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 ASR1k Slow response for show ip cache flow
Mack McBride writes: It could be the specific match string. Right, especially if there are many dots in the regexp. What match is timing out? If there are dots, try to escape them (e.g. | include 192\.0\.2\.). But the output volume of show ip cache flow is probably also significantly larger than the output of show ip bgp. On the Catalyst 6500 platform, there are handy option for the equivalent of show ip cache flow to narrow the output to certain source/destination subnets or UDP/TCP port numbers. That is more efficient than having the router convert the entire Netflow table to text and then filtering 99.9% of the text away by regexp. Does the ASR1k software have these kinds of options? Best regards, -- Simon. ___ 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
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] RES: Cisco AnyConnect VPN Client
It used to be true that AnyConnect was only SSL. One of the features introduced in AnyConnect 3.0 was support for IPSec. HTH Rick On 11/3/2011 3:46 PM, Leonardo Gama Souza wrote: No, it only supports SSL VPN. -Mensagem original- De: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] Em nome de Manu Chao Enviada em: quinta-feira, 3 de novembro de 2011 14:24 Para: cisco-nsp@puck.nether.net Assunto: [c-nsp] Cisco AnyConnect VPN Client I haven't found how to configure IPSec with Cisco AnyConnect VPN Client. Is it possible? ___ 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/ ___ 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/ ___ 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 ASR1k Slow response for show ip cache flow
Thanks I tried using the escape but this did not help. Its faster to export the whole netflow table to text via show ip cache flow | tee url then run a grep in that file than to run it on the ASR direct. I suspect it's software related, seems like a visit to TAC is in order... On 09 Nov 2011, at 11:21 AM, Simon Leinen wrote: Mack McBride writes: It could be the specific match string. Right, especially if there are many dots in the regexp. What match is timing out? If there are dots, try to escape them (e.g. | include 192\.0\.2\.). But the output volume of show ip cache flow is probably also significantly larger than the output of show ip bgp. On the Catalyst 6500 platform, there are handy option for the equivalent of show ip cache flow to narrow the output to certain source/destination subnets or UDP/TCP port numbers. That is more efficient than having the router convert the entire Netflow table to text and then filtering 99.9% of the text away by regexp. Does the ASR1k software have these kinds of options? Best regards, -- Simon. ___ 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 Security Advisory: Cisco TelePresence System Integrator C Series and Cisco TelePresence EX Series Device Default Root Account Manufacturing Error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Cisco TelePresence System Integrator C Series and Cisco TelePresence EX Series Device Default Root Account Manufacturing Error Advisory ID: cisco-sa-2009-telepresence-c-ex-series Revision 1.0 For Public Release 2011 November 9 16:00 UTC (GMT) +- Summary === Software that runs on Cisco TelePresence System Integrator C Series and Cisco TelePresence EX Series devices was updated to include secure default configurations beginning with the TC4.0 release. This change was accompanied by the release of Cisco Security Advisory cisco-sa-20110202-tandberg. Due to a manufacturing error, Cisco TelePresence System Integrator C Series and Cisco TelePresence EX Series devices that were distributed between November 18th, 2010 and September 19th, 2011 may have the root account enabled. Information on how to identify affected devices is available in the Details section of this advisory. Information on how to remediate this issue is available in the Workarounds section of this advisory. This advisory is posted at: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-2009-telepresence-c-ex-series Affected Products = The following products are only affected if they were distributed between November 18th, 2010 and September 19th, 2011 with software release TC4.0, TC4.1, or TC4.2. Vulnerable Products +-- All Cisco TelePresence System Integrator C Series, Cisco TelePresence EX Series, and Cisco TelePresence Quick Set products that were distributed within the designated timeframe are potentially affected. Administrators can determine the status of their device by using the Serial Number Validator located at the following link: http://serialnumbervalidation.com/PSIRT-20111026 The Serial Number Validator tool will indicate if the device was affected when the product was shipped. If a factory reset or software upgrade occurred or certain manual configuration changes were made, the device may not be affected. Products Confirmed Not Vulnerable + Cisco TelePresence System Integrator C Series and Cisco TelePresence EX Series devices that were distributed prior to November 18th, 2010 or after September 19th, 2011 are not affected by this vulnerability. No other Cisco products are currently known to be affected. Details === Cisco TelePresence System Integrator C Series and Cisco TelePresence EX Series devices bring an immersive, interactive, and engaging experience to person-to-person or group telepresence calls. Default Root Account +--- As the result of an error that occurred during the manufacturing and distribution process, affected products may have been distributed with an insecure configuration. The vulnerability is due to a failure to return devices to default configurations after license/option configuration and testing. Affected devices may have the root account enabled and configured with a well-known default password. This account is intended to be enabled by device administrators when certain debugging actions need to be performed and should be disabled by default. Administrators may verify the configuration of affected devices by using one of the following methods: For devices that are running TC4.0 or 4.1 software, administrators may view the serial number of an affected device by logging in to the command line of an affected device with the admin account and issuing the xstatus systemunit hardware command. View Serial Number: +-- ssh admin@203.113.55 Welcome to TANDBERG Codec Release TC4.1.0.247017 SW Release Date: 2011-01-28 OK systemtools xstatus producttype *s SystemUnit Hardware Module SerialNumber: ABC123456789 *s SystemUnit Hardware Module Identifier: 05 *s SystemUnit Hardware MainBoard SerialNumber: ABC123456 *s SystemUnit Hardware MainBoard Identifier: 101551-3 [05] *s SystemUnit Hardware BootSoftware: U-Boot 2010.06-81 ** end Determining the State of the Root Account: +- As the result of a functional defect that was introduced in software release TC4.0, the systemtools rootsettings get command will always return a value of off. To accurately determine the state of the root account on devices that are running software release TC4.0 or TC4.1, administrators should attempt to open an SSH connection to an affected device as root. Root Account Enabled: +- ssh root@203.0.113.55 [tandberg:~] $ Root Account Disabled: ssh root@203.0.113.55 Password: Password: Password: Permission denied (publickey,keyboard-interactive) For devices that are running software release TC4.2, administrators can view the serial number or status of the root account by logging in to the command line of an affected device
[c-nsp] Cat 6500 w/ SUP720 for Multi-Cast
Hello, Does anyone have any experience with the Sup720 and multicast? Looking to find out how many IGMP groups the 720 will support and if we would need the 3BXL or if the 3B would be sufficient. The application is heavy video streaming. Cisco says Nexus but would prefer to stick with my trusty 6500s. Any assistance would be greatly appreciated! * Ronen* ___ 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] Cat 6500 w/ SUP720 for Multi-Cast
On Wed, 9 Nov 2011, Ronen Isaac wrote: Hello, Does anyone have any experience with the Sup720 and multicast? Looking to find out how many IGMP groups the 720 will support and if we would need the 3BXL or if the 3B would be sufficient. The application is heavy video streaming. Cisco says Nexus but would prefer to stick with my trusty 6500s. Any assistance would be greatly appreciated! I have multicast running on my 6509s (Sup720-3BXLs), however I wouldn't necessarily describe our environment as one where multicast is used heavily. It works, but I don't have any numbers immediately handy as to the number of IGMP groups it will support. If v6 multicast is something you're concerned about, I don't think it's handled in hardware on the 720. jms ___ 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] understanding interface traffic counters of Cisco router and Cisco switch
I made a following setup: http://img828.imageshack.us/img828/5736/interfacestrafficcounte.png ..and executed iperf -s -u -fm in ubuntu machine and iperf -c 10.10.11.2 -fm -u -d -b 10m -t600 in PE860 machine. Before the test I cleared all interface counters. Iperf results were following: root@PE860:~# iperf -c 10.10.11.2 -fm -u -d -b 10m -t600 Server listening on UDP port 5001 Receiving 1470 byte datagrams UDP buffer size: 0.12 MByte (default) Client connecting to 10.10.11.2, UDP port 5001 Sending 1470 byte datagrams UDP buffer size: 0.12 MByte (default) [ 3] local 10.10.10.2 port 44911 connected with 10.10.11.2 port 5001 [ 4] local 10.10.10.2 port 5001 connected with 10.10.11.2 port 49469 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 4] 0.0-600.0 sec715 MBytes 10.0 Mbits/sec 0.008 ms0/510205 (0%) [ 4] 0.0-600.0 sec 1 datagrams received out-of-order [ 3] 0.0-600.0 sec715 MBytes 10.0 Mbits/sec [ 3] Sent 510206 datagrams [ 3] Server Report: [ 3] 0.0-600.0 sec715 MBytes 10.0 Mbits/sec 0.026 ms 2/510205 (0.00039%) [ 3] 0.0-600.0 sec 1 datagrams received out-of-order root@PE860:~# For some reason, the interface counters in switch(Fa0/1, Fa0/2, Fa0/23 and Fa0/24): Cisco2950#show interfaces Fa0/1 | i packets input|packets output 510227 packets input, 773472188 bytes, 0 no buffer 510236 packets output, 773484380 bytes, 0 underruns Cisco2950#show interfaces Fa0/2 | i packets input|packets output 510225 packets input, 773476416 bytes, 0 no buffer 510223 packets output, 773471932 bytes, 0 underruns Cisco2950#show interfaces Fa0/23 | i packets input|packets output 510230 packets input, 773476736 bytes, 0 no buffer 510233 packets output, 773479832 bytes, 0 underruns Cisco2950#show interfaces Fa0/24 | i packets input|packets output 510222 packets input, 773471868 bytes, 0 no buffer 510226 packets output, 773476480 bytes, 0 underruns Cisco2950# ..show little bit different results than router counters: C3640#show interfaces Fa2/0 | i packets input|packets output 510228 packets input, 771431340 bytes 510230 packets output, 771435816 bytes, 0 underruns C3640#show interfaces Fa3/0 | i packets input|packets output 510226 packets input, 771435576 bytes 510222 packets output, 771430980 bytes, 0 underruns C3640# I tried this test multiple times with different bandwidth(-b) values and always the difference between router counters and switch counters were ~0.3%. If the difference were 1.2% - 1.3% then it would make sense because probably in this case router counts only up to IP header, but switch includes L2 header as well, but what might cause this 0.3% difference? 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/
[c-nsp] ASR9k to 6500 optic incompatibility
Good evening list, Cisco has claimed that the following optics are compatible: SFP-GE-S= 1000BASE-SX SFP transceiver module for MMF, 850-nm wavelength, extended operating temperature range and DOM support, dual LC/PC connector GLC-SX-MM= 1000BASE-SX SFP transceiver module for MMF, 850-nm wavelength, dual LC/PC connector I have a mindbender of a problem going on in both the lab and production currently. I have an ASR9006 running IOX 4.1.1 with: NAME: module 0/0/CPU0, DESCR: 2-Port 10GE, 20-Port GE Line Card, Requires XFPs and SFPs PID: A9K-2T20GE-B , VID: V04, SN: FOC152786XX And in port 19 a SFP-GE-S: NAME: module mau GigabitEthernet0/0/CPU0/19, DESCR: 1000BASE-SX SFP (DOM), MMF, 550/220m PID: SFP-GE-S , VID: V01 , SN: FNS15411KXX The interface on the asr is showing up/up. RP/0/RSP0/CPU0:oma00-dev-asr9006-1# show int gig0/0/0/19 Wed Nov 9 23:48:20.306 UTC GigabitEthernet0/0/0/19 is up, line protocol is up Interface state transitions: 7 Hardware is GigabitEthernet, address is 4055.3954.2d9d (bia 4055.3954.2d9d) Internet address is 1.1.1.1/30 MTU 1514 bytes, BW 100 Kbit (Max: 100 Kbit) reliability 255/255, txload 0/255, rxload 0/255 Encapsulation ARPA, Full-duplex, 1000Mb/s, SXFD, link type is force-up output flow control is off, input flow control is off loopback not set, ARP type ARPA, ARP timeout 04:00:00 Last input never, output 00:05:04 Last clearing of show interface counters never 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 0 packets input, 0 bytes, 0 total input drops 0 drops for unrecognized upper-level protocol Received 0 broadcast packets, 0 multicast packets 0 runts, 0 giants, 0 throttles, 0 parity 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 3 packets output, 192 bytes, 0 total output drops Output 3 broadcast packets, 0 multicast packets 0 output errors, 0 underruns, 0 applique, 0 resets 0 output buffer failures, 0 output buffers swapped out 7 carrier transitions On the other end of the tested 3m multimode jumper is a catalyst 6500 running SXJ1 with: NAME: 6, DESCR: VS-S720-10G 5 ports Supervisor Engine 720 10GE Rev. 3.1 PID: VS-S720-10G , VID: V04, SN: SAL13431RXX The optic on the 6k is a GLC-SX-MM: oma00-dev-c6506-1(config-if)# do show idprom int gig6/1 Transceiver Serial EEPROM Contents: Common block: Identifier: SFP [0x03] Connector : LC [0x07] Transceiver Speed: Unspecified [0x00] Media: Unspecified [0x00] Technology : Unspecified [0x00] Link Length : [0x01] GE Comp Codes: Unspecified [0x00] SONET Comp Codes : Unspecified [0x00] Encoding : 8B10B [0x01] BR, Nominal : 13x100 MHz [0x0D] Length(9u): Transceiver does not support single mode fibre, or the length information must be determined from the transceiver technology. [0x00] Length(50u) : 55 x 10 m [0x37] Length(62.5u) : 27 x 10 m [0x1B] Length(Copper): Transceiver does not support copper cables, or the length information must be determined from the transceiver technology. [0x00] Vendor Name : CISCO-FINISAR Vendor OUI: 0x0 0x90 0x65 Vendor PN : FTLF8519P2BCL-C5 Vendor rev: A CC_BASE : 0x5F Extended ID Fields Options : Loss of Signal implemented TX_DISABLE is implemented and disables the serial output BR, max : Unspecified 0% BR, min : Unspecified 0% Vendor SN : FNS15251SXX Date code : 110618 CC_EXT: 0xDA Vendor Specific ID Fields: 0x00: 00 00 02 D3 FB D3 38 43 25 7F 85 76 0A E3 08 51 0x10: A0 2A 22 00 00 00 00 00 00 00 00 00 D6 D5 78 3A Product ID: Unspecified Version ID: Unspecified And interface Gig6/1 on the 6k is down/down: oma00-dev-c6506-1(config-if)#do show int gig6/1 GigabitEthernet6/1 is down, line protocol is down (notconnect) Hardware is C6k 1000Mb 802.3, address is 0019.0774.3c00 (bia 0019.0774.3c00) MTU 1500 bytes, BW 100 Kbit, DLY 10 usec, reliability 255/255, txload 0/255, rxload 0/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is SX input flow-control is off, output flow-control is desired Clock mode is auto ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output never, output hang never Last clearing of show interface counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0
Re: [c-nsp] ASR9k to 6500 optic incompatibility
ASR only supports the 100m-fx GLC. The rest need to be SFP to work at all. Jared Mauch On Nov 9, 2011, at 6:59 PM, cisco...@secureobscure.com wrote: Good evening list, Cisco has claimed that the following optics are compatible: SFP-GE-S= 1000BASE-SX SFP transceiver module for MMF, 850-nm wavelength, extended operating temperature range and DOM support, dual LC/PC connector GLC-SX-MM= 1000BASE-SX SFP transceiver module for MMF, 850-nm wavelength, dual LC/PC connector I have a mindbender of a problem going on in both the lab and production currently. I have an ASR9006 running IOX 4.1.1 with: NAME: module 0/0/CPU0, DESCR: 2-Port 10GE, 20-Port GE Line Card, Requires XFPs and SFPs PID: A9K-2T20GE-B , VID: V04, SN: FOC152786XX And in port 19 a SFP-GE-S: NAME: module mau GigabitEthernet0/0/CPU0/19, DESCR: 1000BASE-SX SFP (DOM), MMF, 550/220m PID: SFP-GE-S , VID: V01 , SN: FNS15411KXX The interface on the asr is showing up/up. RP/0/RSP0/CPU0:oma00-dev-asr9006-1# show int gig0/0/0/19 Wed Nov 9 23:48:20.306 UTC GigabitEthernet0/0/0/19 is up, line protocol is up Interface state transitions: 7 Hardware is GigabitEthernet, address is 4055.3954.2d9d (bia 4055.3954.2d9d) Internet address is 1.1.1.1/30 MTU 1514 bytes, BW 100 Kbit (Max: 100 Kbit) reliability 255/255, txload 0/255, rxload 0/255 Encapsulation ARPA, Full-duplex, 1000Mb/s, SXFD, link type is force-up output flow control is off, input flow control is off loopback not set, ARP type ARPA, ARP timeout 04:00:00 Last input never, output 00:05:04 Last clearing of show interface counters never 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 0 packets input, 0 bytes, 0 total input drops 0 drops for unrecognized upper-level protocol Received 0 broadcast packets, 0 multicast packets 0 runts, 0 giants, 0 throttles, 0 parity 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 3 packets output, 192 bytes, 0 total output drops Output 3 broadcast packets, 0 multicast packets 0 output errors, 0 underruns, 0 applique, 0 resets 0 output buffer failures, 0 output buffers swapped out 7 carrier transitions On the other end of the tested 3m multimode jumper is a catalyst 6500 running SXJ1 with: NAME: 6, DESCR: VS-S720-10G 5 ports Supervisor Engine 720 10GE Rev. 3.1 PID: VS-S720-10G , VID: V04, SN: SAL13431RXX The optic on the 6k is a GLC-SX-MM: oma00-dev-c6506-1(config-if)# do show idprom int gig6/1 Transceiver Serial EEPROM Contents: Common block: Identifier: SFP [0x03] Connector : LC [0x07] Transceiver Speed: Unspecified [0x00] Media: Unspecified [0x00] Technology : Unspecified [0x00] Link Length : [0x01] GE Comp Codes: Unspecified [0x00] SONET Comp Codes : Unspecified [0x00] Encoding : 8B10B [0x01] BR, Nominal : 13x100 MHz [0x0D] Length(9u): Transceiver does not support single mode fibre, or the length information must be determined from the transceiver technology. [0x00] Length(50u) : 55 x 10 m [0x37] Length(62.5u) : 27 x 10 m [0x1B] Length(Copper): Transceiver does not support copper cables, or the length information must be determined from the transceiver technology. [0x00] Vendor Name : CISCO-FINISAR Vendor OUI: 0x0 0x90 0x65 Vendor PN : FTLF8519P2BCL-C5 Vendor rev: A CC_BASE : 0x5F Extended ID Fields Options : Loss of Signal implemented TX_DISABLE is implemented and disables the serial output BR, max : Unspecified 0% BR, min : Unspecified 0% Vendor SN : FNS15251SXX Date code : 110618 CC_EXT: 0xDA Vendor Specific ID Fields: 0x00: 00 00 02 D3 FB D3 38 43 25 7F 85 76 0A E3 08 51 0x10: A0 2A 22 00 00 00 00 00 00 00 00 00 D6 D5 78 3A Product ID: Unspecified Version ID: Unspecified And interface Gig6/1 on the 6k is down/down: oma00-dev-c6506-1(config-if)#do show int gig6/1 GigabitEthernet6/1 is down, line protocol is down (notconnect) Hardware is C6k 1000Mb 802.3, address is 0019.0774.3c00 (bia 0019.0774.3c00) MTU 1500 bytes, BW 100 Kbit, DLY 10 usec, reliability 255/255, txload 0/255, rxload 0/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is SX input flow-control is off, output flow-control is desired Clock mode is auto ARP type: ARPA, ARP Timeout 04:00:00 Last
Re: [c-nsp] ASR9k to 6500 optic incompatibility
We just figured it out, the asr9k in 4.1.1 has this: Full-duplex, 1000Mb/s, SXFD, link type is force-up Adding negotiation auto under every fiber SFP interface having the issue has resolved it: Full-duplex, 1000Mb/s, SXFD, link type is autonegotiation Thanks! -Original Message- From: Jared Mauch [mailto:ja...@puck.nether.net] Sent: Wednesday, November 09, 2011 7:36 PM To: cisco...@secureobscure.com Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASR9k to 6500 optic incompatibility ASR only supports the 100m-fx GLC. The rest need to be SFP to work at all. Jared Mauch On Nov 9, 2011, at 6:59 PM, cisco...@secureobscure.com wrote: Good evening list, Cisco has claimed that the following optics are compatible: SFP-GE-S= 1000BASE-SX SFP transceiver module for MMF, 850-nm wavelength, extended operating temperature range and DOM support, dual LC/PC connector GLC-SX-MM= 1000BASE-SX SFP transceiver module for MMF, 850-nm wavelength, dual LC/PC connector I have a mindbender of a problem going on in both the lab and production currently. I have an ASR9006 running IOX 4.1.1 with: NAME: module 0/0/CPU0, DESCR: 2-Port 10GE, 20-Port GE Line Card, Requires XFPs and SFPs PID: A9K-2T20GE-B , VID: V04, SN: FOC152786XX And in port 19 a SFP-GE-S: NAME: module mau GigabitEthernet0/0/CPU0/19, DESCR: 1000BASE-SX SFP (DOM), MMF, 550/220m PID: SFP-GE-S , VID: V01 , SN: FNS15411KXX The interface on the asr is showing up/up. RP/0/RSP0/CPU0:oma00-dev-asr9006-1# show int gig0/0/0/19 Wed Nov 9 23:48:20.306 UTC GigabitEthernet0/0/0/19 is up, line protocol is up Interface state transitions: 7 Hardware is GigabitEthernet, address is 4055.3954.2d9d (bia 4055.3954.2d9d) Internet address is 1.1.1.1/30 MTU 1514 bytes, BW 100 Kbit (Max: 100 Kbit) reliability 255/255, txload 0/255, rxload 0/255 Encapsulation ARPA, Full-duplex, 1000Mb/s, SXFD, link type is force-up output flow control is off, input flow control is off loopback not set, ARP type ARPA, ARP timeout 04:00:00 Last input never, output 00:05:04 Last clearing of show interface counters never 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 0 packets input, 0 bytes, 0 total input drops 0 drops for unrecognized upper-level protocol Received 0 broadcast packets, 0 multicast packets 0 runts, 0 giants, 0 throttles, 0 parity 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 3 packets output, 192 bytes, 0 total output drops Output 3 broadcast packets, 0 multicast packets 0 output errors, 0 underruns, 0 applique, 0 resets 0 output buffer failures, 0 output buffers swapped out 7 carrier transitions On the other end of the tested 3m multimode jumper is a catalyst 6500 running SXJ1 with: NAME: 6, DESCR: VS-S720-10G 5 ports Supervisor Engine 720 10GE Rev. 3.1 PID: VS-S720-10G , VID: V04, SN: SAL13431RXX The optic on the 6k is a GLC-SX-MM: oma00-dev-c6506-1(config-if)# do show idprom int gig6/1 Transceiver Serial EEPROM Contents: Common block: Identifier: SFP [0x03] Connector : LC [0x07] Transceiver Speed: Unspecified [0x00] Media: Unspecified [0x00] Technology : Unspecified [0x00] Link Length : [0x01] GE Comp Codes: Unspecified [0x00] SONET Comp Codes : Unspecified [0x00] Encoding : 8B10B [0x01] BR, Nominal : 13x100 MHz [0x0D] Length(9u): Transceiver does not support single mode fibre, or the length information must be determined from the transceiver technology. [0x00] Length(50u) : 55 x 10 m [0x37] Length(62.5u) : 27 x 10 m [0x1B] Length(Copper): Transceiver does not support copper cables, or the length information must be determined from the transceiver technology. [0x00] Vendor Name : CISCO-FINISAR Vendor OUI: 0x0 0x90 0x65 Vendor PN : FTLF8519P2BCL-C5 Vendor rev: A CC_BASE : 0x5F Extended ID Fields Options : Loss of Signal implemented TX_DISABLE is implemented and disables the serial output BR, max : Unspecified 0% BR, min : Unspecified 0% Vendor SN : FNS15251SXX Date code : 110618 CC_EXT: 0xDA Vendor Specific ID Fields: 0x00: 00 00 02 D3 FB D3 38 43 25 7F 85 76 0A E3 08 51 0x10: A0 2A 22 00 00 00 00 00 00 00 00 00 D6 D5 78 3A Product ID: Unspecified Version ID: Unspecified And interface Gig6/1 on the 6k is down/down: oma00-dev-c6506-1(config-if)#do show int
Re: [c-nsp] understanding interface traffic counters of Cisco router and Cisco switch
Hi, Most likely this is because of 802.1Q tag (4 bytes) added to the counter on a switch interface (and obviously you don't see this tag on a router interface). For example, interfaces Fa3/0 and Fa0/24: 773476480 - 771435576 = 2040904 2040904 / 510226 = 4 HTH Martin T wrote: I made a following setup: http://img828.imageshack.us/img828/5736/interfacestrafficcounte.png ..and executed iperf -s -u -fm in ubuntu machine and iperf -c 10.10.11.2 -fm -u -d -b 10m -t600 in PE860 machine. Before the test I cleared all interface counters. Iperf results were following: root@PE860:~# iperf -c 10.10.11.2 -fm -u -d -b 10m -t600 Server listening on UDP port 5001 Receiving 1470 byte datagrams UDP buffer size: 0.12 MByte (default) Client connecting to 10.10.11.2, UDP port 5001 Sending 1470 byte datagrams UDP buffer size: 0.12 MByte (default) [ 3] local 10.10.10.2 port 44911 connected with 10.10.11.2 port 5001 [ 4] local 10.10.10.2 port 5001 connected with 10.10.11.2 port 49469 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 4] 0.0-600.0 sec715 MBytes 10.0 Mbits/sec 0.008 ms0/510205 (0%) [ 4] 0.0-600.0 sec 1 datagrams received out-of-order [ 3] 0.0-600.0 sec715 MBytes 10.0 Mbits/sec [ 3] Sent 510206 datagrams [ 3] Server Report: [ 3] 0.0-600.0 sec715 MBytes 10.0 Mbits/sec 0.026 ms 2/510205 (0.00039%) [ 3] 0.0-600.0 sec 1 datagrams received out-of-order root@PE860:~# For some reason, the interface counters in switch(Fa0/1, Fa0/2, Fa0/23 and Fa0/24): Cisco2950#show interfaces Fa0/1 | i packets input|packets output 510227 packets input, 773472188 bytes, 0 no buffer 510236 packets output, 773484380 bytes, 0 underruns Cisco2950#show interfaces Fa0/2 | i packets input|packets output 510225 packets input, 773476416 bytes, 0 no buffer 510223 packets output, 773471932 bytes, 0 underruns Cisco2950#show interfaces Fa0/23 | i packets input|packets output 510230 packets input, 773476736 bytes, 0 no buffer 510233 packets output, 773479832 bytes, 0 underruns Cisco2950#show interfaces Fa0/24 | i packets input|packets output 510222 packets input, 773471868 bytes, 0 no buffer 510226 packets output, 773476480 bytes, 0 underruns Cisco2950# ..show little bit different results than router counters: C3640#show interfaces Fa2/0 | i packets input|packets output 510228 packets input, 771431340 bytes 510230 packets output, 771435816 bytes, 0 underruns C3640#show interfaces Fa3/0 | i packets input|packets output 510226 packets input, 771435576 bytes 510222 packets output, 771430980 bytes, 0 underruns C3640# I tried this test multiple times with different bandwidth(-b) values and always the difference between router counters and switch counters were ~0.3%. If the difference were 1.2% - 1.3% then it would make sense because probably in this case router counts only up to IP header, but switch includes L2 header as well, but what might cause this 0.3% difference? 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/ ___ 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/
