- Test - lists.nanog.org

Summary: Reportable Metrics
by Murphy, Brennan 12 Nov '01

12 Nov '01

Here is a summary of a recent query I posted to the list. Reportable Metrics: Original Query: to identify a list of network metrics to compile and report to management on a monthly basis. (Emphasis is on metrics and not the tools used to gather them.) My original list: 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 Vince Mulhollan's additions: 1. acceptable use policy violations 2. number/severity of externally reported abuse complaints 3. IOS deployments: upgrades, schedules, risk/rewards of IOSs in use 4. Installations completed: hw and circuit changes. Time to implement each. 5. RFO: reasons for outages and remedies employed 6. Employees % of time spent on: upgrades, installs, security incidents, etc. Headcount in line with workload? 7. Any hardware related trends:, ie particular devices burning out frequently, etc. Establish loose figure of likelihood of failure per type of device Joe St Sauver's recommendations: 1. Don't overwhelm management with large quantity of data 2. Implement "management by exception" by tracking/reporting "material statistical deviations from expected values wherever possible. " 3. "The other key concept is to give management gauges that will help them drive the plane, rather than historical data that will tell them when/where/how badly they crashed (last month). E.G., make the data timely and operationally relevant." a. -- What's broken? b. -- Where am I vulnerable? c. -- Where am I running out of capacity? d. -- Where do I have performance problems? e. -- What are we doing really well? f. Where can I increase my return on already deployed assets? (e.g., where do I have underutilized capacity?)Look longitudinally (over time), geographically (spatially), and at snapshots (cross sectionally). 4. Focus on downtime as opposed to uptime and only report those that exceed some acceptable threshold. Focus on cause of outages and responses to those outages and whether there are ongoing problems in solving the issues. 5. Tie all measurements to realities of the business: stats that bear out billing expenses, those that might help marketing, or those that help in planning, etc 6. Dial-ins 7. A list of URLs for more ideas a. Compare and contrast: http://hydra.uits.iu.edu/~abilene/traffic/ http://monon.uits.iupui.edu/abilene/dnvr.html http://monon.uits.iupui.edu/abilene/dnvr/index.html http://monon.uits.iupui.edu/abilene/dnvr/uoreg-bits.html http://www.itec.oar.net/abilene-netflow/ b. Latency, packet loss, route changes: i. http://amp.nlanr.net/active/amp-uoregon/HPC/body.html ii. http://www.advanced.org/surveyor/ iii. http://www.caida.org/cgi-bin/skitter_summary/main.pl iv. http://www.ncne.nlanr.net/nimi/ c. Possible breakdown on top WAN talkers: i. Single flow? Aggregate traffic? By protocol? By port? Per dotted quad? Per network block? Per ASN? Measured by octets? Flow count? Flow duration? From flow data? Passive monitoring with OCxMON type tools? Privacy issues? ii. Sample report: http://www.canet3.net/stats/reports.html 8. :-) "Keep it brief." Iljitsch van Beijnum: 1. Interface stats a. CRC errors, (helps identify lower layer problems) b. collisions, if you use any non-switched ethernet 2. router CPU load Joe Provo: 1. Errors: CRCs, queue drops/depth (eg, RED vs tail-drop queues) 2. Routing protocol transitions where relevant, eg, BGP route table size 3. "You should look at SNIPS [formerly NOCOL] for examples of good stuff to monitor [&*therefore trend]. David Newman: 1. For delay-sensitive, include: a. jitter (latency variation) b. histograms (latency distribution) Thanks to everyone who responded! If you have more suggestions for this list, please email me directly. -BM

1 0

Plane crash in Queens
by Ryan Tucker 12 Nov '01

12 Nov '01

Within the last hour, an American Airlines jetliner (Airbus A300, flight 587) crashed into Queens, apparently on departure from JFK. Details are sketchy (as usual), but news sites are very overloaded (as usual). It does not immediately appear to be a terrorist attack. NYC has gone into lockdown mode. -rt -- Ryan Tucker <rtucker(a)netacc.net> Network Operations Manager, NetAccess, Inc. http://www.netacc.net/ • (585)419-8252

7 7

Afghan phone links
by Sean Donelan 12 Nov '01

12 Nov '01

Since the 1991 Gulf War news stories about the net and communication links during the war have been common. Afghanistan has a limited wireless network, but it continues to function. There have only be a few press articles on the subject of communications this time. They New York Times has an article about the Afghan Wireless network. http://www.nytimes.com/2001/11/12/international/asia/12CELL.html US Military forces destroyed the international wireline office in Kabul last month. I don't know of any web site or host currently operating within the physical borders of Afghanistan. Afghan Wireless, like all the other Afghan web sites, are hosted in other countries.

1 0

wireless traffic
by Art Houle 11 Nov '01

11 Nov '01

Does anybody know where I can locate a list of MAC address prefixes that belong specifically to wireless NIC cards? I am looking for a method of discovering what devices on my network are wireless devices. Art Houle e-mail: houle(a)acns.fsu.edu. Academic Computing & Network Services Voice: 850-644-2591 Florida State University FAX: 850-644-8722

9 11

RE: Fwd: Re: Digital Island sponsors DoS attempt?
by Paul A Vixie 11 Nov '01

11 Nov '01

for some reason the list wasn't cc'd on this informative reply to my earlier rant. in case the sender wanted to remain anonymous, i'm stripping headers: ------- Forwarded Message From: ... To: "Paul Vixie" <paul(a)vix.com> Subject: RE: Fwd: Re: Digital Island sponsors DoS attempt? Date: Sat, 10 Nov 2001 19:12:22 -0500 > Without that argument, there's a clear path to "since your customers have > no choice, you are not allowed to filter content." While this probably > applies to DSL since it's "like telco" and there's already legislation > about what telcos can't filter because of their old "natural monopoly" > status, Paul, I don't think it's been tested in the courts, but I think you're sorely mistaken there as far as ISPs(!; unregulated side) operated by telco's being able to filter things. The Telco ISPs typically are on the unregulated side, including my employer ... The ILEC typically doesn't operate any public IP devices. Sure, they could filter, but presently it just looks like one ATM cell like the next ATM cell. And, beyond that, nobody has said anything against ILECs offering network based filtering services (which would be initiated per customer's request on devices like the Shasta). Bottm line is, you presume that the RBOC's ISPs are all regulated, which they're not. They're in a huge gray zone to be exact. Anyways, ... ------- End of Forwarded Message

1 0

Re: Fwd: Re: Digital Island sponsors DoS attempt?
by Paul Vixie 10 Nov '01

10 Nov '01

> Philosophically I think the EFF is right. Blocking a single > legitimate e-mail is very bad, and should be avoided at all costs. Bad for whom? Only for the sender? Does this sender have rights which should supercede the property rights of recipients and of infrastructure owners? If so then who gets to decide whether mail is legitimate or not? The sender again? If so then why should anyone ever be allowed to filter out "spam", either as a recipient, or as an infrastructure owner? That way lies madness. Senders have no such rights, and the determination of a message's legitimacy lies with recipients (and perhaps infrastructure owners) NOT senders. A sender's rights are determined by their contract with their ISP, and an ISP's rights are determined by their contracts with their peers and transit providers. > Practically I think that the tactics of MAPS and ORBS and other > blacklists are necessary right now. I'd like nothing better than > to see them go away because better technology has come along. Agreed. (And note that I no longer have an operational role at MAPS.) > Legally (eg, if congress were going to pass a new law) I'm very > much on the side of the EFF, because the law must be pure and true, > because anything less impinges on our civil liberties. I also want the law to be pure and true, but there is no civil liberty involving the transmission of e-mail or any other traffic whose cost of delivery is paid in any way by anyone other than that sender.

18 28

Re: Fwd: Re: Digital Island sponsors DoS attempt?
by Paul A Vixie 10 Nov '01

10 Nov '01

> As an infrastructure owner, the important thing is that if you're > going to announce reachability, it should be real. If you blackhole > stuff in the middle of a netblock and distribute it as an untainted > netblock in your BGP, you're depriving people of clean routes. ok, so how do you handle a situation like orbs/abovenet as in late 1999? a /16 owned by a transit customer of as6461 had in it a /24 used by orbs. the orbs traffic violated as6461's aup, which the /16's owner had signed. the /16 owner had a less restrictive aup for its downstreams (including orbs) than as6461 had, and thus had a weak contractual basis for enforcing the as6461 aup on orbs. as6461 had three possible choices: (a) ignore it and hope the nonuniform enforcement of the aup didn't show up as a problem elsewhere at a later time; (b) disconnect orbs' upstream on the basis of their inability to conform to the aup they had signed; or (c) block traffic to/from the /24 in question after carefully notifying the /16 owner that this would be done and why. as we all know, (c) was chosen. great was the hue and even greater the cry. a recommendation was even made that if as6461 wasn't going to carry the whole /16 that it ought to chop it up and only advertise the parts it could reach, in spite of what these more-specifics would have done to the /16 owner's own routing policy (they were multihomed.) what would YOU have done? justify your answer. (show all work.)

3 2

The Cidr Report
by CIDR Report 10 Nov '01

10 Nov '01

This is an auto-generated mail on Fri Nov 9 23:00:00 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 09Nov01 0) General Status Table History ------------- Date Prefixes 021101 103427 031101 103794 041101 103681 051101 103790 061101 103996 071101 104143 081101 104227 091101 105100 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 89.81.192.0/20 from AS6695 AS Summary ---------- Number of ASes in routing system: 8879 Number of ASes announcing only one prefix: 4040 (4040 cidr, 0 classful) Largest number of cidr routes: 817 announced by AS701 Largest number of classful routes: 0 announced by 1) Gains by aggregating at the origin AS level --- 09Nov01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1212 931 281 23.2% Telstra Pty Ltd AS701 1415 1172 243 17.2% UUNET Technologies, Inc. AS4151 317 180 137 43.2% USDA AS16473 202 77 125 61.9% Bell South AS577 308 190 118 38.3% Bell Advanced Communications Inc. AS7018 797 687 110 13.8% AT&T AS6595 170 60 110 64.7% DoD Education Activity Network As AS4293 361 256 105 29.1% Cable & Wireless USA AS705 268 168 100 37.3% UUNET Technologies, Inc. AS4766 197 97 100 50.8% Korea Internet Exchange for "96 W AS2048 215 117 98 45.6% State of Louisiana AS271 159 72 87 54.7% University of British Columbia AS1239 484 408 76 15.7% Sprint AS12302 106 35 71 67.0% MobiFon S.A. AS4755 191 122 69 36.1% Videsh Sanchar Nigam Ltd. Autonom AS2149 388 319 69 17.8% Performance Systems, Inc. AS6471 133 67 66 49.6% ENTEL CHILE S.A. AS4200 130 65 65 50.0% Apex Global Information Services, AS19632 72 7 65 90.3% Metropolis Intercom S.A. AS17557 137 72 65 47.4% Pakistan Telecom AS3464 160 96 64 40.0% Alabama SuperComputer Network AS4323 315 254 61 19.4% Time Warner Communications, Inc. AS7046 311 252 59 19.0% UUNET Technologies, Inc. AS724 200 142 58 29.0% DLA Systems Automation Center AS209 310 252 58 18.7% Qwest AS16758 63 6 57 90.5% IKON Office Solutions AS13999 70 14 56 80.0% Mega Cable S.A. de C.V. AS703 277 225 52 18.8% UUNET Technologies, Inc. AS3908 295 244 51 17.3% Supernet, Inc. AS17561 113 62 51 45.1% Internet service provision to Wes 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: wireless traffic
by Dave O'Shea 10 Nov '01

10 Nov '01

Way Back When, I think that IEEE was the party that handed out prefixes to be used as MAC addresses. I know several people have compiled lists at one time or another. There's a neat little app for palm OS handhelds called Ethertools*, that had a reasonably comprehensive list of the well-known ones. (*Of course similarly formatted MAC addresses are present on other multi-access mediums as well. I recall pulling out a lot of hair figuring out how 3Com ended up with what looked like two MAC's on every token-ring card. Turned out to be the same address, but token ring was small-endian vs. big-endian. Or vice versa.) -----Original Message----- From: Steven M. Bellovin [mailto:smb@research.att.com] Sent: Friday, November 09, 2001 10:29 AM To: Andrew Brown Cc: Valdis.Kletnieks(a)vt.edu; Art Houle; nanog(a)merit.edu Subject: Re: wireless traffic In message <20011109104400.A6249(a)noc.untraceable.net>, Andrew Brown writes: > >>> Does anybody know where I can locate a list of MAC address prefixes that >>> belong specifically to wireless NIC cards? I am looking for a method of >>> discovering what devices on my network are wireless devices. >> >>Power down the wireless hub and see who calls? ;) >> >>Seriously though - your wireless hub/transmitter may have a queryable >>arp table that will tell you what's not using the wire.... > >i've used/seen cards with these prefixes: > > 00:e0:29 - smc > 00:02:2d - orinoco/wavelan cards (lucent/agere) > I'm sending this via a Lucent card with prefix 0:60:1d. A glance at my ARP table for a wireless-only segment shows 0:4:dd, 0:3:6b, 8:0:20, 0:0:c, 0:c0:b7, 0:d0:b7, 8:0:6a, and more. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com

3 2

just testing
by Stephen Miller 10 Nov '01

10 Nov '01

just testing -- ================================================== "Let's get dangerous!" - Darkwing Duck ==================================================

1 0