- NANOG - lists.nanog.org

Re: [nanog] Re: Microsoft offering xDSL
by M. David Leonard 23 Jan '98

23 Jan '98

1 0

NANOG 12 REMINDER
by Pam Ciesla 23 Jan '98

23 Jan '98

Hotel room block expires on Sunday, 1/25. Registration fee for $150 due by Friday, 1/30. Payment after 1/30 is $170, cancellation after 1/30 $20 charge. My office hours 7:30AM - 3:30PM EST Information can be found on the NANOG Webpage http://www.nanog.org xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Pam Ciesla 734-936-0172 - phone Merit Network, Inc. 734-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

1 0

The Cidr Report
by Tony Bates 23 Jan '98

23 Jan '98

This is an auto-generated mail on Fri Jan 23 12:00:00 PST 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 23Jan98 0) General Status Table History ------------- Date Prefixes 160198 48136 170198 47944 180198 47971 190198 48017 200198 48183 210198 48498 220198 48637 230198 48658 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 212.192.0.0/16 from AS5568 *** Bogus 212.255.0.0/16 from AS2871 AS Summary ---------- Number of ASes in routing system: 3149 Number of ASes announcing only one prefix: 1462 (756 cidr, 706 classful) Largest number of cidr routes: 450 announced by AS3561 Largest number of classful routes: 1005 announced by AS701 1) Gains by aggregating at the origin AS level --- 23Jan98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 705 396 309 43.8% iSTAR Internet, Inc. AS6235 489 254 235 48.1% Intermedia Communications, Inc. AS4293 425 211 214 50.4% IMCI AS174 875 671 204 23.3% Performance Systems International AS816 581 404 177 30.5% UUNET Canada (ASN-UUNETCA-AS4) AS3602 453 301 152 33.6% Sprint Canada Inc. AS3749 201 60 141 70.1% TECNET AS701 1005 896 109 10.8% Alternet AS3751 123 47 76 61.8% SNET-AS AS2048 161 91 70 43.5% LaNet AS5668 106 40 66 62.3% Century Telephone Inc. AS3804 203 141 62 30.5% Bell Solutions AS1 846 787 59 7.0% BBNPLANET AS549 216 159 57 26.4% ONet Backbone AS271 111 56 55 49.5% BCnet Backbone AS3464 116 63 53 45.7% Alabama Research and Education Ne AS1239 578 526 52 9.0% SprintLink Backbone AS7545 114 66 48 42.1% TPG Internet Pty Ltd AS72 84 36 48 57.1% Schlumberger Information Network AS4763 127 79 48 37.8% Telstra New Zealand AS719 507 461 46 9.1% LANLINK autonomous system AS684 84 39 45 53.6% Manitoba Regional Network Backbon AS1221 257 212 45 17.5% AARNET-AS AS2711 97 55 42 43.3% SUNBELT-AS AS3561 922 881 41 4.4% MCI AS6335 62 24 38 61.3% NTRNET AS4740 333 295 38 11.4% ASN-OZEMAIL (Ozemail Pty Ltd) AS4682 62 24 38 61.3% ITJ Intelligent Telecom Inc., AS1691 161 123 38 23.6% BCTEL AS6332 83 46 37 44.6% TELNOR 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: [nanog] Re: Microsoft offering xDSL
by vaananen＠NASBPD01BS.ntc.nokia.com 23 Jan '98

23 Jan '98

>We are part of the Bell Atlantic ADSL trial in Northern VA - basically BA >has 6 CO's with terminating ADSL modems. This is aggregated onto a FDDI >ring between each CO on cisco's. One of the CO's has a port into the BA >SMDS cloud which is the interconnect with participating ISP's who also >have a port on the SMDS cloud. So basically, packetize the data as early >as possible to get the 20x plus economies of scale vs hauling channelized >circuits. > Hmm... as we are developing equipment for something like this, I would like to get the opinion of the real peoples (read ISPs)of the Cisco - Microsoft - Alcatel... etc. network architecture for the xDSL services (they are mainly talking of ADSL, but who cares). Basic idea is that the telco has xDSL links to subscribers and you are supposed to run ATM over that link. So the access network is "simple ATM network", with VP (or VC) connections from individual subscribers to your favorite ISP's or company network. PPP / L2TP over the ATM are the protocols of choice to run on top of ATM. I can see some problems with this, here are my favorite ones: 1.) If you are supposed to be ISP and get handled over the traffic of say 100k active users nicely encapsulated in PPP or L2TP, where are you going to terminate these PPP sessions ? (I am sure it's possible to construct "massive PPP terminator", but is it necessary ???) 2.) The idea seems to be that ordinary consumers suddenly need n Mbits/s (n=2-6) to home, one use for this (in addition to connecting to web server which is attached with T1 and serving 500 other customers at same time) is to "be able to access content like video". If this kind of bandwith becomes available for the ordinary customers, what's going to happen for backbone (answer is nothing, it should be something) ? Certainly things like multicasting would be required to deliver set of high bandwith services like video to subscribers. Problem with the "simple ATM access network" then becomes that if you are delivering your video nicely packed onto IP packets, you would like to duplicate as late as possible, which means in access network, instead of at the end of the PPP session (ISP). Pasi Ps. Sorry for non-operational posting, but there is not better place to reach the ISPs in states than NANOG list. ----------------------------------------------------------------------- Pasi Vaananen, Senior Systems Engineer pasi.vaananen(a)ntc.nokia.com Nokia Telecommunications, Network Systems, IP Networking -----------------------------------------------------------------------

2 1

Re: [nanog] Re: Microsoft offering xDSL access
by Vadim Antonov 23 Jan '98

23 Jan '98

Paul Vixie wrote: >Nobody in their right mind would sell T1 to every customer and do 1000:1 >overcommit of their transit links without some kind of bandwidth shaping. Well, i strongly doubt anyone would need to do that. Right now, there's enough long-haul fiber capacity in US to provide _all_ current Internet customers with full T-1s. Some carriers (Qwest for example) are already in terabit range in terms of raw capacity. Switching capacity is an entirely different beast :) Caching is not a panacea; it is not going to reduce traffic by even an order of magnitude. Simply put, the diversity is way too high. A year worth of Internet growth... I would rather think of cacheing as means to reduce load on very popular servers, not as something crucial to fixing backbone capacity problems. --vadim

1 0

Re: RLBM (un"protection" meathod)
by sully＠mail.usinternet.com 23 Jan '98

23 Jan '98

>>The "no ip directed-broadcast" directive, if applied to all router >>interfaces, will prevent your site from being a bounce site in the smurf >>attack. Unfortunately, it will not prevent you from being the end victim. > >So, the education initiative is that *you* and *I* need to explain to >the masses why this needs to be done, no? We even have tee shirts. :-) > Well, it certainly is here....its on my borderline router now (in a few mins). Thanks Paul! ------------------------------------------------------------------ Tim Sullivan Senior Technical Support/Network Consultant http://www.usinternet.com US Internet Corp - Full Service Internet Provider MN Based, running Windows NT, connected directly to the Backbone. "Get your Net's Worth" (tm) (612) 222-4638 ------------------------------------------------------------------

1 0

Re: Being blackhole by some one.
by sully＠mail.usinternet.com 23 Jan '98

23 Jan '98

Are you being BGP'ed blackholed? Like, one of their routers is lying about a route it owns? At 10:35 AM 1/23/98 PST, you wrote: >> We just being blackhole by some ISP during their provisioning, >> a few hours ago. I thought that bogus route should be filtered by >> the NAP. Is there a way to prevent from somebody blackholing you ? >> It takes a lot of affort to solve this problem, especially those >> who need to update their router through rrdb automatically. Which >> suppose to solve blackhole problem accidentally. > >Could you please explain the issue more specifically. "Blackhole" could >have many meanings. > >randy >

1 0

Re: RLBM (un"protection" meathod)
by Sam Birch 23 Jan '98

23 Jan '98

-----Original Message----- From: Paul Ferguson <ferguson(a)cisco.com> To: Eric Osborne <osborne(a)notcom.com> Cc: Dave Van Allen <dave(a)fast.net>; eric(a)ccti.net <eric(a)ccti.net>; nanog(a)merit.edu <nanog(a)merit.edu> Date: Thursday, January 22, 1998 11:00 AM Subject: Re: Reporting Little Blue Men >At 10:55 PM 1/21/98 -0500, Eric Osborne wrote: > >>How do you prevent packets from your network with a broadcast address, since >>what defines a "broadcast" address really depends on the subnet mask? >> > >"no ip directed-broadcast" > >- paul > That directive on the router will only protect the network of the router interface it is put on. For example, if I have: ! hostname Router1 ! interface Ethernet0 ip address X.Y.Z.1 255.255.255.0 no ip directed-broadcast ! "ONLY" X.Y.Z.0 will be protected from someone trying to use "ping X.Y.Z.255" as a bounce site. No other networks beyond the one I have defined with my subnet mask will be protected. The reason I know this is because I was hoping this directive would be an easy fix...but when I checked it out, the hole in my logic became apparent. If anyone has experienced different, I would be interested in hearing the IOS used and the setup of the router. The "no ip directed-broadcast" directive, if applied to all router interfaces, will prevent your site from being a bounce site in the smurf attack. Unfortunately, it will not prevent you from being the end victim. The only way I can think of to stop your site from being a victim is to do one of two things: 1) block all ICMP (type 8, in particular) or 2) Have some type of firewall device that keeps track of all ICMP requests coming from your site with the intent to block any ICMP responses that do not match a request. Option 1 is not possible for most, and I currently don't know of a proxy/firewall/etc... that will track ICMP in this way. If anyone does, please let me know! Sam Birch

2 1

Re: Reporting Little Blue Men
by Dennis Simpson 23 Jan '98

23 Jan '98

> From: Dean Anderson <dean(a)av8.com> > > But when you take the step from advocacy to actions you are violating the > law in almost every case. You can advocate anything, but you can't go > tearing down buildings, or in this case, intercepting communications. Filtering packets is not interception, it is disregard. If I ignore your packets and do not pass them to the next machine in the link, I am not intercepting your communications, I am ignoring them. Unless you are paying me to do so, I have no obligation to carry your packets. If my server checks message headers to determine validity before transferring to a spool file, I am not intercepting, I am determining message routing. As above, if you aren't paying me, I have no obligation to deliver something you handed me for delivery. Or are you suggesting mail servers should deliver mail without determining who it is for? If I review the content of your message, and then make decisions about who gets to read it (as opposed to discarding it), then I am intercepting, and reprehensible. I cannot block mail espousing causes I disagree with, but I have no obligation to deliver them either. Find yourself another path to my client; I won't do anything to permit or prevent it. I am not blocking you. I am also not assisting you. That is neither illegal nor immoral. SPAM yourself silly. dennis

10 11

Reporting Little Blue Men
by Eric Wieling 23 Jan '98

23 Jan '98

Just about every night someone(s) tries to use us as the "innocent third party" in smurf attacks. Of course, we block and log all the broadcast packets. Is there any point in trying to report these attacks? Who would we report them to? We don't know what the source is, after all the address is spoofed. It seems kind of pointless to notify the victim -- they already know they have been smurfed. I want to do my part to try to stop attacks, but I'm baffled on this one. --Eric -- Eric Wieling (eric(a)ccti.net) Chesapeake Communications Corporation Sales: sales(a)ccti.net 504-585-1850, Support: support(a)ccti.net 504-525-5449 We have changed our name! Corporate Communications Technology is now known as Chesapeake Communications Corporation.

16 18