July 2000 - Test - lists.nanog.org

Deadline Oct 6 200 Re: NFPA 76 Standard for the protection of telecommunications facilities
by Sean Donelan 30 Jul '00

30 Jul '00

I poked around the NFPA website a bit more, the deadline for comments is October 6, 2000. On Sat, 29 July 2000, Michael Shields wrote: > I'm not sure why colo facilities should be held to lesser fire > protection standards than COs. Although the standard as written may > have problems as a document, many data centers could certainly benefit > from a more rigorous and professional approach to fire safety. I not saying colo facilities should be held to a lesser fire protection standard. The fallacy is assuming CO's are held to a higher standard. They have different backgrounds and different assumptions which resulted in a different set of decisions. For example, CO's are exempted from many of the requirements of the National Electrical Code, which colo facilities are not. These assumptions permeate the standard, which are inappropriate to apply to facilities built with different functional assumptions. Why shouldn't the NEC apply to telephone CO's? Is the fact it doesn't mean telephone CO's are built to a lower standard than even a building built to meet the NEC. No. > Precisely. If the requirements are onerous, perhaps we are building > COs that are expensively overprotected. NFPA 76 may be appropriate for a telephone central office. It is not appropriate to extend it to cover internet and other telecommunication facilities.

1 0

Re: NFPA 76 Standard for the protection of telecommunications facilities
by Michael Shields 29 Jul '00

29 Jul '00

In article <20000729031834.23310.cpmta(a)c004.sfo.cp.net>, Sean Donelan <sean(a)donelan.com> wrote: > See that word "Internet." While they may have intended to only > apply it to the traditional telephone Central Office, the scope > statement is far too broad for this standard. I'm not sure why colo facilities should be held to lesser fire protection standards than COs. Although the standard as written may have problems as a document, many data centers could certainly benefit from a more rigorous and professional approach to fire safety. > You can tell the document was written by a bunch of old-line telephone > folks. They make distinctions between ILECs ("These companies, who > have been in business for many years,") and CLECs ("The companies are > primarily start-up companies"). Such distinctions have no place in an > consensus standard document. Industry standards should apply equally > to all companies within an industry. Precisely. If the requirements are onerous, perhaps we are building COs that are expensively overprotected. -- Shields.

1 0

NFPA 76 Standard for the protection of telecommunications facilities
by Sean Donelan 29 Jul '00

29 Jul '00

The folks at NFPA are at it again. They've developed NFPA 76, Standard for the protection of telecommunication facilities. Which would be fine, the telephone companies can go off and do their own thing. The problem is the document scope expands beyond just telephone central offices. "Standard proves minimum requirements for fire protection of telecommunication facilities, where telephone, data, cellular, internet, and video services are rendered." See that word "Internet." While they may have intended to only apply it to the traditional telephone Central Office, the scope statement is far too broad for this standard. You can tell the document was written by a bunch of old-line telephone folks. They make distinctions between ILECs ("These companies, who have been in business for many years,") and CLECs ("The companies are primarily start-up companies"). Such distinctions have no place in an consensus standard document. Industry standards should apply equally to all companies within an industry. But perhaps the more distubing part of NFPA 76 is it incorporates by refence non-industry consensus based standards such as NEBS. NEBS is a proprietary standard published by Telcordia, originally developed as a private standard by AT&T. It is even more inappropriate to apply a standard such as NEBS to other industries such as the Internet, and claim it is an "industry standard." http://www.nfpa.org/doc_FAQ/76-p.pdf How many ISPs would like the fire marshall to apply this standard as written to their Internet facilities. If you don't comment, they just might. Oh, by the way, the deadline for comments is July 30, 2000.

2 1

SOA RNAME field in NSI Registry-administered zones
by Larson, Matt 28 Jul '00

28 Jul '00

The NSI Registry is always striving to improve the build and distribution process for the zones we administer. On Thursday, a new version of this build process went into production. Unfortunately, the information used to produce the SOA RNAME field was incorrect and it slipped through our QA process. We have resolved the issue, and zones with the correct information are being distributed. Matt Larson <mlarson(a)netsol.com> DNS Platform Manager Network Solutions Registry / www.nsiregistry.com

2 1

ATM problem with Cisco 6400
by Abrams, Chris 28 Jul '00

28 Jul '00

I am running into a problem with our Cisco 6400s. I have a NNI between a BPX and 6400. It only allows me to use up to 8 bits for VPI. The ATM spec states that 12 bits for VPI over NNI connection. I do the following on the 6400: interface ATM5/1/0 description oc3 to BPX no ip address no atm auto-configuration no atm ilmi-keepalive atm nni LAB1-6400-1-NSP(config)#int a5/1/0 LAB1-6400-1-NSP(config-if)#atm max LAB1-6400-1-NSP(config-if)#atm maxvpi LAB1-6400-1-NSP(config-if)#atm maxvpi-bits ? <0-8> Configure maximum number of VPI bits Has anyone run into this problem? Is there a new version of IOS that will support this? Thanks

1 0

bw usage?
by David M. Ramsey 28 Jul '00

28 Jul '00

Folks, I'm interested in learning which tools other people are using to measure bandwidth usage for co-located client machines on Ethernet switches. For now I've cobbled together some crude software to regularly read SNMP port byte in/out counters from our switches, stashing the deltas in a DB for later reporting/analysis. I'm concerned that the data is misleading, though, in that it will include LAN broadcast traffic. Also, customers end up paying for other bandwidth that they did not want or induce, like network scans, etc. (tough luck?). We've considered implementing unique customer VLANS to separate customer broadcast domains, but it seems like that'd be a pain, would eat up IP addresses, and possibly tax our routers with all of the ISL/VLAN stuff? Thanks in advance for any help/hints/pointers/advice you can offer. Regards, --dmr David Ramsey Charlotte, NC

5 4

SUMMARY: bw usage?
by David M. Ramsey 28 Jul '00

28 Jul '00

Thanks to everyone who shared thoughts, ideas and experience regarding monitoring bandwidth usage on Ethernet switch ports without including broadcast traffic. EVERYONE tends to agree that a separate VLAN for each co-located customer is the only professional way to do things "right". I agree, and plan to move in that direction, fast. Then I won't have to worry about broadcast traffic, either! Other recommended solutions included: - MRTG This is great (I use it elsewhere) but it doesn't directly address the issue I have of *not* including broadcast traffic - Cisco 6500 switches apparently support "Private VLANS", which don't burn up IP addresses. Sounds cool, wish I had a 6500 ;-) - AUI port -- several people pointed out that an unused AUI port on a switch will log broadcast traffic and no other; I can subtract that from traffic monitored on all other ports. Some people said that an unused VLAN1 has same behavior. - dumb hub -- by plugging in a dumb, passive Ethernet hub with nothing connected, it will receive broadcast traffic. I can then subtract that ports byte counters from others. - Cisco NetFlow / cflowd ( http://www.caida.org/tools/measurement/cflowd/ ) Seems very thorough, overkill for me right now. - RMON counting of unicast-Octets only - Extracting SNMP # multicast/broadcast packets, using average packet size and subtracting product from total byte count - HPOV + SNMPv2 Regards to all, --dmr David Ramsey Charlotte, NC

6 5

The Cidr Report
by Tony Bates 28 Jul '00

28 Jul '00

This is an auto-generated mail on Fri Jul 28 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 28Jul00 0) General Status Table History ------------- Date Prefixes 210700 82529 220700 82534 230700 82499 240700 82582 250700 82822 260700 82702 270700 82843 280700 82898 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 65.0.0.0/14 from AS6172 AS Summary ---------- Number of ASes in routing system: 8021 Number of ASes announcing only one prefix: 4513 (2506 cidr, 2007 classful) Largest number of cidr routes: 943 announced by AS701 Largest number of classful routes: 1078 announced by AS701 1) Gains by aggregating at the origin AS level --- 28Jul00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 435 152 283 65.1% BCnet Backbone AS7046 643 397 246 38.3% COQUI-NET PRTC Internet AS1221 583 418 165 28.3% TELSTRA-AS AS9706 155 25 130 83.9% Pusan Metropolitan City Office of AS2609 128 8 120 93.8% EUnet-TN AS9304 125 16 109 87.2% Hutchcity AS7657 300 192 108 36.0% The Internet Group Limited AS7545 157 58 99 63.1% TPG Internet Pty Ltd AS9269 155 62 93 60.0% Hong Kong CTI AS6429 208 115 93 44.7% RDC-INTERNET AS7496 126 38 88 69.8% Power Up AS4293 335 248 87 26.0% Internal ASN for C&W AS577 256 171 85 33.2% Bell Backbone AS174 535 456 79 14.8% Performance Systems International AS705 326 249 77 23.6% ALTERNET-AS AS1727 172 99 73 42.4% MRMS-WEST AS724 224 153 71 31.7% DLA-ASNBLOCK-AS AS3908 244 178 66 27.0% Supernet, Inc. AS4755 166 101 65 39.2% Videsh Sanchar Nigam Ltd. India AS701 1078 1014 64 5.9% Alternet AS6595 116 52 64 55.2% DODDSEUR AS5106 98 36 62 63.3% AADS-COLUMBUS AS3749 117 58 59 50.4% TECNET AS7018 546 488 58 10.6% AT&T WorldNet Service Backbone AS7568 80 23 57 71.2% C.S. Communications Co., Ltd. AS3602 299 242 57 19.1% Sprint Canada Inc. AS4740 325 272 53 16.3% Ozemail Pty Ltd (ASN-OZEMAIL) AS11252 90 37 53 58.9% Idaho State University AS7993 78 28 50 64.1% Global One Communications AS209 267 220 47 17.6% Qwest Communications 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

more NSI braindamage....
by woods＠weird.com 28 Jul '00

28 Jul '00

MORE NSI braindamage: . NS B.ROOT-SERVERS.NET A.ROOT-SERVERS.NET zone(a)nsiregistry.NET (2000072800 1800 900 604800 86400) !!! . SOA hostmaster zone(a)nsiregistry.NET has illegal mailbox Don't let the new guy play with the zone files!!!!!! -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods(a)acm.org> <robohack!woods> Planix, Inc. <woods(a)planix.com>; Secrets of the Weird <woods(a)weird.com>

1 0

Happy Sys Admin Appreciation Day
by James Smith 28 Jul '00

28 Jul '00

Happy Sys Admin Appreciation Day to every sys admin and network admin on the list! :) http://www.sysadminday.com/ -- James Smith, CCNA Chief Network/System Administrator DXSTORM.COM http://www.dxstorm.com/ DXSTORM Inc. 2395 Speakman Drive, Suite 2200 Mississauga, ON, L5K 1B3 CANADA Tel: 905-822-1957 (email preferred) Fax: 905-822-0680 1-877-DXSTORM (1-877-397-8676) "Feeling 'connected' with carbon-based dolts holds all the joy of being handcuffed to a dead zebra - it sounds special, but it can get old fast." - The Dilbert Principle - Engineers, Scientists, Programmers and Other Odd People

1 0