- Test - lists.nanog.org

Statistics and network analysis workshop
by hwb＠upeksa.sdsc.edu 30 Oct '95

30 Oct '95

Hi: Lately we have been discussing with the NSF holding a workshop on statistics collection and network analysis. We are thinking about 4/5 January at SDSC in San Diego, but that is still open to changes. We believe we can comfortably accomodate 30 attendees and have an initial (not yet mailed out) invitation list, but are interested in suggestions from NANOG and IEPG relative to attendees and contents and expectations. If we end up with more than 30 people we will likely have to go by who has expressed most interest by means of position papers or so. I will attach a draft of the invitation letter we are planning to mail out. Please email me with your suggestions (no need to litter on the mailing lists). Hans-Werner Dear colleague: The existence of the NSFNET as a "central network" for the research and education community facilitated research into aspects of aggregate network traffic patterns and the anomalies in those patterns caused by the introduction of new or unique applications. Decommissioning the centralized NSFNET backbone resulted in an environment with no dependable public source of statistics on Internet workloads. Gaining insight into the nature of current workloads and their resource requirements, as well as how they change over time, is essential to supporting Internet evolution. For example, the disparity in workload profiles within the current cross section of Internet applications, ranging from high bandwidth-duration multimedia to historically less demanding e-mail or remote login, will necessitate revised metrics for describing aggregate network behavior. Simple mean or peak utilization figures will be dangerously ineffective in addressing a service provider's needs, without also knowing the `transaction' profile constituting and perhaps dominating those figures. (See http://www.nlanr.net/Fix for examples of traffic flow profiling, including data from the FIX-West multiagency network interconnection facility.) The NSF supported Routing Arbiter provides another source of operational statistics collection, via route servers at the NSF supported NAPs. The RA maintains NAP statistics on packet loss and latency among routing peers, BGP routing protocol message counts, route server memory utilization, and selected interface counts on the server. Details and sample statistics on the MAE-East facility are at http://www.ra.net/ra/statistics. To facilitate discussion among communities of academia, equipment vendors, and service providers, who share interest in and incentive to understand one another's views on network statistics and analysis, we will hold a workshop with support of the National Science Foundation. In this workshop we expect to identify, elicit and evaluate the cross sections of interest, goals, willingness, and technical capability to facilitate such studies in the new distributed environment. Critical to the discussions will be the presence of those who can set policy for design and configuration of Internet components: vendors who can design statistics collection mechanisms, and service providers who can ensure the effective employment of those mechanisms to support their short and medium term engineering requirements to deliver and maintain a stable on a daily basis. Also critical is a user representation, on who's behalf the network is built. If you would like to participate, it would help us greatly to obtain from you a short position statement in advance. ou will have an opportunity to discuss these views during the workshop. Please also let us know whether you are interested in giving a short presentation of your views to the workshop attendees. From the workshop we will construct a report to be distributed to the participants, the National Science Foundation, and other interested parties. We will also attempt to make position statements and pointers to relevant information available via the Web in advance, as we receive them, to allow for information distribution prior to the workshop. The workshop will be held in January 1996 at the San Diego Supercomputer Center. Attached you will find attendance information. Please confirm with us by responding to this note whether you expect to attend. We have submitted a proposal to the National Science Foundation to help those participants who do not have own funding to cover the travel for the workshop. If this is the case for you, please contact us for information about possible availability of such funds. Hans-Werner Braun, and Kimberly C. Claffy (SDSC), and Mark W. Garrett (Bellcore) Workshop co-chairs

1 0

New mailing list announcement
by Eric Kozowski 30 Oct '95

30 Oct '95

A new mailing for discussing Internet related activities, ISP's, etc. in the Pacific NW has been established. To join this list, send email to: majordomo(a)structured.net and put "subscribe nw-internet" in the message _body_ (not the Subject: line) -- Eric Kozowski Structured Network Systems, Inc. kozowski(a)structured.net Better, Cheaper, Faster -- pick any two. (503)656-3530 Voice "Providing High Quality, Reliable Internet Service" (800)881-0962 Voice 56k to DS1

2 1

Re: hum. Is the net-39 experiment expanded to net-38?
by Sean Doran 30 Oct '95

30 Oct '95

Gack. Fix, PSI, you are killing the Internet, and we may have to disconnect from you. Sean.

1 0

hum. Is the net-39 experiment expanded to net-38?
by Peter Lothberg 30 Oct '95

30 Oct '95

Network Next Hop Metric LocPrf Weight Path *> 38.0.0.0 192.108.200.70 0 1800 1239 174 i *> 38.0.3.0/24 192.108.200.70 0 1800 1239 174 i *> 38.1.10.0/24 192.108.200.70 0 1800 1239 174 i *> 38.1.11.0/24 192.108.200.70 0 1800 1239 174 i *> 38.1.62.0/24 192.108.200.70 0 1800 1239 174 i *> 38.1.169.0/24 192.108.200.70 0 1800 1239 174 i *> 38.1.204.0/24 192.108.200.70 0 1800 1239 174 i *> 38.1.213.0/24 192.108.200.70 0 1800 1239 174 i *> 38.1.216.0/24 192.108.200.70 0 1800 1239 174 i *> 38.1.218.0/24 192.108.200.70 0 1800 1239 174 i *> 38.1.219.0/24 192.108.200.70 0 1800 1239 174 i *> 38.1.220.0/24 192.108.200.70 0 1800 1239 174 i *> 38.1.247.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.72.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.77.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.88.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.89.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.103.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.104.0/24 192.108.200.70 0 1800 1239 174 ? *> 38.2.106.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.108.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.110.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.112.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.115.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.116.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.119.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.126.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.135.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.151.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.153.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.155.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.169.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.172.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.174.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.178.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.182.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.184.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.185.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.193.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.194.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.197.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.198.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.199.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.201.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.204.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.205.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.206.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.209.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.212.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.213.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.215.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.216.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.217.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.219.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.220.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.224.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.228.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.239.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.240.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.246.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.247.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.250.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.251.0/24 192.108.200.70 0 1800 1239 174 i *> 38.2.252.0/24 192.108.200.70 0 1800 1239 174 i *> 38.3.212.0/24 192.108.200.70 0 1800 1239 174 i *> 38.3.213.0/24 192.108.200.70 0 1800 1239 174 i *> 38.3.219.0/24 192.108.200.70 0 1800 1239 174 i *> 38.4.213.0/24 192.108.200.70 0 1800 1239 174 i *> 38.5.39.0/24 192.108.200.70 0 1800 1239 174 i *> 38.5.51.0/24 192.108.200.70 0 1800 1239 174 i *> 38.5.52.0/24 192.108.200.70 0 1800 1239 174 i *> 38.5.54.0/24 192.108.200.70 0 1800 1239 174 i *> 38.5.74.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.3.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.4.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.41.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.42.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.74.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.75.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.81.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.82.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.92.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.93.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.95.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.98.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.99.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.100.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.101.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.102.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.111.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.113.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.121.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.122.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.133.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.136.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.143.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.144.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.147.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.148.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.151.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.187.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.191.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.202.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.205.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.206.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.207.0/24 192.108.200.70 0 1800 1239 174 i *> 38.8.208.0/24 192.108.200.70 0 1800 1239 174 i *> 38.10.169.0/24 192.108.200.70 0 1800 1239 174 i *> 38.10.204.0/24 192.108.200.70 0 1800 1239 174 i *> 38.10.212.0/24 192.108.200.70 0 1800 1239 174 i *> 38.10.216.0/24 192.108.200.70 0 1800 1239 174 i *> 38.10.219.0/24 192.108.200.70 0 1800 1239 174 i *> 38.10.220.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.1.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.62.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.72.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.110.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.112.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.115.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.116.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.119.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.126.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.127.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.172.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.174.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.178.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.181.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.185.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.194.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.198.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.199.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.201.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.204.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.205.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.206.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.209.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.215.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.216.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.217.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.224.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.239.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.240.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.246.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.247.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.250.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.251.0/24 192.108.200.70 0 1800 1239 174 i *> 38.11.252.0/24 192.108.200.70 0 1800 1239 174 i *> 38.12.62.0/24 192.108.200.70 0 1800 1239 174 i *> 38.12.172.0/24 192.108.200.70 0 1800 1239 174 i *> 38.12.204.0/24 192.108.200.70 0 1800 1239 174 i *> 38.14.39.0/24 192.108.200.70 0 1800 1239 174 i *> 38.14.51.0/24 192.108.200.70 0 1800 1239 174 i *> 38.14.52.0/24 192.108.200.70 0 1800 1239 174 i *> 38.14.54.0/24 192.108.200.70 0 1800 1239 174 i *> 38.14.74.0/24 192.108.200.70 0 1800 1239 174 i *> 38.33.33.0/24 192.108.200.70 0 1800 1239 174 i *> 38.127.80.0/24 192.108.200.70 0 1800 1239 174 i *> 38.145.34.0/24 192.108.200.70 0 1800 1239 174 i *> 38.145.39.0/24 192.108.200.70 0 1800 1239 174 i *> 38.145.69.0/24 192.108.200.70 0 1800 1239 174 i *> 38.145.76.0/24 192.108.200.70 0 1800 1239 174 i *> 38.145.77.0/24 192.108.200.70 0 1800 1239 174 i *> 38.145.83.0/24 192.108.200.70 0 1800 1239 174 i *> 38.145.111.0/24 192.108.200.70 0 1800 1239 174 i *> 38.145.138.0/24 192.108.200.70 0 1800 1239 174 i *> 38.145.146.0/24 192.108.200.70 0 1800 1239 174 i *> 38.145.161.0/24 192.108.200.70 0 1800 1239 174 i *> 38.145.169.0/24 192.108.200.70 0 1800 1239 174 i *> 38.145.176.0/24 192.108.200.70 0 1800 1239 174 i *> 38.145.185.0/24 192.108.200.70 0 1800 1239 174 i *> 38.145.194.0/24 192.108.200.70 0 1800 1239 174 i *> 38.145.204.0/24 192.108.200.70 0 1800 1239 174 i *> 38.145.209.0/24 192.108.200.70 0 1800 1239 174 i *> 38.145.212.0/24 192.108.200.70 0 1800 1239 174 i *> 38.145.213.0/24 192.108.200.70 0 1800 1239 174 i *> 38.145.216.0/24 192.108.200.70 0 1800 1239 174 i *> 38.145.218.0/24 192.108.200.70 0 1800 1239 174 i *> 38.145.219.0/24 192.108.200.70 0 1800 1239 174 i *> 38.145.220.0/24 192.108.200.70 0 1800 1239 174 i *> 38.145.247.0/24 192.108.200.70 0 1800 1239 174 i *> 38.145.250.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.10.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.13.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.25.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.26.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.29.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.32.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.33.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.43.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.45.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.53.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.57.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.63.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.65.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.72.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.78.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.83.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.85.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.86.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.88.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.89.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.90.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.91.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.103.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.106.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.110.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.112.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.115.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.116.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.119.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.126.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.127.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.133.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.134.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.135.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.138.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.139.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.140.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.147.0/24 192.108.200.70 0 1800 1239 174 ? *> 38.146.152.0/24 192.108.200.70 0 1800 1239 174 ? *> 38.146.172.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.173.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.174.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.178.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.181.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.185.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.194.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.198.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.199.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.205.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.206.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.209.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.215.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.217.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.224.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.239.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.240.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.246.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.247.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.250.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.251.0/24 192.108.200.70 0 1800 1239 174 i *> 38.146.252.0/24 192.108.200.70 0 1800 1239 174 i *> 38.147.39.0/24 192.108.200.70 0 1800 1239 174 i *> 38.147.51.0/24 192.108.200.70 0 1800 1239 174 i *> 38.147.52.0/24 192.108.200.70 0 1800 1239 174 i *> 38.147.54.0/24 192.108.200.70 0 1800 1239 174 i *> 38.147.74.0/24 192.108.200.70 0 1800 1239 174 i *> 38.147.254.0/24 192.108.200.70 0 1800 1239 174 i *> 38.241.241.0/24 192.108.200.70 0 1800 1239 174 i

2 1

Request
by System Administrator# 30 Oct '95

30 Oct '95

Would you mind .... Subscripte E-mail: chkim(a)garam.kreonet.re.kr ---------------------------------------------- P.O.BOX 1,Youseong-Gu Taejeon-City (Zip Code) 305 - 600 KOREA KIST KOREA INSTITUTE OF SCIENCE AND TECHNOLOGY ( KIST ) SERI SYSTEM ENGINEERING REASEARCH INSTITUTE ( SERI ) ~~~~ National R&D Network Center [ Phone:042-869-1390/FAX:042-861-1999 ] KREONet ( Korea Research Environment Open Network ) ~~~~~~~ [ Phone:+8242-869-1390 ] [ E-mail: chkim(a)garam.kreonet.re.kr ] Choon-Hyoung Kim [ E-mail: chkim(a)garam.kreonet.re.kr ]

1 0

Black holes caused by aggregation
by bmanning＠ISI.EDU 26 Oct '95

26 Oct '95

My appologies if you have already seen this. It appears to be an operational/configuration issue that our clients might be interested in..... :) Perhaps its time to upgrade all that mbone/mrouted software out there. > From: Bill Fenner <fenner(a)parc.xerox.com> > Subject: Black holes caused by aggregation > Date: Wed, 25 Oct 1995 18:52:46 PDT > > Longest-match routing was introduced in mrouted version 3.5 . Previous > versions would only accept the least specific route that it heard, and > if it heard routes that overlapped it would log a message and drop the > new route. > > People now appear to be using Cisco's route aggregation feature in > places that it shouldn't be used, which will cause problems when > forwarding through mrouted versions previous to 3.5 (which is about 75% > of the MBONE). A nice example of the breakage is net UIUC-CAMPUS-B, > 128.174. (Not to pick on UIUC in particular, but it's the easiest > example for me.) The three routes that I have in my routing tables for > 128.174 are: > > 128.174.212.0/25 > 128.174.240/24 > 128.174/16 > > Note that the last route covers the first two, and mrouted versions previous > to 3.5 will only accept the last route. In fact, if I traceroute towards > 128.174.0.0, I have a nice short route: > > Mtrace from 128.174.0.0 to 204.162.228.2 via group 224.2.0.1 > Querying full reverse path... > 0 dartvader (204.162.228.2) > -1 parc.dart.net (204.162.228.1) DVMRP thresh^ 1 200 s > -2 ames.dart.net (140.173.144.1) DVMRP thresh^ 1 200 s > -3 mbone2.nsi.nasa.gov (192.203.230.242) DVMRP thresh^ 64 200 s > -4 mbone.nsi.nasa.gov (192.203.230.241) DVMRP thresh^ 1 200 s > -5 oday.psc.edu (192.88.114.10) DVMRP thresh^ 64 176 s > -6 mbone.merit.edu (198.108.2.20) DVMRP thresh^ 64 201 s > -7 tibia.cic.net (192.217.65.100) DVMRP thresh^ 32 254 s Next router no mtrace > -8 dcl2.gw.uiuc.edu (192.17.2.8) [proteon/mrouted 1.0] doesn't support mtrace > > However, if I trace towards one of the specific routes, I end up taking > the shortest mrouted-3.5-or-greater path: > > Mtrace from 128.174.240.0 to 204.162.228.2 via group 224.2.0.1 > Querying full reverse path... > 0 dartvader (204.162.228.2) > -1 parc.dart.net (204.162.228.1) DVMRP thresh^ 1 200 s > -2 ames.dart.net (140.173.144.1) DVMRP thresh^ 1 200 s > -3 mbone2.nsi.nasa.gov (192.203.230.242) DVMRP thresh^ 64 200 s > -4 mbone.nsi.nasa.gov (192.203.230.241) DVMRP thresh^ 1 200 s > -5 mbone.sdsc.edu (198.17.47.39) DVMRP thresh^ 64 200 s > -6 VINEGAR.SESQUI.NET (128.241.0.91) DVMRP thresh^ 64 201 s > -7 mae-bone.psi.net (192.41.177.247) DVMRP thresh^ 64 128 s > -8 MBONE1.UU.NET (137.39.43.34) DVMRP thresh^ 64 201 s > -9 MBONE2.UU.NET (137.39.246.98) DVMRP thresh^ 64 201 s > -10 dec3800-2-fddi-0.SanFrancisco.mci.net (204.70.158.61) DVMRP thresh^ 64 2828 ms > -11 dec3800-2-fddi-0.Denver.mci.net (204.70.152.61) DVMRP thresh^ 1 41 s > -12 dec3800-1-fddi-0.WillowSprings.mci.net (204.70.104.29) DVMRP thresh^ 1 -24 s > -13 tibia.cic.net (192.217.65.100) DVMRP thresh^ 32 254 s Next router no mtrace > -14 dcl2.gw.uiuc.edu (192.17.2.8) [proteon/mrouted 1.0] doesn't support mtrace > Round trip time 295 ms > > Now, you might say "Well, that just means that traffic is taking a suboptimal > path, no big deal." But, because of the way DVMRP builds its forwarding > trees, traffic that matches the specific routes (e.g. 128.174.240.1) will > *not* get forwarded from a 3.5-and-up to a 3.4-and-down mrouter. Here is > a (slightly altered, since there is no active source in 128.184.240.x right > now) mtrace showing what you would see on that boundary: > > Mtrace from 128.174.240.0 to 141.210.188.1 via group 224.2.0.1 > Querying full reverse path... > 0 ? (141.210.188.1) > -1 ? (141.210.188.3) DVMRP thresh^ 1 208 s > -2 mbone.wayne.edu (141.217.1.74) DVMRP thresh^ 32 -250 s Not forwarding > -3 mbone.merit.edu (198.108.2.20) DVMRP thresh^ 32 201 s > -4 tibia.cic.net (192.217.65.100) DVMRP thresh^ 32 254 s Next router no mtrace > -5 dcl2.gw.uiuc.edu (192.17.2.8) [proteon/mrouted 1.0] doesn't support mtrace > > Note the "Not forwarding" error code on the mbone.wayne.edu line. > 141.210.188.3 is 3.4, mbone.wayne.edu is 3.5 . (Again, not to pick > on wayne.edu; this was the easiest test case that I could come up with.) > > This means that if you are one of the people advertising this kind of > specific and general routes, that you are isolating your traffic from > the specifically routed subnets to the connected cloud of 3.5-and-above > routers. Of course, the long term solution is to get the whole MBONE > able to accept this kind of routing; the short term solution, however, > is not to advertise this kind of route. Therefore, I will be periodically > posting a list of routes that fall into this category; hopefully, the > people responsible for those networks will reconfigure their routers to > either advertise only a general route or only non-overlapping specific > routes. > > The list follows. I will be posting this list (with a shorter explanation) > periodically. > > Bill > > 36.18/16 is covered by 36/8 > 36.53/16 is covered by 36/8 > 36.56/16 is covered by 36/8 > 36.103/16 is covered by 36/8 > 36.153/16 is covered by 36/8 > 36.224/16 is covered by 36/8 > 128.32.211/24 is covered by 128.32/16 > 128.32.226/24 is covered by 128.32/16 > 128.171.3/24 is covered by 128.171/16 > 128.171.10/24 is covered by 128.171/16 > 128.171.11/24 is covered by 128.171/16 > 128.171.45/24 is covered by 128.171/16 > 128.174.212.0/25 is covered by 128.174/16 > 128.174.240/24 is covered by 128.174/16 > 132.250.88.170/32 is covered by 132.250.88.160/28 > 137.194.2/23 is covered by 137.194/16 > 137.194.34/23 is covered by 137.194/16 > 137.194.98/23 is covered by 137.194/16 > 137.194.160/23 is covered by 137.194/16 > 137.194.224/23 is covered by 137.194/16 > 137.194.230/23 is covered by 137.194/16 > 137.194.232/23 is covered by 137.194/16 > -- --bill

1 0

A bunch-of-morons
by avg＠postman.ncube.com 26 Oct '95

26 Oct '95

Check http://www.hyperspace.net for a good laugh. (Credits to Sean for discovering it). --vadim

1 0

Re: Initial Route Server Stats for MAE-East
by Steven J. Richardson 24 Oct '95

24 Oct '95

Tim: 1) I'm Steve, not Richard. 2) Yes, I did find your analogy (which you admitted was "crude") to be offensive. That was my point. I really don't see the point of that sort of comment in a technical discussion. also... >From bass(a)dune.silkroad.com Tue Oct 24 16:09:07 1995 >From: Tim Bass <bass(a)dune.silkroad.com> >Message-Id: <199510242006.QAA06544(a)dune.silkroad.com> >Subject: Re: Initial Route Server Stats for MAE-East >To: sjr(a)merit.edu (Steven J. Richardson) >Date: Tue, 24 Oct 1995 16:06:08 -0400 (EDT) >Cc: young(a)mci.net, curtis(a)ans.net, mnasto(a)franklin.nysernet.org, > mo(a)uunet.uu.net, nanog(a)home.merit.edu, wbn(a)merit.edu >In-Reply-To: <199510241659.MAA17828(a)home.merit.edu> from "Steven J. Richardson" at Oct 24, 95 12:59:40 pm >> >> >' make sure to put all the hair in your pants before >> > zipping your zipper..... notes ... SPAMtastic >> >> Is this really necessary? I don't see any technical point in this >> sort of argument. >> > >No, Richard, it is not 'really necessary'. I hope that you did not >find my crude analogy offensive. >I plead guilty to taking >my opinion to somewhat arrogant extremes in the above statement. >Furthermore, I made the mistake of thinking that this tread was on >com-priv. Ah... >If I had been more cognizant of the fact that this >discussion was on nanog, I would not have posted such a harsh >critique. > >My mistake, too quick on the elm keys, for sure. Thanks > >Regards, > >Tim Steve Richardson/Merit

1 0

Re: Initial Route Server Stats for MAE-East
by Steven J. Richardson 24 Oct '95

24 Oct '95

>From list-admin(a)merit.edu Sun Oct 22 22:24:49 1995 >From: Tim Bass <bass(a)dune.silkroad.com> >Message-Id: <199510230155.VAA03167(a)dune.silkroad.com> >Subject: Re: Initial Route Server Stats for MAE-East >To: young(a)mci.net (Jeff Young) >Date: Sun, 22 Oct 1995 21:55:04 -0400 (EDT) >Cc: mnasto(a)franklin.nysernet.org, mo(a)uunet.uu.net, curtis(a)ans.net, > wbn(a)merit.edu, nanog(a)home.merit.edu >In-Reply-To: <199510230104.VAA15334(a)foghorn.reston.mci.net> from "Jeff Young" at Oct 22, 95 09:04:19 pm >X-Mailer: ELM [version 2.4 PL24 PGP2] >MIME-Version: 1.0 >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: 7bit >Content-Length: 1915 >Status: RO > Tim: >' make sure to put all the hair in your pants before > zipping your zipper..... notes ... SPAMtastic Is this really necessary? I don't see any technical point in this sort of argument. >Tim > >-- >+--------------------------------------------------------------------------+ >| Tim Bass | #include<campfire.h> | >| Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | >| The Silk Road Group, Ltd. | take_one_down(); | >| | pass_it_around(); | >| http://www.silkroad.com/ | } | >| | back_to_work(); /*never reached */ | >+--------------------------------------------------------------------------+ Steve Richardson speaking for himself, not Merit Network, Inc.

2 1

bcast LQM
by William Allen Simpson 24 Oct '95

24 Oct '95

> From: Curtis Villamizar <curtis(a)ans.net> > LQM on non-PPP links sure would be great. A number of times I've > suggested we consider LQM on bcast, with a set of LQM parameters per > ARP entry. This way one end sends a LQM packet that serves as a time > marker, counts packets, then includes the count in the next LQM time > marker. The receiver needs only count packets between LQM packets and > compare the local count against the count sent by the other end. This > is an enormously oversimplified summary of LQM, but it just to make > the point that LQM is Good Stuff. > Yes, but a bit tough on broadcast, as you would need all nodes sending a history of all the other LQM counts it heard. Quite a big packet or set of packets with many nodes participating. What might be a better idea is to add it to BGP-n. Say between routing peers. That's what I did for IPng, in my (now mangled) Neighbor Discovery. > In the absence of LQM we have the DS3 MIB (poor substitute) Hey, the original PPP LQM was designed and built for DS3 (at Network Systems). NSFnet was very interested at the time. Aren't we already running PPP LQM for all the DS3's? PPP LQM was one of the reasons for PPP/FrameRelay, too. Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

2 1