- Test - lists.nanog.org

Re: using IRR tools for BGP route filtering
by Danny McPherson 23 Jun '00

23 Jun '00

> As has been observed many times on NANOG, one of the advantages that a > circuit-switched network like the PSTN has over a packet-switched network > like the Internet is that the PSTN has leisurely call setup times and > relatively infrequent routing table lookups. No long-distance carrier > processes even 100 million phone calls in a day networkwide; yet there > are many routers which process billions of packets daily *per interface*. I suppose for one this depends on your definition of leisurely, though I certainly agree with your point. I believe the lack of pre-populated "forwarding tables" in the PSTN is also a major difference, and a major factor in circuit setup time... The comments regarding number allocation and portability were more so related to the attributes of PSTN datatbase (E800, LIDB, PVN, etc..) versus forwarding capabilities. -danny

1 0

The Cidr Report
by Tony Bates 23 Jun '00

23 Jun '00

This is an auto-generated mail on Fri Jun 23 12:00:00 PDT 2000 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 23Jun00 0) General Status Table History ------------- Date Prefixes 160600 80091 170600 79759 180600 80139 190600 79957 200600 79704 210600 80023 220600 80240 230600 80236 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 65.56.64.0/21 from AS2941 AS Summary ---------- Number of ASes in routing system: 7723 Number of ASes announcing only one prefix: 4350 (2384 cidr, 1966 classful) Largest number of cidr routes: 939 announced by AS701 Largest number of classful routes: 1047 announced by AS701 1) Gains by aggregating at the origin AS level --- 23Jun00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 439 151 288 65.6% BCnet Backbone AS7046 534 360 174 32.6% COQUI-NET PRTC Internet AS1221 583 411 172 29.5% TELSTRA-AS AS9269 192 50 142 74.0% Hong Kong CTI AS9706 154 21 133 86.4% Pusan Metropolitan City Office of AS2609 127 12 115 90.6% EUnet-TN AS7657 273 170 103 37.7% The Internet Group Limited AS9304 121 22 99 81.8% Hutchcity AS7545 167 68 99 59.3% TPG Internet Pty Ltd AS174 568 476 92 16.2% Performance Systems International AS6429 208 118 90 43.3% RDC-INTERNET AS7496 127 42 85 66.9% Power Up AS4293 326 241 85 26.1% Internal ASN for C&W AS705 340 260 80 23.5% ALTERNET-AS AS577 248 176 72 29.0% Bell Backbone AS724 229 158 71 31.0% DLA-ASNBLOCK-AS AS9557 97 29 68 70.1% Pakistan Telecommunication Compan AS701 1047 981 66 6.3% Alternet AS1727 148 82 66 44.6% MRMS-WEST AS3602 305 245 60 19.7% Sprint Canada Inc. AS3749 118 59 59 50.0% TECNET AS5106 87 29 58 66.7% AADS-COLUMBUS AS6595 106 49 57 53.8% DODDSEUR AS4740 329 273 56 17.0% Ozemail Pty Ltd (ASN-OZEMAIL) AS7018 541 487 54 10.0% AT&T WorldNet Service Backbone AS7568 70 17 53 75.7% C.S. Communications Co., Ltd. AS1785 363 314 49 13.5% NYSERNet Backbone AS209 264 216 48 18.2% Qwest Communications AS1 616 572 44 7.1% GTE Internetworking AS6499 96 55 41 42.7% Brooks Fiber Properties, Inc. 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

Orlando FL Fiber Cut
by Jeff Wheat 23 Jun '00

23 Jun '00

Time Warner Telcom is reporting a fiber cut between Maitland, FL and Kissimmee, FL. At this time (14:30 EDT 06/23/00) there is no ETR. Fiber crews are enroute. They state the cause of the cut was due to a power truck. Time Warner ticket number: #8824. This is in their terms "a massive cut". Regards, Jeff

1 0

Re: Generally accepted announcement sizes
by Sean Butler 23 Jun '00

23 Jun '00

At 05:23 PM 6/22/00, Daniel L. Golding wrote: >BTW - I find /24 to be fairly common. Some folks are more restrictive, >using the ARIN /20 issuance guideline as a filter policy. www.nanog.org >has a few filter policies listed. The link to Sprint's filter policy is broken, but rumor has it they now accept up to /24 in any space. So does this mean Verio is the only big provider still filtering based on ARIN allocation lengths? /Sean

3 2

GT NOC Contact?
by ww＠shadowfax.styx.org 23 Jun '00

23 Jun '00

Is there someone from Group Telecom on this list who can deal with BGP? Or knows the NOC phone number? Thanks, -w -- Will Waites Network Engineer Wiznet Inc. ww(a)wiznet.ca

1 0

Re: using IRR tools for BGP route filtering
by Michael Shields 23 Jun '00

23 Jun '00

In article <200006230005.SAA11801(a)tcb.net>, Danny McPherson <danny(a)tcb.net> wrote: > It's interesting that for quite a while nearly 30K PSTN 800 numbers > were allocated nearly every week, with number portability and all. > Perhaps we're simply missing something :-) As has been observed many times on NANOG, one of the advantages that a circuit-switched network like the PSTN has over a packet-switched network like the Internet is that the PSTN has leisurely call setup times and relatively infrequent routing table lookups. No long-distance carrier processes even 100 million phone calls in a day networkwide; yet there are many routers which process billions of packets daily *per interface*. -- Shields.

1 0

Re: exchange point media (was: Re: MAE-EAST Moving? ...)
by Martin Cooper 23 Jun '00

23 Jun '00

Alex Bligh <amb(a)gxn.net> writes: > LINX also runs mixed media (sadly) - FDDI and more sane things (GigE > and Fast Ethernet). The switches here fragment when switching toward > Fast Ethernet. They would certainly move >1500 byte pings between > FDDI ports, but I have no FDDI ports now to test whether this works > with DF set (i.e. it doesn't fragment FDDI to FDDI), nor whether > ICMP is *ever* generated. Maybe I'm being ultra-thick here, but what business do layer-2 devices have looking at the contents of layer-3 packet headers and acting on what they find there? I thought the whole point of building IXPs at layer-2 was to leave layer-3 policies to the participants - if not then one might as well start building IXPs with routers surely? > However, I believe best practice at LINX is, and perhaps should > be elsewhere, to set MTU on your FDDI interfaces to that supported > by ethernet. Given most exchanges started with ethernet and worked > upwards, this should have been best practice everywhere from teh > start. This seems to me to be exactly the right thing to do in the context of exchange point fabrics composed of mixed MTU media, irrespective of the presence or absence of such schizoid layer-2 devices as those that have been discussed here. M.

1 0

Re: using IRR tools for BGP route filtering
by Jessica Yu 23 Jun '00

23 Jun '00

--- Danny McPherson <danny(a)tcb.net> wrote: > > > I agree with this, and have seen the document, and > have worked for > large providers that performed prefix filtering on > customers long > before IOPS existed. I know that some ISPs have been doing that but that is not good enough. The key is to have EVERY ISP do it to leave no 'holes' for bad routes to sneak in. And that's the model suggested in the paper. > > However, if every ISP performed prefix-based > filtering between one > another, it'd be improved "a lot more". I recall > more than a few > instances when providers inadvertently broke other > providers customers > by "mis-advertising" prefixes. Agree. The ideal situation is to filter on all interface where external routes come in i.e. filter on peers and customers. I used to work for an ISP (ANS) who filtered all its peers and managed to automatically generate router configurations including huge no. of prefix filtering lines. It did help us to dodge the disaster of AS7007 and other similar incidents. However, it does introduce a lot more work. Also, the toughest part is how often to update the filtering list so no legitimate prefixes be blocked. How big a filter list a router can handle in its configuration is something needs to be investigated since number of prefix lines will be huge for peer to peer filtering. In conclusion, the best is for ISPs to filter on peers and customers. But if they can not do that for peers, at least filter on customers. If all ISPs filter its customers, it's already a big step forward. > > And if every ISP performed SA verification between > one another > (presumably with the same filters) it would again be > improved "a > lot" more. > > -danny --jessica > > > If every ISP does prefix based filtering on its > > downstream customers, the integrity of the > Internet > > routing system will be improved a lot. The > document > > below proposes such a model: > > > > http://www.iops.org/Documents/routing.html > > __________________________________________________ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/

1 0

RE: Generally accepted announcement sizes
by Mike Heller 23 Jun '00

23 Jun '00

The 216.73.19.128/25 is a legacy network that I am renumbering off of. I agree that it is too small of a network to be seen consistently. When my verio connection went down the other day, the 165.254.159/24 netblock did not appear in the cerf routeserver and verio wasn't seeing my announcement at all either. It seems that they filter announcements from 128/8 to the /19 and larger thereby filtering my announcement out. The above two are my office networks. The 209.10.180/24 is my production network and I peer directly with GBIX, UUnet, and SPrint. I had no problems there. Thanks for your input, Mike -----Original Message----- From: Kai Schlichting [mailto:kai@pac-rim.net] Sent: Thursday, June 22, 2000 7:33 PM To: Mike Heller Cc: 'nanog(a)merit.edu' Subject: Re: Generally accepted announcement sizes At Thursday 05:35 PM 6/22/00 , Tony Tauber wrote: >On Thu, 22 Jun 2000, Mike Heller wrote: > > > > Can anyone point me to a centralized resource for Tier 1 and Tier2 > > providers' accept policies? I have found that when some of my circuits go > > down various parts of the 'Net become unreachable and I attributed that to > > the size of that announcement being a /24. I assume that the carriers I'm > > having issue with are not using RADB as I registered all of my netblocks, > > >To find out exactly why your multi-homing set-up isn't working, >I'd work with your providers' operations staff. Perhaps set up >a time to test the fail over with them on hand to help you analyze >by looking at the routes on both. It should be possible for them >to help check the behavior of traffic over a third provider as well >if the providers are worth their salt. A rather complex setup on their side, as far as I can tell from route-server.cerf.net, route-views.oregon-ix.net and route-server.ip.att.net: iwon.com is AS 14829, and they seem to announce 3 networks: They announce 165.254.159.0/24 to AS 2914 (Verio) and AS 1785 (AppliedTheory) At the Oregon IX, the path via Verio is seen 15 times, via AT only 2 times. That's is an indicator of connectivity (and likely density of interconnectivity of providers to Verio vs. AT) right there. It's more balanced 5:4 (Verio:AT) at AT&T's route view. They announce 209.10.180.0 to AS 701 (UUnet), 4513 (PFM/Globix), 1239 (SL). At the Oregon IX, this is seen somewhat balanced between the 3, but at AT&T, it's 8 paths to UUNet or SL, only one path to PFM/Globix. They announces 216.73.19.128/25, which is solely seen through AS 2914 (Verio) at the Oregon-IX, and only 4 times at that. As expected, Verio seems to accept this as a customer route, but few of their peers accept the /25, Note that AT&T and CERF.net are not seeing this specific, but they see the larger /18 aggregate from AppliedTheory only, which is probably what 90% of all traffic to this network . It's a wonder that the /25 is seen at all: I think it should be withdrawn for sanity's sake. So, what exactly are you trying to accomplish, Mike? One thing is clear: the third network will always receive most traffic from AT, the second one mostly from UUnet+Sprint, the first one (which I believe you are referring to) mostly from Verio. The right way to overcome this is likely not to play with BGP toys like AS_prepend or making your providers manipulate the local_pref for you (and I see that Verio and UUnet don't seem to be crossing paths, at least for the first network listed), but by utilizing bigger networks: /22's in the >204.0.0.0/8 space are looking damn good in terms of 'being heard' compared to /24's. Did I mention that Verio seems to be the only one filtering at /20 boundary in 62/8 and 63/8 ? As a customer, you won't have that problem, obviously. bye,Kai

1 0

ATM resources?
by Steve Hardin 23 Jun '00

23 Jun '00

Hi, I was hoping someone good point me to some resources in the form of books on ATM. This would be for voice as well as Data? This would be for a real world implementation. Regards, Steve

3 2