- NANOG - lists.nanog.org

Re: Peering problem with NSP
by William Allen Simpson 31 Oct '95

31 Oct '95

> From: briand(a)fonorola.net (Brian Dickson) > I do wish you'd feel free to ask us these sorts of questions directly. > We're more > than happy to provide you with an explanation, and an honest answer based > on the facts > will go a lot farther towards providing you with a solution, than open > speculation on a > mailing list. You cut off his excellent rationale, which was (Quoting Matt Harrop): # before I start butting heads with their # management, I want to be sure of the technical issues. Now, here is exactly what you ought to desire -- an informed customer. Yet, you publically castigate him for asking a mailing list which deals with _exactly_ these technical issues. > Frankly, it is this sort of unenlightened, baseless opinion that gives > Usenet its deserved reputation. It certainly doesn't reflect the level of > professionalism that a reputable NSP should display, on this list > in particular. This rather surprises me, since I don't believe that this is a Usenet distributed list. My personal reaction was also, "they want you as a captive customer". You say: > ... Transit ASes > cannot be > provided to you at this time on a guarenteed basis. If you use us as > default, this is not a problem.... And: > The reason we cannot > guarantee transit AS connectivity is a direct result of not being your default > connection. If you select us as default, we can guarantee transit access. The > particulars behind that are technical; I surely don't understand what default routing (which would only be outgoing) has to do with your advertisements to other ASs (which would provide him incoming reachability). So, perhaps you can enlighten this technical mailing list? To conclude, this person states that he is a "service provider". Providers _should_ be multiply homed. This is encouraged! 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

1 0

Re: Peering problem with NSP
by mharrop＠interlog.com 31 Oct '95

31 Oct '95

I would like to extent a public apology to Eric Carroll, Brian Dickson, and the rest of the staff of i*internet. My message ruffled some feathers, and I'm sorry about that. I did not mean to imply that they don't know what they're doing, or are in any way less than competent. On the contrary I have found the i*internet staff to be extremely good at what they do. I would also like to apologize to Eric Carroll for posting an excerpt from his private email, which I did without thinking. BTW: Thanks to all who have replied to my message for your valuable feedback, it's just what I was after. Regards, -- Matt Harrop mharrop(a)interlog.com InterLog Internet Services voice (416) 975-2655 fax (416) 975-9639

1 0

Re: Peering problem with NSP
by briand＠fonorola.net 31 Oct '95

31 Oct '95

> On Mon, 30 Oct 1995, Matt Harrop wrote: > > > In a few months, the network I operate is going to become > > multi-homed. I've just ordered the T1 from SprintLink and I know that > > they'll have no problem with BGP4 peering, or with the fact that I'll be > > multi-homed. My problem is with my existing NSP; fONOROLA. When I > > informed that that I would be going multi-homed, and asked them about > > peering this was their answer: > > > > > Due to our high level of interconnectivity, we carry over 6k routes >on our > > > backbone. Not all will be available to you. We can only assure you >that direc > > t > > > connect routes will be offered, namely AS2493 & AS812. Transit ASes >cannot be > > > provided to you at this time on a guarenteed basis. If you use us as > > > default, this is not a problem, but I suspect you will not. We have >direct > > > connectivity to CA*net, Rogers, UUNET, WorldLinx, MCI, ANS, and > > > cannot, at this time, ensure that all routes land on you. This kind of > > > routing transit service is not really intended as our usual service > > > offering, and it has a strong impact on our backbone design. > > > > Is this in any way reasonable? fONOROLA's primary connections to the rest > > of the world are MCI and ANS. If they can't provide transit to MCI and > > ANS, they are essentialy useless to me. Of perticular interest to me is > > their last statement. Would this actualy have a "strong impact" on their > > backbone? Matt, I do wish you'd feel free to ask us these sorts of questions directly. We're more than happy to provide you with an explanation, and an honest answer based on the facts will go a lot farther towards providing you with a solution, than open speculation on a mailing list. But feel free to solicit opinions. Language used in networking can be a bit confusing, since some of the aspects of networking are somewhat subtle. I will send you a more detailed explanation, but I wanted to set the record straight in this public forum. The reason we cannot guarantee transit AS connectivity is a direct result of not being your default connection. If you select us as default, we can guarantee transit access. The particulars behind that are technical; I will fill you in off-line, since that information is proprietary. And yes, it really does have a strong impact on our backbone *design*. [ BTW, Matt, we are iSTAR internet, inc. (formerly fONOROLA i*internet). Please use our new name when referring to us, to avoid any confusion. ] > Ya, drop them, they just don't want to do it. > > Nathan Stratton CEO, NetRail, Inc. Your Gateway to >the World! [ Editorial mode on ] Frankly, it is this sort of unenlightened, baseless opinion that gives Usenet its deserved reputation. It certainly doesn't reflect the level of professionalism that a reputable NSP should display, on this list in particular. [ End of editorial mode ] ----------------------------------------------------------------------------- Brian Dickson, Email: briand(a)istar.ca iSTAR internet, inc., Tel : (613) 780-2200 Suite 202, 250 Albert Street, Fax : (613) 780-6666 Ottawa, Ontario, Canada, K1P 6M1 http://www.istar.ca -----------------------------------------------------------------------------

1 0

Peering problem with NSP
by mharrop＠interlog.com 30 Oct '95

30 Oct '95

In a few months, the network I operate is going to become multi-homed. I've just ordered the T1 from SprintLink and I know that they'll have no problem with BGP4 peering, or with the fact that I'll be multi-homed. My problem is with my existing NSP; fONOROLA. When I informed that that I would be going multi-homed, and asked them about peering this was their answer: > Due to our high level of interconnectivity, we carry over 6k routes on our > backbone. Not all will be available to you. We can only assure you that direct > connect routes will be offered, namely AS2493 & AS812. Transit ASes cannot be > provided to you at this time on a guarenteed basis. If you use us as > default, this is not a problem, but I suspect you will not. We have direct > connectivity to CA*net, Rogers, UUNET, WorldLinx, MCI, ANS, and > cannot, at this time, ensure that all routes land on you. This kind of > routing transit service is not really intended as our usual service > offering, and it has a strong impact on our backbone design. Is this in any way reasonable? fONOROLA's primary connections to the rest of the world are MCI and ANS. If they can't provide transit to MCI and ANS, they are essentialy useless to me. Of perticular interest to me is their last statement. Would this actualy have a "strong impact" on their backbone? I can't think of any technical reason that they would be taking this position with me. However I'm not a routeing expert, and that's why I'm posting to this list. At this point I'm assuming that their possition is an administrative one, but before I start butting heads with their management, I want to be sure of the technical issues. Thanks in advance, Matt Harrop -- Matt Harrop mharrop(a)interlog.com InterLog Internet Services voice (416) 975-2655 fax (416) 975-9639

2 1

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