November 2001 - Test - lists.nanog.org

bandwidth prices
by allan＠alum.mit.edu 03 Nov '01

03 Nov '01

So what have people been getting for prices for CO to CO bandwidth per DS0 mile? allan

1 0

Fwd: Q: Sizes of Existing and Planned Fully Meshed IPSEC VPN (Tunnel Mode)
by Rodney Thayer 03 Nov '01

03 Nov '01

I assume "fully meshed" means each node connects to each other node, so each node has 109 tunnels (110 total). I also assume "Cisco IPSEC based VPN" means IPsec (rfc 2401/2411/etc.) and not MPLS-only. In that case, 120 is not 'large' according to the vendor community -- 'large' starts at around 5000 tunnels. I suspect that, in nature (or in the land of the Nanogians) that under 1000 is more like a 'large' one. On the other hand, drop one box with 119 tunnels set up and restart it and time how long it takes to re-initiate all 119 tunnels, and you may very well be unhappy. >From: "Tim Bass" <bass(a)silkroad.com> >We have a Cisco IPSEC based VPN with over 110 edge routers >in a full tunnel-mode mesh, mostly 'big hunking routers' with >average CPU utilization under 15 percent. The VPN is >controlled by a single organization, under centralized admin.

3 2

Q: Sizes of Existing and Planned Fully Meshed IPSEC VPN (Tunnel Mode)
by Tim Bass 03 Nov '01

03 Nov '01

Lots of old and dear friends in NANOG to say HELLO!, it has been many, many years since I've posted here. Hopefully this very simply question will not be very controversial :) I did a search of the archives on VPN with keywords 'size' and 'mesh' only to find a thread debating the merits of MPLS. This was an interested thread and some of my old and dear friends were active in that discussion. Please allow me to ask a simple less-technical question. My apologies if this has been discussed and I missed it in the archives. We have a Cisco IPSEC based VPN with over 110 edge routers in a full tunnel-mode mesh, mostly 'big hunking routers' with average CPU utilization under 15 percent. The VPN is controlled by a single organization, under centralized admin. Are there larger fully meshed VPNs out there in ISP land? Are there any 'real-tangible issues' with a fully meshed VPN at the size we are talking (around 120 sites fully meshed)? The marketing hype tends to be great. I like -vadim's closing comments in: http://www.merit.edu/mail.archives/nanog/2001-08/msg00311.html as follows: "Sometimes older ways are simply better." --vadim This seems to be true regarding a simple fully-meshed IPSEC VPN in tunnel-mode, right NANOG geniuses? Is 110 fulled meshed edge routers considered big?? Finest Regards, Tim www.silkroad.com

2 1

slightly OT : versign complaint department
by beldridg＠best.com 03 Nov '01

03 Nov '01

i've been trying to add a pgp key to the verisign/netsol database for the past two weeks. i've sent four messages, opened three web help requests, and spent three hours on the phone with their helpdesk. they know less than their customers about their own procedures and web documentation for adding keys for PGP guardian auth. i guess this is the problem with government sanctioned monopolies. i'd like to do something about it. does anybody know if there is a formal board or governing group that i can send my grievances to? - brett

10 11

(no subject)
by Zhao, Xingguo 03 Nov '01

03 Nov '01

Hi, all I have a question regarding to redistribute IGR routes into BGP. Currently both Cisco and Juniper support it. Here I don't understand what is the advantage of this redistribution? Because BGP is potentially injecting information into the IGP and then sending such information back into BGP. Could anybody provide more description regarding the advantage and the disadvantage of redistribuing IGP routes into BGP? Do people use this in real life? Thanks a lot, Xingguo

7 12

Confidential outage Saturday October 20 2001
by Sean Donelan 03 Nov '01

03 Nov '01

The first one I've seen. A carrier filed a confidential outage report with the FCC for an outage on Saturday October 20. http://www.fcc.gov/Bureaus/Engineering_Technology/Filings/Network_Outage/20… So, did any customers of the unknown carrier notice an outage?

1 0

The Cidr Report
by CIDR Report 03 Nov '01

03 Nov '01

This is an auto-generated mail on Fri Nov 2 23:00:01 PST 2001 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. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. 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 GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 02Nov01 0) General Status Table History ------------- Date Prefixes 271001 104354 281001 104082 281001 104104 291001 104430 301001 103922 311001 103786 011101 103634 021101 103427 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 219.0.0.0/16 from AS17676 *** Bogus 219.1.0.0/23 from AS17676 *** Bogus 219.1.0.0/16 from AS17676 *** Bogus 219.2.0.0/16 from AS17676 *** Bogus 219.3.0.0/16 from AS17676 *** Bogus 219.4.0.0/16 from AS17676 *** Bogus 219.5.0.0/16 from AS17676 *** Bogus 219.6.0.0/23 from AS17676 *** Bogus 219.6.0.0/16 from AS17676 *** Bogus 219.7.0.0/16 from AS17676 *** Bogus 219.8.0.0/16 from AS17676 *** Bogus 219.9.0.0/16 from AS17676 *** Bogus 219.10.0.0/16 from AS17676 *** Bogus 219.11.0.0/16 from AS17676 *** Bogus 219.12.0.0/16 from AS17676 *** Bogus 219.13.0.0/16 from AS17676 *** Bogus 219.14.0.0/16 from AS17676 *** Bogus 219.15.0.0/16 from AS17676 *** Bogus 219.16.0.0/16 from AS17676 *** Bogus 219.17.0.0/16 from AS17676 *** Bogus 219.18.0.0/16 from AS17676 *** Bogus 219.19.0.0/16 from AS17676 *** Bogus 219.20.0.0/16 from AS17676 *** Bogus 219.21.0.0/16 from AS17676 *** Bogus 219.22.0.0/16 from AS17676 *** Bogus 219.23.0.0/16 from AS17676 *** Bogus 219.24.0.0/16 from AS17676 *** Bogus 219.25.0.0/16 from AS17676 *** Bogus 219.26.0.0/16 from AS17676 *** Bogus 219.27.0.0/16 from AS17676 *** Bogus 219.28.0.0/16 from AS17676 *** Bogus 219.29.0.0/16 from AS17676 *** Bogus 219.30.0.0/16 from AS17676 *** Bogus 219.31.0.0/16 from AS17676 *** Bogus 219.32.0.0/16 from AS17676 *** Bogus 219.33.0.0/16 from AS17676 *** Bogus 219.34.0.0/16 from AS17676 *** Bogus 219.35.0.0/16 from AS17676 *** Bogus 219.36.0.0/16 from AS17676 *** Bogus 219.37.0.0/16 from AS17676 *** Bogus 219.38.0.0/16 from AS17676 *** Bogus 219.39.0.0/16 from AS17676 *** Bogus 219.40.0.0/16 from AS17676 *** Bogus 219.41.0.0/16 from AS17676 *** Bogus 219.42.0.0/16 from AS17676 *** Bogus 219.43.0.0/16 from AS17676 *** Bogus 219.44.0.0/16 from AS17676 *** Bogus 219.45.0.0/16 from AS17676 *** Bogus 219.46.0.0/16 from AS17676 *** Bogus 219.47.0.0/16 from AS17676 *** Bogus 219.48.0.0/16 from AS17676 *** Bogus 219.49.0.0/16 from AS17676 *** Bogus 219.50.0.0/16 from AS17676 *** Bogus 219.51.0.0/16 from AS17676 *** Bogus 219.52.0.0/16 from AS17676 *** Bogus 219.53.0.0/16 from AS17676 *** Bogus 219.54.0.0/16 from AS17676 *** Bogus 219.55.0.0/16 from AS17676 *** Bogus 219.56.0.0/16 from AS17676 *** Bogus 219.57.0.0/16 from AS17676 *** Bogus 219.58.0.0/16 from AS17676 *** Bogus 219.59.0.0/16 from AS17676 *** Bogus 219.60.0.0/16 from AS17676 *** Bogus 219.61.0.0/16 from AS17676 *** Bogus 219.62.0.0/16 from AS17676 *** Bogus 219.63.0.0/16 from AS17676 AS Summary ---------- Number of ASes in routing system: 8829 Number of ASes announcing only one prefix: 4020 (4020 cidr, 0 classful) Largest number of cidr routes: 818 announced by AS701 Largest number of classful routes: 0 announced by 1) Gains by aggregating at the origin AS level --- 02Nov01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1214 934 280 23.1% Telstra Pty Ltd AS701 1368 1157 211 15.4% UUNET Technologies, Inc. AS4151 318 180 138 43.4% USDA AS16473 202 77 125 61.9% Bell South AS7018 807 688 119 14.7% AT&T AS577 297 183 114 38.4% Bell Advanced Communications Inc. AS6595 171 61 110 64.3% DoD Education Activity Network As AS4293 361 257 104 28.8% Cable & Wireless USA AS705 270 170 100 37.0% UUNET Technologies, Inc. AS2048 215 117 98 45.6% State of Louisiana AS271 157 70 87 55.4% University of British Columbia AS13999 110 23 87 79.1% Mega Cable S.A. de C.V. AS4755 217 134 83 38.2% Videsh Sanchar Nigam Ltd. Autonom AS1239 478 404 74 15.5% Sprint AS17557 141 69 72 51.1% Pakistan Telecom AS12302 106 36 70 66.0% MobiFon S.A. AS6471 132 66 66 50.0% ENTEL CHILE S.A. AS4200 131 66 65 49.6% Apex Global Information Services, AS19632 72 7 65 90.3% Metropolis Intercom S.A. AS3464 160 96 64 40.0% Alabama SuperComputer Network AS7046 316 253 63 19.9% UUNET Technologies, Inc. AS4323 296 237 59 19.9% Time Warner Communications, Inc. AS724 200 142 58 29.0% DLA Systems Automation Center AS209 307 250 57 18.6% Qwest AS16758 63 6 57 90.5% IKON Office Solutions AS703 270 218 52 19.3% UUNET Technologies, Inc. AS3908 297 246 51 17.2% Supernet, Inc. AS17561 110 59 51 46.4% Internet service provision to Wes AS376 122 73 49 40.2% Reseau Interordinateurs Scientiqu AS16814 64 17 47 73.4% NSS, S.A. 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: redistribute IGP routes to BGP
by Patrick W. Gilmore 02 Nov '01

02 Nov '01

At 11:54 AM 11/1/2001 -0600, Zhao, Xingguo wrote: > >I didn't get how this helps to make this redistribution useful. >Could you give me more hints? FWIW: I do not use it, and neither do most of the people I know - on ciscos. On Junipers, apparently they like you to do this, not sure why. On a cisco, many people say the route is already in the IGP (has to be to be advertised by BGP), so why not just redistribute with filters. I prefer to put the prefixes into BGP manually, and nail something to the loopback for the IGP. If you make a mistake in typing the prefixes in, you get a single route wrong. If you make a mistake in your filter during redistribution, all kinds of bad things can happen. My $0.00000000002. -- TTFN, patrick

1 0

Reportable Metrics
by Murphy, Brennan 02 Nov '01

02 Nov '01

I am trying to take stock of all the network tools we employ on our network and come up with a concise list of metrics I can compile from these to report to management on a rolling basis to reflect the health of our enterprise network. I've started a list and I was hoping others might help me out by adding to it. If a measurement you sugggest is not achieveable with a tool I have, I'll probably pester you and find out what you are using. But to keep it simple, I'm just looking for things to measure. Assuming a monthly reporting schedule, here's the list I have so far: 1. Uptime per WAN or Internet circuit 2. # and average length of outages 3. Bandwidth utilization per WAN/Internet circuit and "important" VLANs 4. Overall Network Latency, RTT measured from various parts of network (cisco IPM) to various other parts 5. Top talkers per WAN circuit 6. Top destinations per WAN circuit 7. Top 10 most utilized WAN circuits (% burst above CIR, etc) 7. Protocol distribution per WAN circuit 8. Syslog/Sniffer alarms by severity 9. Application Response time for key Apps (eg, SAP, HTTP) 10. Security Incidents 11. TACACs reports on number of logins, changes, etc 12. Bandwidth/Latency trending What am I missing? Thanks! -BM

2 1

Re: 214/8 and 215/8
by smd＠clock.org 01 Nov '01

01 Nov '01

| These were delegated on the return of nets 49 and 50, along w/ about a | /9 of mixed /16 and /24 space. e.g. an overall reduction in the | amount of space. Jon Postel, as the IANA, approved the transfers. | At that time, ARIN did not have control over legacy delegations. So I seem to be missing something that keeps me from understanding this -- why didn't they just turn off the /9 of mixed /16 and /24 space and keep the two pre-existing historical class-As, which would have more fully followed the BCPs? Sean.

4 3