- Test - lists.nanog.org

Is the list alive
by Scott McGrath 31 Jul '00

31 Jul '00

I have not seen any traffic from the list recently and I usually get 50+ messages per day Thanks - Scott

2 1

ORBS IS BUSY
by Henry R. Linneweh 31 Jul '00

31 Jul '00

Telstra And Optus Blacklisted By ORBS http://www.internetnews.com/intl-news/article/0,2171,6_425981,00.html -- Thank you; |--------------------------------| | Thinking is a learned process. | | ICANN member @large | | Gigabit over IP, ieee 802.17 | |--------------------------------| Henry R. Linneweh

1 0

Beermaker?
by Alex 31 Jul '00

31 Jul '00

Anyone else seeing peermaker not working properly?

1 0

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