October 1998 - Test - lists.nanog.org

Re: Maybe I'm misreading this but...
by I Am Not An Isp 17 Oct '98

17 Oct '98

At 04:58 PM 10/16/98 -0400, tvo wrote: >Well, that is all fine and well if the device with the RFC1918 address is >the one screaming "Too Boocoo!" but if it's some other box trying to tell >it that the packets are too bug, no dice. Non-routable address. If you mean "if some device tries to tell the RFC1918 box the packet is too large", this is correct. However, the same reasoning shows that *ANY* session opened between an RFC1918 box and a random host on the Internet will break as well. I suppose you could be talking about a one-way transmission of data from the RFC1918 box to a random host. If so, yes, you are SOL. I just don't see a whole lot of that. ;) TTFN, patrick I Am Not An Isp www.ianai.net "Think of it as evolution in action." - Niven & Pournelle

1 0

Re: Maybe I'm misreading this but...
by Dean Anderson 17 Oct '98

17 Oct '98

Sorry. I stand corrected. --Dean At 02:00 PM 10/16/98 -0700, I Am Not An Isp wrote: >At 04:37 PM 10/16/98 -0400, Dean Anderson wrote: > >>But Path MTU discovery is a bit more complicated. I'm not looking at any >>docs at the moment, so I hope I'm not completely wrong about this, but as I >>recall the discovery process tries to send packets to each hop. First >>discovering the route path, and then trying to determine the mtu of each >>hop. While the intermediate RFC1918 addresses can reply to things they >>happen to get, you can't directly send a packet to them to see if they will >>want to fragment it. > >This is incorrect. From RFC1191, which can be found at >http://www.pmg.lcs.mit.edu/cgi-bin/rfc/view-plain?number=1191, page 2, >section "2. Protocol overview": > ><quote> > The basic idea is that a source host initially assumes that the PMTU > of a path is the (known) MTU of its first hop, and sends all > datagrams on that path with the DF bit set. If any of the datagrams > are too large to be forwarded without fragmentation by some router > along the path, that router will discard them and return ICMP > Destination Unreachable messages with a code meaning "fragmentation > needed and DF set" [7]. Upon receipt of such a message (henceforth > called a "Datagram Too Big" message), the source host reduces its > assumed PMTU for the path. ></quote> > >So, as I stated in my last post, it will work unless you filter RFC1918 >space. I've received lots & lots of replies saying "I filter it", or "I >RFC1918 in my own LAN, so the firewall drops the packets assuming they are >spoofed" or stuff like that. This is fine, and possibly even desirable. >However, there is nothing to distinguish a packet with RFC1918 space as the >source address from any other "legal" packet on the 'Net other than your >own administrative policies - which can break *anything* on the 'Net, not >just PMTU with RFC1918 space. Sorry, but I have no control over your >policy. So, if someone asks "does this break...", the answer is no. > >> --Dean > >TTFN, >patrick > >I Am Not An Isp >www.ianai.net >"Think of it as evolution in action." - Niven & Pournelle > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Re: Maybe I'm misreading this but...
by tvo 17 Oct '98

17 Oct '98

Well, that is all fine and well if the device with the RFC1918 address is the one screaming "Too Boocoo!" but if it's some other box trying to tell it that the packets are too bug, no dice. Non-routable address. ------- John Fraizer (tvo) | __ _ The System Administrator | / / (_)__ __ ____ __ | The choice mailto:tvo@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste... On Fri, 16 Oct 1998, I Am Not An Isp wrote: > At 01:12 PM 10/16/98 -0400, tvo wrote: > >Doesn't this break MTU path discovery though? > > No, it wouldn't. Those addresses are not routable on the global 'Net, > however, there is nothing stopping a device with an RFC1918 address from > sending a packet onto the 'Net. > > Assume you have a T1 between two routers, but you are out of 'normal' > addresses. So you make the two serial ports 10.1.1.1 and 10.1.1.2. > Simple, huh? Well, anyone outside your network attempting to reach those > addresses will fail - there is no route to 10.x.x.x on the Internet. (At > least not in *my* network. :) Let's further assume there's a LAN on the > other side of this T1 with a MTU below 1500 bytes. Now, when you attempt > PMTU discovery to a device on that small MTU LAN (going through the T1 of > course), what happens? When the router on the opposite end of the T1 gets > the packet, it sees that the packet is "too big" and DF bit is set (as per > PMTU rules) and cannot send the packet. So what should it do? Why send an > ICMP "Datagram Too Big" error message, of course. (Type 3, "Destination > Unreachable", Code 4, "fragmentation needed and DF set". See RFC 1191, > http://www.pmg.lcs.mit.edu/cgi-bin/rfc/view-plain?number=1191, and RFC 792, > http://www.pmg.lcs.mit.edu/cgi-bin/rfc/view?792, for more info.) Just like > any other (properly functioning) router on the Internet. But what's the > source address? Why 10.1.1.1 of course. So you get a packet from RFC1918 > space. Perfectly normal, perfectly acceptable, perfectly legitimate. > > See, when a router gets a packet, it does not look at the source IP for > routing info. (Unless you're doing something weird like policy routing.) > So the source IP is irrelevant to a router. Hell, even the destination IP > is irrelevant as long as it's 32 bits and matches something in the router's > table (including a possible default route). I have never seen a router > vendor treat a packet with RFC1918 space in source or destination any > differently than any other packet. Unless, of course, the user manually > modifies the default behavior with filters or something - which can be done > to any address just as easily. > > The point is, there is magical router fairy looking for RFC1918 space and > removing all those packets from your network. Those addresses are treated > by your router just like *any other address*. Forwarded, filtered, > whatever depending upon the rules you set up and the information it > receives dynamically. > > I hope that explains everything. > > TTFN, > patrick > > I Am Not An Isp > www.ianai.net > "Think of it as evolution in action." - Niven & Pournelle >

1 0

Re: Maybe I'm misreading this but...
by Dean Anderson 17 Oct '98

17 Oct '98

Yes. --Dean At 01:12 PM 10/16/98 -0400, tvo wrote: >Doesn't this break MTU path discovery though? > > > >------- >John Fraizer (tvo) | __ _ >The System Administrator | / / (_)__ __ ____ __ | The choice >mailto:tvo@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU >http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation > A 486 is a terrible thing to waste... > >On Wed, 14 Oct 1998, I Am Not An Isp wrote: > >> At 05:11 PM 10/14/98 -0400, Barry Shein wrote: >> > >> >The following traceroute seems to indicate, according to ARIN, that >> >someone is running routers for spammers in the IANA Reserved netspace? >> >> [SNIP] >> >> >> 8 bs-jackson-gw.customer.alter.net (157.130.65.226) 107 ms 132 ms 96 ms >> >> 9 172.17.80.46 (172.17.80.46) 59 ms 53 ms 44 ms >> >>10 172.21.210.18 (172.21.210.18) 122 ms 96 ms 49 ms >> >>11 209.149.111.17 (209.149.111.17) 53 ms (ttl=118!) 58 ms (ttl=118!) >> 150 ms (ttl=118!) >> >> >What's going on here? >> >> Barry, 172.16.0.0/12 is part of RFC1918 space. There is no prohibition of >> addressing routers with these addresses, and in fact I do not know of a >> router that will route RFC1918 space differently than any other IP address. >> (Of course, you can put in filters, and many people do, but you can filter >> any addresses exactly the same way.) This is a perfectly legitimate use of >> RFC1918 space, as long as those hosts expect no connectivity outside their >> own network. Many people use RFC1918 on WAN links and whatnot to preserve >> their ARIN allocations for "real" hosts. Read the RFC for more info. >> >> > -Barry Shein >> >> TTFN, >> patrick >> >> I Am Not An Isp >> www.ianai.net >> "Think of it as evolution in action." - Niven & Pournelle >> > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3 2

DNS for aol.com
by bryan s. blank 17 Oct '98

17 Oct '98

this doesn't look good ;( [rs.internic.net] Registrant: America Online (AOL-DOM) 12100 Sunrise Valley Drive Reston, VA 20191 US Domain Name: AOL.COM Administrative Contact: O'Donnell, David B (DBO3) PMDAtropos(a)AOL.COM 703/265-5666 (FAX) 703/265-4003 Technical Contact, Zone Contact: America Online (AOL-NOC) trouble(a)AOL.NET 703-265-4670 Billing Contact: Barrett, Joe (JB4302) BarrettJG(a)AOL.COM 703-453-4160 (FAX) 703-453-4001 Record last updated on 15-Oct-98. Record created on 22-Jun-95. Database last updated on 16-Oct-98 04:27:25 EDT. Domain servers in listed order: DNS1.AUTONET.NET 206.88.0.34 DNS2.AUTONET.NET 206.88.0.66 The InterNIC Registration Services database contains ONLY non-military and non-US Government Domains and contacts. Other associated whois servers: American Registry for Internet Numbers - whois.arin.net European IP Address Allocations - whois.ripe.net Asia Pacific IP Address Allocations - whois.apnic.net US Military - whois.nic.mil US Government - whois.nic.gov SECURE:{bryan@bryan:~:5}$ host -t ns aol.com a.root-servers.net + host -t ns aol.com a.root-servers.net Using domain server: Name: a.root-servers.net Address: 198.41.0.4 Aliases: aol.com name server DNS1.AUTONET.NET aol.com name server DNS2.AUTONET.NET SECURE:{bryan@bryan:~:6}$ host -t ns aol.com b.root-servers.net + host -t ns aol.com b.root-servers.net Using domain server: Name: b.root-servers.net ddress: 128.9.0.107 Aliases: aol.com name server DNS2.AUTONET.NET aol.com name server DNS1.AUTONET.NET SECURE:{bryan@bryan:~:7}$ host -t ns aol.com c.root-servers.net + host -t ns aol.com c.root-servers.net Using domain server: Name: c.root-servers.net Address: 192.33.4.12 Aliases: aol.com name server DNS1.AUTONET.NET aol.com name server DNS2.AUTONET.NET SECURE:{bryan@bryan:~:8}$ host -t ns aol.com d.root-servers.net + host -t ns aol.com d.root-servers.net Using domain server: Name: d.root-servers.net Address: 128.8.10.90 Aliases: aol.com name server DNS1.AUTONET.NET aol.com name server DNS2.AUTONET.NET |o|----------------------------------------------------------------------|o| |o| bryan s. blank (203)-351-1178 voice |o| |o| senior systems analyst (203)-351-1186 fax |o| |o| discovernet, incorporated (203)-979-5126 emerg |o|

2 1

The Cidr Report
by Tony Bates 17 Oct '98

17 Oct '98

This is an auto-generated mail on Fri Oct 16 12:00:00 PDT 1998 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 16Oct98 0) General Status Table History ------------- Date Prefixes 091098 52585 101098 52353 111098 52340 121098 52520 131098 52587 141098 52544 151098 52663 161098 53167 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: 4110 Number of ASes announcing only one prefix: 1971 (1039 cidr, 932 classful) Largest number of cidr routes: 343 announced by AS3561 Largest number of classful routes: 942 announced by AS701 1) Gains by aggregating at the origin AS level --- 16Oct98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1785 668 390 278 41.6% NYSERNet Backbone AS271 346 149 197 56.9% BCnet Backbone AS4293 420 247 173 41.2% IMCI AS3749 229 71 158 69.0% TECNET AS2493 356 202 154 43.3% iSTAR Internet, Inc. AS174 696 563 133 19.1% Performance Systems International AS701 942 815 127 13.5% Alternet AS4200 191 98 93 48.7% AGIS (Apex Global Information Ser AS5668 129 42 87 67.4% Century Telephone Inc. AS7046 262 187 75 28.6% UUNET-CUSTOMER AS3221 118 44 74 62.7% EENet Autonomous System AS3804 228 155 73 32.0% Bell Solutions AS4755 120 55 65 54.2% Videsh Sanchar Nigam Ltd. India AS4740 400 336 64 16.0% Ozemail Pty Ltd (ASN-OZEMAIL) AS8517 126 73 53 42.1% ULAKNET-ASN AS7545 116 64 52 44.8% TPG Internet Pty Ltd AS6335 71 19 52 73.2% NTRNET AS72 87 39 48 55.2% Schlumberger Information Network AS549 194 147 47 24.2% ONet Backbone AS1239 538 491 47 8.7% SprintLink Backbone AS1221 360 314 46 12.8% AARNET-AS AS803 77 33 44 57.1% SaskNet Backbone AS852 165 124 41 24.8% AGT Advance Communication AS7122 123 83 40 32.5% MTS ADVANCED Network Policy AS4539 68 28 40 58.8% NETROPOLIS AS10928 87 48 39 44.8% UNKNOWN AS6181 64 30 34 53.1% FUSE-NET AS2707 64 31 33 51.6% WEC AS7496 66 35 31 47.0% Power Up AS3564 65 34 31 47.7% Microserve Infromation Systems In 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

RE: Gigarouter
by Greg Mirsky 16 Oct '98

16 Oct '98

Rogerio, these are not REAL gigarouters. Real once yet to come ;). Stay tuned Greg > -----Original Message----- > From: Rogerio Alvarez - DRS23 [SMTP:rogerio@embratel.net.br] > Sent: Thursday, October 15, 1998 9:36 AM > To: nanog(a)merit.edu > Cc: eng-l(a)embratel.net.br > Subject: Gigarouter > > Hi. > > Anyone there has any information (experience) about Gigarouters like > GRF1600 (Ascend) or > GSR12000 (Cisco). > > I want to know performance, availability, scalability and limitations > data in "real world", > I mean in real condition of internet traffic. > > Thanks in advance. > > Rogerio

4 3

SONET ring questions
by Peter Polasek 16 Oct '98

16 Oct '98

This is my first posting to the NANOG list. I don't think this is off-topic, but if so, please send replies (or flames) directly to me (rather than to the list) and I will issue a detailed summary. We are in the process of implementing an OC-12 SONET ring connection between two sites in New Jersey that span a distance of 15 miles. The SONET ring will be provided by Bell Atlantic and is composed of fully redundant hardware (there are no single points of within the telecom equipment) and redundant rings. We are splitting the OC-12 into pairs of OC-3's on two routers in each location (running ATM on the WAN). This interface is extremely mission critical to the point that a 99.9% uptime will not be acceptable. I have the following questions: 1) Bell Atlantic assures us that, because of the redundancy, we can expect 100% uptime from the OC-12. I would like feedback as to whether this is a realistic portrayal of the SONET environment. 2) We have the option of using either single-mode or multi-mode fiber OC-3 connections - what factors should be considered in selecting the fiber media type. 3) Which routers should be used. The options are 3com NB-II's DPE+ (dual CPU), Cisco 7200 series, or Cisco 7500 (each router will have at least two 100Base-T LAN ports). OK, I know the 3com suggestion is a loaded question for this list, but has anybody used the 3com's in this capacity? We are a 3com shop that is considering switching to Cisco - this is a significant decision because switching will require us to continue to maintain the existing 3com environment (~500 routers) and the new Cisco routers. Thanks, Peter Polasek

3 2

Re: IGPs in use
by alex＠nac.net 16 Oct '98

16 Oct '98

I'd have to definatly disagree. IGP wise, EIGRP is easy and fast and it works. If ou need a *lot* of interoperability, use OSPF. Friends don't let friends use BGP as an IGP On Mon, 12 Oct 1998, Megatron wrote: > > I would say the most interior Routing Protocol that is out there is > BGP. It gives a better control of route announcements. > > -Megatron > > > On Mon, 12 Oct 1998, Andre' Zehl wrote: > > > > Is there an overview on what the dominantly used interior routing > protocols are percentagewise in large AS backbones (IBGP, OSPF, IGRP, > EIGRP, IS-IS, any?). I don't want to start religous wars on what's the > best protocol, I'm rather interested if there is an overview available > on the facts of protocols used. Is there an "objective" > (vendor-independent) feature-based overview on the compared > advantages/disadvantages (especially regarding redistribution) of the > various protocols that goes with those numbers? > > Andre' > > > zehl(a)berkom.de > > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. Atheism is a non-prophet organization. I route, therefore I am. Alex Rubenstein, alex(a)nac.net, KC2BUO, ISP/C Charter Member Father of the Network and Head Bottle-Washer Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834 Don't choose a spineless ISP; we have more backbone! http://www.nac.net -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

2 1

Gigarouter
by Rogerio Alvarez - DRS23 16 Oct '98

16 Oct '98

Hi. Anyone there has any information (experience) about Gigarouters like GRF1600 (Ascend) or GSR12000 (Cisco). I want to know performance, availability, scalability and limitations data in "real world", I mean in real condition of internet traffic. Thanks in advance. Rogerio

4 3