- Test - lists.nanog.org

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

NANOG17 agenda topics
by Susan R. Harris 27 Aug '99

27 Aug '99

Greetings - here are topics we've lined up so far for NANOG17 in Montreal: - Traffic Engineering Update (Panel moderated by Ed Kern, Digex) - The HOW-TO Guide to Building Your Own Fiber Network: An ISP Perspective (Yves Le Borgne, RISQ, and Robert Proulx, IMS Expert Conseils) - Optical Networks for the Rest of Us: Recent Developments in Canada's Research Networks (Bill St. Arnaud, CANARIE) - Filling the Gap: Provisioning Bandwidth Between T1 and T3 (Joshua Sakov, Tiara Networks) - Wireless Internet Services (John Brown, iHighway) - BIND and DNS: The Moving Targets (Paul Vixie, ISC) - Spam Update (Paul Vixie, ISC) - Current and Next-Generation Content Distribution Techniques (Panel moderated by Bill Norton, Equinix) - CenterTrack: An IP Overlay Network to Facilitate Packet Tracing (Robert Stone, UUNet) - Building Network Monitoring Systems with RRDtool (Tobias Oetiker, CAIDA) - Using Remstats for Network and Server Monitoring (Thomas Erskine, Communications Research Centre) - New MBone Monitoring Tools (John Robinson, Communications Research Centre) - Network Security: Route Filters and Flow Analysis (Bruce Potter, Fort Nocs) - Application of Statistics/Measurement Technologies to Backbone Engineering (Panel moderated by Abha Ahuja, Merit) Sunday Tutorials - Introduction to MPLS (Peter Ashwood-Smith, Nortel) - Routing Policy Specification Language/Internet Routing Registry Tutorial (Cengiz Alaettinoglu, ISI) Monday Evening BOFs - Inter-Provider Cooperation for MEDs and Best-Exit Routing (Patrick Gilmore, PGExpress, and Avi Freedman, AboveNet) Further info about the meeting is available here: http://www.nanog.org/mtg-9910/ A bientot -- Susan R. Harris

1 0

The Mathematical Reality of IP Addressin in IPv4...
by J.D. Falk 27 Aug '99

27 Aug '99

This looks like interesting (and operational) reading. ----- Forwarded message from Internet-Drafts(a)ietf.org ----- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Mathematical Reality of IP Addressing in IPv4 Questions the need for Another IP System of Addressing Author(s) : E. Terrell Filename : draft-terrell-math-ipaddr-ipv4-00.txt Pages : 22 Date : 24-Aug-99 This paper was necessitated by an overwhelming desire; an attempt to end the apparent disparity in the dissemination of information absent of the logical and thoroughness in rendering an explanation of the IP Addressing Scheme. To render a more pointed fact, I needed to pass a CISCO Certification Examination. However, this can never be accomplished, if the information that is needed and used in the preparation thereof, lacks continuity and propagates errors pertaining to foundational information. Needless to say, my endeavors were not in vein. That is,as a direct result of this undertaking, I corrected the underlining errors, derived a possible alternative approach to the IPv4 Addressing Scheme, and expanded its Class system ( that is no longer in use ). In other words, I was indeed successful in the elimination of the problems associated with IP Address Flooding inherent in IPv4 and the complexities of IPv6. In short, small business and single family dwellings can now have the option of having their own private IP Addressing Scheme, without the disparity resulting from the steep learning curve presented in IPv6. While the Internet Community at large, will not suffer a shortage of the availability IP Addresses for assigned distribution. Especially since, while the number available IP Addresses do not exceed the amount reported to be provided, if IPv6 is implemented. It does indeed, provide enough IP Addresses to cover their continued issuance for at least another 100 years or so. Which is dependent upon the adoption of an adequate scheme for its allocation and distribution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-terrell-math-ipaddr-ipv4-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-terrell-math-ipaddr-ipv4-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv(a)ietf.org. In the body type: "FILE /internet-drafts/draft-terrell-math-ipaddr-ipv4-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ----- End forwarded message ----- ---------========== J.D. Falk <jdfalk(a)cybernothing.org> =========--------- | "The Ogre philosopher Gnerdel beleived the purpose of life | | was to live as high on the food chain as possible. | | She refused to eat vegetarians, and preferred to live entirely | | on creatures that preyed on sentient beings." | | -Magic: The Gathering "Grey Ogre" | ----========== http://www.cybernothing.org/jdfalk/home.html ==========----

11 14

customer troubleshooting process
by Barratt, Tony 27 Aug '99

27 Aug '99

I've been asked to look into customer service issues/fault resolution Along the lines of: Fault1: question1 question2 Fault2: question1 question2 eg Fault:Subscriber can't authenticate (and then get inetaccess) Q1. which userid/password was used Q2. which access number But, mmm, hasn't this been done many times before? I searched the web, but found some half useful stuff on troubleshooting. Can anyone point me to a relevant URL? TIA Tony

1 0