Re: [c-nsp] Cisco and third party transceivers
On Wednesday, November 09, 2011 08:35:56 PM Jared Mauch wrote: Are you sure they were SFP vs GLC? Some platforms support these differently or not at all. Cisco can't keep this straight themselves. They regularly won't support their own optics in their own product unless you got the right one. Like for us, the ME3600X can swallow both GLC- and SFP- optics, since it's both a switch and router (although more a router). Interestingly, a 7201 we have was able to accept GLC- optics, even though it's always supposed to eat SFP-. We stopped keeping up, unless you're talking about pure classic switches such as the 2960, e.t.c. If memory serves, the RP's on our CRS routers shipped with GLC- optics for the control ports. In this case, I have to praise Juniper's consistency. Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco and third party transceivers
In addition, anyone seen a situation where DDM support depends on IOS image version? For example I have one ProLabs X2-10GB-LR-C transceiver, which outputs DDM information in case of cat4500-ipbasek9-mz.122-54.SG.bin, but displays nothing in show interfaces transceiver output when IOS image is cat4500-ipbasek9-mz.122-37.SG1.bin. Anyone seen something like this? Last but not least, any ideas why do different switch models display transceiver EEPROM information(show idprom interface X) differently? Example below with third-party SFP-BIDI-240B-D Cisco-compatible transceiver: A) in ME-C3750-24TE switch: C3750#show idprom interface Gi1/0/1 General SFP Information --- Identifier: 0x03 Connector : 0x07 Transceiver : 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x00 Encoding : 0x01 BR_Nominal: 0x0D Vendor Name : OEM Vendor Part Number: SFP-BIDI-240D Vendor Revision : 0x41 0x20 0x20 0x20 Vendor Serial Number : GB1110260604 --- Other Information --- Port asic num : 00 Port asic port num: 00 SFP presence index: 00 SFP iter cnt : 4654580 SFP failed oper flag : 0x IIC error cnt : 0 IIC error dsb cnt : 0 IIC max sts cnt : 35 Chk for link status : 01 Link status : 00 Autoneg enable: 01 Flow control Pause: 00 Flow control asymPause: 00 Duplex mode : 00 PcsInfo : 0x041960A8 MacInfo : 0x04196098 0x04196090 AutoNeg : 0x04196090 0x04196098 Sfp selection asic reg map phyLoopback : 0x00 sfpControl : 0x4E Regs Loc : 0xF000 SFF-8472 MSA EEPROM Data === 000 : 03 04 07 00 00 00 02 00 00 00 010 : 00 01 0D 00 28 FF 00 00 00 00 020 : 4F 45 4D 20 20 20 20 20 20 20 030 : 20 20 20 20 20 20 00 00 0B 40 040 : 53 46 50 2D 42 49 44 49 2D 32 050 : 34 30 44 20 20 20 41 20 20 20 060 : 06 0E 00 5B 00 1A 00 00 47 42 070 : 31 31 31 30 32 36 30 36 30 34 080 : 20 20 20 20 31 31 31 30 32 35 090 : 20 20 58 F0 01 CB 37 34 30 2D 100 : 30 31 31 36 31 34 20 52 45 56 110 : 20 30 31 00 00 00 00 00 00 00 120 : 00 00 00 00 00 00 00 00 SFF-8472 Digital Diagnostic Monitoring Data === 000 :55 00 F6 00 50 00 FB 00 90 88 010 :71 48 8C 9F 75 30 7E F4 13 88 020 :75 30 17 70 62 1F 04 EB 4D F1 030 :06 31 31 2D 00 14 27 10 00 19 040 :00 00 00 00 00 00 00 00 00 00 050 :00 00 00 00 00 00 00 00 00 00 060 :00 00 00 00 00 00 00 00 3F 80 070 :00 00 00 00 00 00 01 00 00 00 080 :01 00 00 00 01 00 00 00 01 00 090 :00 00 00 00 00 DA 19 B3 80 A4 100 :33 18 13 E4 00 01 00 00 00 00 110 :02 00 00 40 00 00 00 40 00 00 120 :00 FF FF FF FF FF FF FF YETI INTERNAL REGS --- Location=0xD8000500 : Value=0x00 Location=0xD8000501 : Value=0x00 Location=0xD8000502 : Value=0x00 Location=0xD8000503 : Value=0x00 Location=0xD8000504 : Value=0x00 Location=0xD8000505 : Value=0x00 Location=0xD8000506 : Value=0x00 Location=0xD8000507 : Value=0x02 Location=0xD8000508 : Value=0x00 Location=0xD8000509 : Value=0x40 Location=0xD800050A : Value=0x00 Location=0xD800050B : Value=0x00 Location=0xD800050C : Value=0x05 Location=0xD800050D : Value=0x00 Location=0xD800050E : Value=0x01 Location=0xD800050F : Value=0x00 Location=0xD8000510 : Value=0x0F yetiIICinited : Value=0x0001 yetiIICLockPassCnt : Value=0 yetiIICLockFailCnt : Value=0 yetiIICLockApp : Value=11 --- --- C3750# B) and this very same SFP in WS-C4506 switch: Catalyst4500#show idprom interface Gi1/3 GBIC Serial EEPROM Contents: Common Block: Identifier= Not available [0x3] Extended Id = GBIC is compliant with MOD_DEF 4 [0x4] Connector = LC Connector [0x7] Transceiver Type = Gbic 1000BaseZX Speed(FC,byte 10)= Not available [0x0] Media= Not available [0x0] Technology = Not available [0x0] Link Length = Not available [0x0] GE Comp Codes= 1000BASE-LX [0x2] (LX used generically for LX, LH or ZX) SONET Comp Codes = Not available [0x0] Encoding = 8B10B [0x1] BR, Nominal = 1300 Mbps (million bits per second) Length(9u) in km = 40 km Length(9u)= 25.4 km Length(50u) = GBIC does not support 50 micron multi-mode fibre, or the length must be determined from the transceiver technology. Length(62.5u) = GBIC does not support 62.5 micron multi-mode fibre, or
Re: [c-nsp] Cisco and third party transceivers
Hi Martin, In addition, anyone seen a situation where DDM support depends on IOS image version? For example I have one ProLabs X2-10GB-LR-C Take a look at the DOM Support column: http://www.cisco.com/en/US/docs/interfaces_modules/transceiver_modules/compatibility/matrix/OL_6974.html#wp55804 On the CAT4k you typically need 12.2(54)SG for DOM support. Best regards, Klaus Kastens -- Klaus Kastens NetUSE AG Dr.-Hell-Str. 6, D-24107 Kiel,Germany Fon: +49 431 2390 400 (07:00 UTC - 17:00 UTC) Fax: +49 431 2390 499 Vorstand: Dr. Joerg Posewang (Vorsitz), Dr. Roland Kaltefleiter, Andreas Seeger Aufsichtsrat: Dr. Dirk Lukas (Vorsitz) Sitz der AG: Kiel, HRB 5358 USt.ID: DE156073942 Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen. Das unbefugte Kopieren dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen ist nicht gestattet. The information contained in this message is confidential or protected by law. Any unauthorised copying of this message or unauthorised distribution of the information contained herein is prohibited. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco and third party transceivers
On 30.09.2011 01:39, Martin T wrote: Jason, I agree that preferring Cisco branded SFP's gives a sort of quality guarantee. According to a friend of mine, those SFP's were bought from a electronics market in Moscow: http://img.nag.ru/images/18388/101019342.gif http://img.nag.ru/images/18388/138043329.jpeg http://img.nag.ru/images/18640/2112514702.jpg http://img.nag.ru/images/18640/2054988461.jpeg ..but manufactured in Asia. On the other hand, there are manufacturers like Finisar, Prolabs, Agilent etc, which make decent transceivers as much as I have experience. In addition, according to this article: http://www.lightreading.com/document.asp?doc_id=102950 ..Cisco buys SFP directly from Finisar. Do you see a difference in Cisco branded Finisar SFP and Finisar SFP other than content of EEPROM? I've one time had a Finisar-labeled and Cisco-labeled SFP in hands ... you could see they were most likely identical from the PCB routing ... We've had a good OEM/compatible place for several years now, bought something like 100+ optics in all sizes and speeds (SFP MM/SM, X2, SFP+ MM/SM), of which some have been operating for 4+ years without any glitch ... even have 3 years warranty on them, compared to the official 3 months from Cisco or the minimum legal warranty of 2 years for the original Cisco SFPs. Interesting side note: in a customer Nexus 5548 we've recently put some 20+ SFPs in (1 and 10G) - along with four copper 10G links for NX2248. Interestingly, the OEM SFP/SFP+ were recognized as original (no warning, even without unsupported transceiver), but the _original_ Cisco copper SFP+ link cables are shown as third party ... (I must assume they are original, as they were purchased directly from an official reseller, and the prices match up to the OIP we set up for the project). -gg ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco and third party transceivers
Last but not least, any ideas why do different switch models display transceiver EEPROM information(show idprom interface X) differently? Because Cisco has lots of different Business Units and they don't have any reason to coordinate the display format? Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco and third party transceivers
On 09/11/2011 12:20, sth...@nethelp.no wrote: Because Cisco has lots of different Business Units and they don't have any reason to coordinate the display format? My favourite is showing DOM values on 7600s. If you have a LAN card, you use: (Router)# show interfaces TenGigabitEthernet x/y transceiver if you have a SIP card, you use: (Router)# show hw-module subslot x/y transceiver z status Way to go. Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco and third party transceivers
See below Jared Mauch On Nov 9, 2011, at 6:20 AM, Garry g...@gmx.de wrote: Interesting side note: in a customer Nexus 5548 we've recently put some 20+ SFPs in (1 and 10G) - along with four copper 10G links for NX2248. Interestingly, the OEM SFP/SFP+ were recognized as original (no warning, even without unsupported transceiver), but the _original_ Cisco copper SFP+ link cables are shown as third party ... (I must assume they are original, as they were purchased directly from an official reseller, and the prices match up to the OIP we set up for the project). Are you sure they were SFP vs GLC? Some platforms support these differently or not at all. Cisco can't keep this straight themselves. They regularly won't support their own optics in their own product unless you got the right one. Going 3rd party solves all these problems and can save you thousands or millions of dollars. I recently paid $35 for optics that were list $1k. Buys lots of spares for that cost. I certainly was not going to spend as much on optics as the switch! ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco and third party transceivers
On Tue, Sep 27, 2011 at 1:17 PM, Martin T m4rtn...@gmail.com wrote: Hello, there are providers like Flexoptix(http://www.flexoptix.net) who are able to flash SFP EEPROM memory with different vendor data, probably set custom serial numbers etc. However, why is such service needed at nowadays for Cisco equipment? Every router/switch I have seen supports the service unsupported-transceiver(should turn of checking the Cisco Quality ID) and no errdisable detect cause gbic-invalid commands and thus doesn't check the ID code in EEPROM.. In addition, am I correct, that some old Cisco IOS versions did not have the service unsupported-transceiver and no errdisable detect cause gbic-invalid commands and thus one really was forced to use transceivers with Cisco serials? Some ASAs won't take some 3rd party transceivers no matter what voodoo you type, as far as I've been able to figure out anyway. It really depends on your business model so to speak. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco and third party transceivers
On 30/09/2011 00:39, Martin T wrote: ..but manufactured in Asia. On the other hand, there are manufacturers like Finisar, Prolabs, Agilent etc, which make decent transceivers as much as I have experience. In addition, according to this article: http://www.lightreading.com/document.asp?doc_id=102950 ..Cisco buys SFP directly from Finisar. Do you see a difference in Cisco branded Finisar SFP and Finisar SFP other than content of EEPROM? Cisco buys transceivers from several companies. Sometimes the same product SKU from a particular vendor might actually be sourced from several different transceiver manufacturers. Do you think for a moment that that a GLC-LH-SM bought in 1999 is going to be exactly the same component as a GLC-LH-SM bought in 2011? Of course it isn't. Transceiver compatibility is a really difficult area. And one transceiver is not the same as another. Bugs slip into the transceiver firmware and hardware. Some vendors produce complete trash. Some vendors produce really high quality products (e.g. finisar, opnext, etc) It's a third-party SFP directly from China. As much as I understand, it doesn't have any sort of Cisco-branding, does it? Regardless it supports DDM. DDM is defined in SFF8472. It's nothing particularly to do with Cisco. In addition, in the past, has there been times where one really was forced to use transceivers with Cisco serials because there were no service unsupported-transceiver and no errdisable detect cause gbic-invalid commands? Maybe some seasoned network engineer remembers.. Yes, that was the case in the past. And unfortunately, Cisco have recently either deliberately started ignoring service unsupported-transceiver on some of their new products, or else the transceiver device drivers are sufficiently portably written that they no longer work with many types of transceiver. Either way, transceiver compatibility problems are rearing their ugly head again in a major way. Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco and third party transceivers
Jason, I agree that preferring Cisco branded SFP's gives a sort of quality guarantee. According to a friend of mine, those SFP's were bought from a electronics market in Moscow: http://img.nag.ru/images/18388/101019342.gif http://img.nag.ru/images/18388/138043329.jpeg http://img.nag.ru/images/18640/2112514702.jpg http://img.nag.ru/images/18640/2054988461.jpeg ..but manufactured in Asia. On the other hand, there are manufacturers like Finisar, Prolabs, Agilent etc, which make decent transceivers as much as I have experience. In addition, according to this article: http://www.lightreading.com/document.asp?doc_id=102950 ..Cisco buys SFP directly from Finisar. Do you see a difference in Cisco branded Finisar SFP and Finisar SFP other than content of EEPROM? Mikael, what do you mean by non-cisco coded optics? Take a look at following example: WS-C3750G-12S#show idprom interface GigabitEthernet 1/0/1 General SFP Information --- Identifier: 0x03 Connector : 0x07 Transceiver : 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Encoding : 0x01 BR_Nominal: 0x0D Vendor Name : OEM Vendor Part Number: SFP-CWDM-2120-47 Vendor Revision : 0x31 0x31 0x2E 0x30 Vendor Serial Number : N87R3121 --- Other Information --- Port asic num : 02 Port asic port num: 02 SFP presence index: 00 SFP iter cnt : 323752258 SFP failed oper flag : 0x IIC error cnt : 0 IIC error dsb cnt : 0 IIC max sts cnt : 4 Chk for link status : 01 Link status : 01 Autoneg enable: 01 Flow control Pause: 00 Flow control asymPause: 00 Duplex mode : 00 PcsInfo : 0x05FDEBE0 MacInfo : 0x05FDEBC8 0x05FDEBC0 AutoNeg : 0x05FDEBC0 0x05FDEBC8 Sfp selection asic reg map stbi : 0x00 tbi : 0x00 sfpControl : 0x15 sfpStatus0 : 0xC0 sfpStatus1 : 0x00 Regs Loc : 0xF000 SFF-8472 MSA EEPROM Data === 000 : 03 04 07 00 00 00 00 00 00 00 010 : 00 01 0D 00 78 FF 00 00 00 00 020 : 4F 45 4D 20 20 20 20 20 20 20 030 : 20 20 20 20 20 20 00 20 20 20 040 : 53 46 50 2D 43 57 44 4D 2D 32 050 : 31 32 30 2D 34 37 31 31 2E 30 060 : 05 BE 20 E2 20 20 20 20 4E 38 070 : 37 51 33 31 30 34 20 20 20 20 080 : 20 20 20 20 31 30 30 34 30 31 090 : 20 20 58 80 01 95 01 00 11 80 100 : 63 BE 0B 0B 3F 60 94 D7 71 7D 110 : C9 3C CD 04 4C 00 00 00 00 00 120 : 00 00 00 00 09 21 04 EC SFF-8472 Digital Diagnostic Monitoring Data === 000 :64 00 D8 00 5F 00 DD 00 89 EE 010 :72 F1 86 1A 76 C6 09 78 01 50 020 :0A 32 01 2A 07 A0 00 C3 06 0E 030 :00 F6 8B 6E 00 21 AF 86 00 27 040 :00 00 00 00 00 00 00 00 00 00 050 :00 00 00 00 00 00 00 00 00 00 060 :00 00 00 00 00 00 00 00 3E 0F 070 :D2 7D BF BB A9 AF 0D 69 00 00 080 :10 34 00 00 01 00 00 00 01 05 090 :00 00 00 00 00 80 33 E0 7F 90 100 :03 36 04 48 01 76 00 00 00 00 110 :00 F8 00 00 00 00 00 00 00 00 120 :00 00 00 00 00 00 00 00 YETI INTERNAL REGS --- Location=0xD8000500 : Value=0x00 Location=0xD8000501 : Value=0x00 Location=0xD8000502 : Value=0x00 Location=0xD8000503 : Value=0x00 Location=0xD8000504 : Value=0x00 Location=0xD8000505 : Value=0x00 Location=0xD8000506 : Value=0x00 Location=0xD8000507 : Value=0x02 Location=0xD8000508 : Value=0x00 Location=0xD8000509 : Value=0x40 Location=0xD800050A : Value=0x00 Location=0xD800050B : Value=0x00 Location=0xD800050C : Value=0x05 Location=0xD800050D : Value=0x00 Location=0xD800050E : Value=0x01 Location=0xD800050F : Value=0x00 Location=0xD8000510 : Value=0x0F yetiIICinited : Value=0x0001 yetiIICLockPassCnt : Value=0 yetiIICLockFailCnt : Value=0 yetiIICLockApp : Value=35 --- --- WS-C3750G-12S#show interfaces Gi1/0/1 transceiver ITU Channel not available (Wavelength not available), Transceiver is externally calibrated. If device is externally calibrated, only calibrated values are printed. ++ : high alarm, + : high warning, - : low warning, -- : low alarm. NA or N/A: not applicable, Tx: transmit, Rx: receive. mA: milliamperes, dBm: decibels (milliwatts). Optical Optical Temperature Voltage Tx Power Rx Power Port (Celsius)(Volts) (dBm) (dBm) - --- --- Gi1/0/1 52.1 3.32 2.4 -23.0 WS-C3750G-12S#
Re: [c-nsp] Cisco and third party transceivers
On Fri, 30 Sep 2011, Martin T wrote: Mikael, what do you mean by non-cisco coded optics? Take a look at following example: I mean the ones which do not have a cisco keyed idprom, ie wouldn't work without service unsupported-transciever. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Cisco and third party transceivers
Hello, there are providers like Flexoptix(http://www.flexoptix.net) who are able to flash SFP EEPROM memory with different vendor data, probably set custom serial numbers etc. However, why is such service needed at nowadays for Cisco equipment? Every router/switch I have seen supports the service unsupported-transceiver(should turn of checking the Cisco Quality ID) and no errdisable detect cause gbic-invalid commands and thus doesn't check the ID code in EEPROM.. In addition, am I correct, that some old Cisco IOS versions did not have the service unsupported-transceiver and no errdisable detect cause gbic-invalid commands and thus one really was forced to use transceivers with Cisco serials? Last but not least, does SmartNet require you to use Cisco branded transceivers? I have heard that this is true only in case the fault or unexpected behaviour is related to transceiver.. regards, Martin ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco and third party transceivers
On 2011-09-27, at 4:17 PM, Martin T wrote: Hello, there are providers like Flexoptix(http://www.flexoptix.net) who are able to flash SFP EEPROM memory with different vendor data, probably set custom serial numbers etc. However, why is such service needed at nowadays for Cisco equipment? Every router/switch I have seen supports the service unsupported-transceiver(should turn of checking the Cisco Quality ID) and no errdisable detect cause gbic-invalid commands and thus doesn't check the ID code in EEPROM.. Just because a third party optic is recognized (by way of EEPROM flash or service unsupported-transceiver) by your gear, it doesn't automatically mean that it will perform on par with a genuine optic. When we started our 10GE foray last year, we had no end of problems with third party optics. It wasn't until we ran the optics through RFC2544 tests back to back and in our gear that we were able to differentiate the good ones from the bad ones. We do this routinely for our 10G and 1G (duplex, Bidi and T) whenever we get a batch of SFPs that we don't recognize. If you don't fully test your optics, you will be plagued with small little niggling issues that can't really be identified with any degree of certainty. I've found that as the bit rates go up, it's more imperative than ever to test absolutely everything. The smallest little defect can manifest itself in so many different ways. The investment in RF2544 testers and OTDR testers has paid itself back in full, repeatedly. Last but not least, does SmartNet require you to use Cisco branded transceivers? I have heard that this is true only in case the fault or unexpected behaviour is related to transceiver.. Use whatever optic you want, but if you're going to open a TAC case, they'll ask you to put a Cisco optic in before they do something like RMA a line card. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco and third party transceivers
Thus spake Jason Lixfeld (ja...@lixfeld.ca) on Tue, Sep 27, 2011 at 04:45:39PM -0400: Use whatever optic you want, but if you're going to open a TAC case, they'll ask you to put a Cisco optic in before they do something like RMA a line card. I think the warning message from my nexus 5548up summs it up nicely: Warning: When Cisco determines that a fault or defect can be traced to the use of third-party transceivers installed by a customer or reseller, then, at Cisco's discretion, Cisco may withhold support under warranty or a Cisco support program. In the course of providing support for a Cisco networking product Cisco may require that the end user install Cisco transceivers if Cisco determines that removing third-party parts will assist Cisco in diagnosing the cause of a support issue. Cheers, Dale ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco and third party transceivers
On Tue, 27 Sep 2011, Martin T wrote: However, why is such service needed at nowadays for Cisco equipment? Because Cisco do not activate DOM (Digital Optical Monitoring) on non-cisco coded optics. It's also nice to be able to get things working out of the box and not have the remote hands engineer have to configure things to get the optics running. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
