- Test - lists.nanog.org

IP allocation software
by Jeremiah Kristal 31 Aug '99

31 Aug '99

Back in early '98 there was a rather limited discussion on the availability (or lack) of software to manage IP allocations in a CIDR world. The concensus at the time was that nothing really existed, other than homebuilt products. Has anyone come out with a commerical or non-commercial solution since then? Jeremiah Kristal Qwest Internet Solutions Manager, Network Services 201-319-5764 x284 internal

5 4

two workshops (cflowd, RRDTool) 29-30 sept 99
by k claffy 31 Aug '99

31 Aug '99

the Cooperative Association for Internet Data Analysis (CAIDA) at the University of California's San Diego Supercomputer Center (SDSC) is hosting a two-day workshop, September 29-30, 1999, focusing on two tools: cflowd and arts++ (www.caida.org/Tools/cflowd and www.caida.org/Tools/arts++) - Daniel McRobb author RRDtool (www.caida.org/Tools/RRDtool) - Tobi Oetiker, author cflowd and arts++ are tools for collection, storage and analysis of flow-export data from Cisco netflow output. they facilitate collection and analysis of router-based data by network engineers in support of capacity planning, trends analysis, and characterization of traffic workloads. (note btw new cflowd release today: cflowd-2-1-a2; corresponding arts++ release: arts++-1-1-a1. http://www.caida.org/archives/cflowd/0377.html) RRDtool is a time-series, data-storage and visualization tool that assists in managing data collections. it is a system to store and display time-series data, e.g. network bandwidth, machine-room temperature, server load average. RRDtool stores data in a compact manner and includes utilities for graphical presentation of synthesized data. note there won't be any cflowd stuff at nanog.montreal, but tobi should be doing an RRDtool overview. fwiw. the workshop is open to network operators responsible for monitoring and/or managing WAN networks. attendance is limited and will be on a first-come basis. details available at http://iec.caida.org/workshop/9909/. if you have any questions, please contact Theresa Ott <theresa(a)caida.org> 858/822-0956. k

1 0

acm finally lets us mbone-broadcast sigcomm (going on today->fri)
by k claffy 31 Aug '99

31 Aug '99

(we've been asking/offering for years; guess persistence sometimes actually works, yum) high s/n sigcomm program, hope you're actually lucky enuf to be there: http://www.acm.org/sigcomm/sigcomm99/advance_program.html vint's montage.thing today: http://www.acm.org/sigcomm/sigcomm99/tutorials.html#Technical_history note apparently only about 40% of globe can see ad on sdr (ok so persistence hasn't worked for everything yet) k ----- Forwarded message from Evi Nemeth <evi(a)anchor.cs.colorado.edu> ----- Date: Tue, 31 Aug 1999 10:46:47 -0600 (MDT) From: Evi Nemeth <evi(a)anchor.cs.colorado.edu> To: rem-conf(a)es.net Subject: sigcomm mbone broadcast Cc: evi(a)anchor.cs.colorado.edu our advertisements of the sigcomm conference (today, vint cerf ++ 's tutorial on the technical history of the internet) seems to be intermittment in sdr, so here are the numbers if anyone wants to join it by hand this is what ps says on the broadcasting machine: vat -f pcm2 -r -I 3 -t 127 224.2.248.10/26350 vic -t 127 -I 3 224.2.238.15/59082/h261/127 wb -t 127 224.2.184.76/40395 our original advertisement from uc santa barbara used dvi2 as format, but we couldnt see it when we started broadcasting so we used the local backup which was set to use pcm2 format. i think vat adapts. -evi ----- End forwarded message -----

1 0

NANOG 17 Info
by Pam Ciesla 31 Aug '99

31 Aug '99

Room block at the Wyndham Hotel Montreal ends Friday 9/3. Be sure to mention NANOG Meeting 514-285-1450-phone. The tutorials on Sunday, 10/3 will start at 1PM EDT and the meeting will end on Tueday, 10/5 at 4PM EDT. Information on the NANOG 17 Meeting can be found on http://www.nanog.org. Any questions please contact me. Thanks Pam Pam Ciesla Merit Network,Inc. 734-936-0172 - phone 4251 Plymouth Road 734-647-3185 Bldg.I, Suite C pam(a)merit.edu Ann Arbor, MI 48107

1 0

Seems PB-NAP or those at PB-NAP are filtering on 206.29.134 /24
by John M. Brown 31 Aug '99

31 Aug '99

It seems that several providers are filtering on the above /24 space. EPOCH is one of them The common point is PB-NAP But I don't know if its the fabric at PB-NAP, if its PacBell Internet, or if its various providers at PB-NAP..... I wouldn't think that PB-NAP would filter, but I am at a loss, and haven't been able to get a reply from either party. PacBell Internet could be the problem as they had some static routes in there system while we where a customer. They swear they never did, but the clueless NOC monkeys wouldn't know a static if it bit them on there dynamic..... I also don't think its PBI, as PBI != PB-NAP, Right? Several of our clients are having problems getting to sites by using this /24. jmbrown(a)ihighway.net

1 0

Communicating with customers, then and now
by Sean Donelan 30 Aug '99

30 Aug '99

http://www.teledotcom.com/news0899/news083099_3.html MCI Worldcom is getting some third-party help with their communications. Although this was mostly directed to an IP network, most of the suggestions are applicable to all networks. Check out the NANOG archives from 1995 (watch the addresses, people have switched employers several times since). search for the subject "outages, quality monitoring, trouble tickets, etc" http://answerpointe.cctec.com/query/q-nanog.asp Here was my opinion in 1995, the problem with the Net is your words will come back to haunt you. http://answerpointe.cctec.com/maillists/nanog/historical/9511/msg00319.html -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: BGP Path Selection
by Russell Briggs 30 Aug '99

30 Aug '99

On Mon, Aug 30, 1999 at 03:44:01PM -0400, John G. Scudder said: > At 12:34 PM -0700 8/30/99, Russell Briggs wrote: > > Um, Cisco uses as length and igp metrics in the route selection > > process. This is hardly in compliance with the RFC. > > Actually, IGP metric is just fine, it's 9.1.2.1.b in RFC 1771. I read that section of the rfc, and yes, that is correct. Thanks for pointing that out. --Russb > > Use of AS path length is, as you say, hardly in compliance. > > --John > -- > John Scudder email: jgs(a)ieng.com > Internet Engineering Group, LLC phone: (734) 213-4939 x14 > 122 S. Main, Suite 280 fax: (734) 669-8661 > Ann Arbor, MI 48104 www: http://www.ieng.com -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Russell Briggs TEL: 512-322-9200 Senior Network Engineer CEL: 512-633-5983 Onramp Access, Inc. FAX: 512-476-2878 russb(a)quadrunner.com http://www.onr.com/

1 0

Re: BGP Path Selection
by Russell Briggs 30 Aug '99

30 Aug '99

in-line reply On Mon, Aug 30, 1999 at 07:53:36PM +0200, Alex Bligh said: > > Bryan, > > > I keep hearing bitching about how broken the BGP path selection > > process as 1) defined in the protocol spec and 2) as implemented > > by vendors, is. > > Well this is a yet-another-knob-request. I have for a while now thought > it would be useful to have an attribute which is kept local to the AS, > and is if you like an "exit-penalty". This could be added to your IGP > distance at the decision stage process. It's difficult to combine > internal IGP metrics (especially if you use next-hop-self style peerings > internally so lose the distance on the interface itself) *and* add > make intelligent use of different quality interconnects (especially > if these are interfaces on the same router). > > Consider the case where you are prepared to send traffic from SOME parts > of the country "around the long way" to avoid a particularly crappy > interconnect, point, but not from ALL parts of the country. > > On your point (2) I reckon Cisco implements the standard pretty > well (i.e. where it diverges it's for reasonable reasons), or at Um, Cisco uses as length and igp metrics in the route selection process. This is hardly in compliance with the RFC. > least it does when you've switched on "bgp deterministic-med" which > gives you a good indication of how MED decisions are taken without > this knob switched on. > > -- > Alex Bligh > GX Networks (formerly Xara Networks) > > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Russell Briggs TEL: 512-322-9200 Senior Network Engineer CEL: 512-633-5983 Onramp Access, Inc. FAX: 512-476-2878 russb(a)quadrunner.com http://www.onr.com/ ----- End forwarded message ----- -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Russell Briggs TEL: 512-322-9200 Senior Network Engineer CEL: 512-633-5983 Onramp Access, Inc. FAX: 512-476-2878 russb(a)quadrunner.com http://www.onr.com/

1 1

BGP Path Selection
by Bryan S. Blank 30 Aug '99

30 Aug '99

I keep hearing bitching about how broken the BGP path selection process as 1) defined in the protocol spec and 2) as implemented by vendors, is. It's probably a good idea to bring this out in to the open. If you have specific complaints about how broken path selection is, please speak your piece now. Thanks! ----------------------------------------------------------------------------- Bryan S. Blank bryan(a)supernet.net (443)394-9529 tele (410)995-2191 page (410)802-6998 emer

3 2

The Cidr Report
by Tony Bates 27 Aug '99

27 Aug '99

This is an auto-generated mail on Fri Aug 27 12:00:00 PDT 1999 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 27Aug99 0) General Status Table History ------------- Date Prefixes 200899 62592 210899 62567 220899 62711 230899 63441 240899 62725 250899 62995 260899 62950 270899 63124 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 4052 Number of ASes announcing only one prefix: 1635 (351 cidr, 1284 classful) Largest number of cidr routes: 181 announced by AS701 Largest number of classful routes: 835 announced by AS701 1) Gains by aggregating at the origin AS level --- 27Aug99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 335 145 190 56.7% BCnet Backbone AS2609 127 13 114 89.8% EUnet-TN AS1221 555 455 100 18.0% TELSTRA-AS AS577 290 196 94 32.4% Bell Canada Backbone AS174 574 480 94 16.4% Performance Systems International AS4293 235 145 90 38.3% IMCI AS7046 319 234 85 26.6% UUNET-CUSTOMER AS7657 237 160 77 32.5% The Internet Group Limited AS7545 140 65 75 53.6% TPG Internet Pty Ltd AS4200 176 101 75 42.6% AGIS (Apex Global Information Ser AS3749 139 64 75 54.0% TECNET AS209 318 243 75 23.6% Qwest Communications AS7496 108 34 74 68.5% Power Up AS10928 118 48 70 59.3% UNKNOWN AS9269 88 19 69 78.4% Hong Kong CTI AS1785 372 311 61 16.4% NYSERNet Backbone AS6944 63 6 57 90.5% RapidSite, Inc. AS4755 136 79 57 41.9% Videsh Sanchar Nigam Ltd. India AS4740 359 304 55 15.3% Ozemail Pty Ltd (ASN-OZEMAIL) AS719 462 410 52 11.3% LANLINK autonomous system AS2493 156 107 49 31.4% iSTAR Internet, Inc. AS684 92 46 46 50.0% Manitoba Regional Network Backbon AS549 209 169 40 19.1% ONet Backbone AS3737 102 65 37 36.3% PenTeleData Inc. (ASN-PTD) AS1 506 469 37 7.3% BBNPLANET AS10724 42 8 34 81.0% UNKNOWN AS4307 32 1 31 96.9% SVINET-1 AS10479 40 9 31 77.5% ITESM-Rectoria Zona Norte AS8023 43 13 30 69.8% CASTLES AS7745 38 8 30 78.9% BIGSKY-AS For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0