Re: [c-nsp] Wierd MPLS/VPLS issue
Hi Simon, WE have investigated this issue (I work for INSBU Engineering that designed these ASICs), and the issue is not an ASIC bug, but a wrong flag set by SW, which will be fixed. I will re-open the bug and we will get it resolved. We will reach out to you through the TAC and account team offline to resolve this ASAP using workaround , until the fixed SW is available. If needed, we can make an RPM patch available for you. Should you have any questions, please feel free to unicast me. thanks sukumar On 12/2/16, 5:42 AM, "cisco-nsp on behalf of Simon Lockhart" wrote: On Fri Dec 02, 2016 at 03:40:03PM +0200, Mark Tinka wrote: > Good to know. > > We are currently considering the 9508 for a particular role (Layer 2 > only), and I know they are based on the Broadcom chip. I'm guessing this > is where the limitation is coming from, yes? The 92160 is based on Cisco silicon (ASE3, I think). So they can't even blame Broadcom :) 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/ ___ 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] Nexus ip arp alias
This support is not present in NxOS. sukumar On 11/12/15, 10:01 AM, "cisco-nsp on behalf of Crist J. Clark" wrote: >What is the equivalent of the IOS command, > > ip arp arpa alias > >In NXOS? I know about, ip arp , on Nexus, but how >do I get the behavior added by alias keyword? >-- >Crist J. Clark >___ >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] EARL_L2_ASIC-SP-4-DBUS_HDR_ERR
Unfortunately, it is not possible.. as the error is seen on the DBUs.So, it could be any linecard. If you started seeing this issue recenty, you may want to check and see what was the last linecard or Sup you added to system and go from there.. To rule out a bad sup you can do switchover to standby if present, or move sup to other slot and see.. This is unfortnately, a process of elimitation in the older bus based architectures. sukumar On 1/15/14 5:56 PM, "PlaWanSai RMUTT CPE IX" wrote: >Could you specify which card is a problem? > >Thank you very much. > >-Original Message- >From: Sukumar Subburayan (sukumars) [mailto:sukum...@cisco.com] >Sent: Wednesday, January 15, 2014 10:25 PM >To: PlaWanSai RMUTT CPE IX; cisco-nsp@puck.nether.net >Cc: Panuwat Santukaw; Somphong Pokfai; p.pansa...@gmail.com >Subject: Re: [c-nsp] EARL_L2_ASIC-SP-4-DBUS_HDR_ERR > >Error in the DBUS (data bus) header indicates that you have had hardware. > >Either a bad Sup or linecard or backplane.. If you have redundant sup, you >switchover to that and observe if the problem goes away. > >sukumar > >On 1/14/14 8:16 PM, "PlaWanSai RMUTT CPE IX" >wrote: > >>Hi, >> Today, I saw this log in my 7609. And my customer told me that while > >>the log appear he saw the EIGRP down, up on his router. How to >>troubleshoot it? I can't open TAC case because the warranty is expired. >> >>Thank you very much. >> >>___ >>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] EARL_L2_ASIC-SP-4-DBUS_HDR_ERR
Error in the DBUS (data bus) header indicates that you have had hardware. Either a bad Sup or linecard or backplane.. If you have redundant sup, you switchover to that and observe if the problem goes away. sukumar On 1/14/14 8:16 PM, "PlaWanSai RMUTT CPE IX" wrote: >Hi, > Today, I saw this log in my 7609. And my customer told me that while >the log appear he saw the EIGRP down, up on his router. How to >troubleshoot >it? I can't open TAC case because the warranty is expired. > >Thank you very much. > >___ >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] Nexus 7K NX-OS Upgrade
Any new CoPP best Practice configs update available in the new code is applied only when using install script. sukumar Thumb typed on my Smartphone. Excuse Typos. On Nov 8, 2012, at 7:54 AM, "Tim Stevenson (tstevens)" wrote: > At 07:18 AM 11/8/2012, Antonio Soares mused: >> I just have one SUP... You are talking about dual supervisors setup, right ? > > > Ah. In that case, clearly, the box is going to go offline when you upgrade. > You might want to consider buying another sup. > > IMO, there is no huge benefit in using the install all script in a single sup > system - in the end, all it will do for you is a little sanity checking and > maybe save you from fat fingering a bootstring. > > In your situation, I would copy over the new images you want; manually change > the bootstrings & save to startup; power off the box, yank the sup & add the > DRAM; and then power it all back on. > > Tim > > > >> Regards, >> >> Antonio Soares, CCIE #18473 (R&S/SP) >> amsoa...@netcabo.pt >> http://www.ccie18473.net >> >> >> >> -Original Message- >> From: Dirk Woellhaf [mailto:dirk.woell...@gmail.com] >> Sent: quinta-feira, 8 de Novembro de 2012 14:10 >> To: Antonio Soares >> Cc: Charles Spurgeon; cisco-nsp >> Subject: Re: [c-nsp] Nexus 7K NX-OS Upgrade >> >> Hi Antonio, >> >> You should be able to do the memory-upgrade without rebooting the box. >> I've never done it on my I own but I know a few which did without any >> problem. I believe they first upgraded the memory and then did the update! >> >> Dirk >> >> Sent from my iPhone >> >> On 08.11.2012, at 13:42, Antonio Soares wrote: >> >> > Thanks, I don't know if you noticed but somewhere in the thread the >> > bug was mentioned and it is resolved in 5.1.5 and later. >> > >> > Bug CSCtn61286 - Boot variables are not set up correctly on Sup-2 >> > after ISSU >> > >> > So in my case, it should not give me problems (5.2.3a to 5.2.7). >> > >> > But since I also need to upgrade the SUP1 RAM from 4G to 8G, I have no >> > other option than doing the traditional upgrade. It's the only way to >> > just send the box down 1 time: >> > >> > - update the boot variables >> > - power off and upgrade the RAM >> > - power on >> > >> > The install all script has another limitation: it won't let us to >> > reboot when we chose to do it. This is what happened to me last time: >> > >> > + >> > Switch will be reloaded for disruptive upgrade. >> > Do you want to continue with the installation (y/n)? y >> > >> > Install is in progress, please wait. >> > >> > (..) >> > >> > A few minutes later: >> > >> > Finishing the upgrade, switch will reboot in 10 seconds. >> > + >> > >> > I don't see how to upgrade the RAM and upgrade the NX-OS with the >> > install script in just one shot... >> > >> > >> > Regards, >> > >> > Antonio Soares, CCIE #18473 (R&S/SP) >> > amsoa...@netcabo.pt >> > http://www.ccie18473.net >> > >> > >> > -Original Message- >> > From: Charles Spurgeon [mailto:c.spurg...@austin.utexas.edu] >> > Sent: quinta-feira, 8 de Novembro de 2012 00:50 >> > To: Antonio Soares >> > Cc: 'Tóth András'; 'cisco-nsp' >> > Subject: Re: [c-nsp] Nexus 7K NX-OS Upgrade >> > >> > While doing some more testing this aft I also removed the sup from >> > slot 5 and did a "disruptive" single sup ISSU upgrade from 5.1(5) to >> > 5.2(7) on the slot 6 sup without issues. >> > >> > -Charles >> > >> > On Tue, Nov 06, 2012 at 11:48:35PM +, Antonio Soares wrote: >> >> Great, I must confess that I searched a lot and I didn't find this >> >> bug. So I suppose the install all script will work well this time. I >> >> will come back to the list next week with the good news. I hope :) >> >> >> >> >> >> Thanks. >> >> >> >> Regards, >> >> >> >> Antonio Soares, CCIE #18473 (R&S/SP) >> >> amsoa...@netcabo.pt >> >> http://www.ccie18473.net >> >> >> >> >> >> >> >> -Original Message- >> >> From: Tóth András [mailto:diosbej...@gmail.com] >> >> Sent: terça-feira, 6 de Novembro de 2012 23:35 >> >> To: Antonio Soares >> >> Cc: cisco-nsp >> >> Subject: Re: [c-nsp] Nexus 7K NX-OS Upgrade >> >> >> >> Hi Antonio, >> >> >> >> In general, doing a traditional upgrade (changing boot variables) >> >> will not update the BIOS for example, while an ISSU does and it's >> >> non-disruptive with dual-supervisors. >> >> >> >> There's a defect which caused the behavior you were seeing, >> >> CSCtn61286 which affects 5.1(3). Since you were upgrading from that >> >> version, it was still impacting the upgrade process. It has been >> >> fixed in 5.1(4) and 5.2(1) already, so upgrading from 5.2(3a) to >> >> 5.2(7) will not have the >> > same issue. >> >> >> >> http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?met >> >> h >> >> od=fet >> >> chBugDetails&bugId=CSCtn61286 >> >> >> >> >> >> If the boot variables are incorrect, you can edit them as you'd do on >> >> an IOS device, make sure you update the kickstart and system as well. >> >> >> >> Upgradi
Re: [c-nsp] RES: VLAN internal usage
It is a bug.. We will file one to get it fixed. sukumar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Rathlev Sent: Wednesday, December 03, 2008 6:14 AM To: cisco-nsp Subject: Re: [c-nsp] RES: VLAN internal usage Hi, On Tue, 2008-12-02 at 20:46 -0300, Leonardo Gama Souza wrote: > So the command 'show platform hardware capacity vlan' should be > tracking the free internal VLANs, but this is not happening: > > 7609#show platform hardware capacity vlan VLAN Resources > VLANs: 4094 total, 68 VTP, 0 extended, 16 internal, 4010 free > > As subinterfaces use "internal VLANs", I am actually using 18 internal > VLANs here. It seems this command is only tracking the "internal VLANs" > in the range 1006-4094 (automatically allocated by IOS). > Am I missing anything? Interesting; you are quite right: I tried moving a sub-interface between "encapsulation dot1q 6" and "encapsulation dot1q 3800", and the output changed: Switch(config-subif)#int gi4/8.6 Switch(config-subif)#enc dot 6 Switch(config-subif)#do sh pla har cap vl VLAN Resources VLANs: 4094 total, 130 VTP, 58 extended, 22 internal, 3884 free Switch(config-subif)#enc dot 3800 Switch(config-subif)#do sh pla har cap vl VLAN Resources VLANs: 4094 total, 130 VTP, 58 extended, 23 internal, 3883 free Switch(config-subif)# So if I use VLAN 6, I have an extra VLAN. I'm scheduling a service window a.s.a.p.! :-) (Or more realistically the output from the command is wrong...) Regards, Peter ___ 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] SP: L2-Aging messages
Someone has turned on L2-aging debugging on the SP-side. These are periodic RM (router-mac) entry aging debugs, and these debug outputs don't indicate any problem. Please have them do 'remote command switch undebug all' sukumar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Everton Diniz Sent: Sunday, July 20, 2008 7:17 AM To: cisco-nsp Subject: [c-nsp] SP: L2-Aging messages Hi all, Anyone already see this message? I searched on cisco swit and google and nothing... Jul 19 23:12:37.057 BRA: SP: L2-Aging : l2_aging_do_rm_rma_aging, entry not found Jul 19 23:17:37.056 BRA: SP: L2-Aging : l2_aging_do_rm_rma_aging, entry not found Jul 19 23:22:37.057 BRA: SP: L2-Aging : l2_aging_do_rm_rma_aging, entry not found Jul 19 22:27:37.058 BRA: SP: L2-Aging : l2_aging_do_rm_rma_aging, entry not found IOS (tm) s72033_rp Software (s72033_rp-PK9SV-M), Version 12.2(17d)SXB10, RELEASE SOFTWARE (fc1) cisco WS-C6509 (R7000) processor (revision 2.0) with 458752K/65536K bytes of memory. Supervisor Engine 720 (Active) WS-SUP720-3B SAL094235C0 ___ 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 VSS monitoring through Syslog/SNMP-traps
Dual-active cases (VSL down) cannot be detected by below. We need to use the 'vswitch vsl' trap for that. sukumar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Koen Sent: Tuesday, July 01, 2008 4:40 PM Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cisco VSS monitoring through Syslog/SNMP-traps Hi Anthony, I was just looking for this too and found out the following you can use to make a check: MIB CISCO-VIRTUAL-SWITCH-MIB Object cvsChassisEntry OID 1.3.6.1.4.1.9.9.388.1.2.2.1 TypeCvsChassisEntry Description "An entry describes the present chassis information in the virtual switch architecture." Object cvsChassisRole OID 1.3.6.1.4.1.9.9.388.1.2.2.1.2 TypeVSSwitchRole 1:standalone 2:active 3:standby Greetz, Koen Anthony Guéneau wrote: > Hi, > > Does anybody know what syslog messages are supposed to be sent when a > VSS failover occurs? > Would it be easier to monitor it through SNMP traps? In that case what > kind of traps should I enable and what are the corresponding OID to > handle from the server? > The main idea is to detect any failures within the VSS domain. I > identified > 3 types of failures I would need to detect thanks to the syslog > messages or SNMP-traps. Then, corresponding alarms will be generated. Here > they are: > -> Active Supervisor Engine Failure (=Active Virtual Switch Chassis > -> Failure) Hot-standby Supervisor Engine Failure (=Standby Virtual > -> Switch Chassis > Failure) > -> Complete VSL Failure (Dual Active) > > If someone knows or identified syslog messages and/or SNMP traps > corresponding to each of these three failures, could you please get > back to me with these informations? > Many thanks. > > Anthony > ___ > 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 VSS monitoring through Syslog/SNMP-traps
For Complete VSL failure, we have SNMP trap, that can be configured using: vss(config)#snmp-server enable traps vswitch ? vsl Enable SNMP Virtual Switch Link (VSL) notification For Active supervisor failure, you can monitor the following syslog message: PFREDUN-SW2_SPSTBY-6-ACTIVE: Initializing as Virtual Switch ACTIVE processor If the message comes from 'SW2' it means that previous active(SW1) went down. For standby supervisor failure, the VSL link will go down, as entire standby is down. So, you could use the VSL link trap. Additionally following syslogs are printed on the active, when standby goes down: %VSLP-SW2_SP-2-VSL_DOWN: All VSL links went down while switch is in ACTIVE role or this: %PFREDUN-SW2_SP-6-ACTIVE: Standby supervisor removed or reloaded, changing to Simplex mode sukumar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anthony Guéneau Sent: Tuesday, July 01, 2008 4:05 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Cisco VSS monitoring through Syslog/SNMP-traps Hi, Does anybody know what syslog messages are supposed to be sent when a VSS failover occurs? Would it be easier to monitor it through SNMP traps? In that case what kind of traps should I enable and what are the corresponding OID to handle from the server? The main idea is to detect any failures within the VSS domain. I identified 3 types of failures I would need to detect thanks to the syslog messages or SNMP-traps. Then, corresponding alarms will be generated. Here they are: -> Active Supervisor Engine Failure (=Active Virtual Switch Chassis -> Failure) Hot-standby Supervisor Engine Failure (=Standby Virtual -> Switch Chassis Failure) -> Complete VSL Failure (Dual Active) If someone knows or identified syslog messages and/or SNMP traps corresponding to each of these three failures, could you please get back to me with these informations? Many thanks. Anthony ___ 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 Optimized ACL Logging (OAL)
To answer your main questions. 1. Is OAL really going to help me that much? There are two benefits of OAL. 1. OAL improves performance from traditional logging which is done at process level, by around 10 folks, with processing done at interrupt level. So, you probably can expect around 20Kpps (instead of 3-4 Kpps) with CPU around 30-40%. 2. With OAL logged packet is forwarded in hardware, while the copy is sent for logging purposes only, and consumed by the RP. So, in other words forwarding of the actual packet is done in HW. A copy is sent for logging purposes. Without OAL, the packet is logged & and forwarded in software at process level. 2. Any caveats/tradeoffs: Since, OAL uses some HW resource on the EARL (PFC/DFC) forwarding engine, if there are other conflicting features, you cannot use it. OAL & VACL capture, cannot work together. So, if you need VACL capture, you cannot use OAL. sukumar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Nguyen Sent: Wednesday, June 25, 2008 5:17 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Cisco Optimized ACL Logging (OAL) Is anyone out there using OAL? It seems very easy to implement but I’d appreciate any feedback about your experience implementing this. I have a 6509 with Sup720/MSFC3 and PFC3B and am not yet using OAL. I have about 30 VLANs with low/negligible traffic volume. I have 4 high volume VLANs with sustained traffic volume of 100Mbps and 30Kpps. I have another 4 medium volume VLANs with about half that volume of traffic. I have 130 line ACLs inbound and outbound on 2/4 of the high and 2/4 of the medium volume VLANs with selective logging of particular lines in the ACLs. My CPU is steady at about 18%. I am in the process of adding ACL’s to the remaining high and medium volume VLANs but have halted my deployment because during initial phases where I was doing more logging than normal to try and identify source/destination pairs, my CPU was spiking to 98%! My main questions are: Is OAL really going to help me that much? Any caveats/tradeoffs when implementing OAL? All feedback is greatly appreciated! ___ 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] 12.2(33)SXH
David, Unfortunately, there is no publicly available doc to interpret this data, as much of these are very Hardware (ASIC) centric information, which cannot make sense unless one has the ASIC specification. The Pinnacle ASIC register dump you did was the right one. If you see those errors incrementing in large number (these are clear on read), you should consider replacing the LC. Not sure what exact Linecard type you have. As a workaround, you can try moving the physical port to any other ports other than what is controlled by port asic 0, as that is what is picking up these errors. sukumar (sent from Good mail) -Original Message- From: David Freedman [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2008 04:48 AM Pacific Standard Time To: Sukumar Subburayan (sukumars) Cc: Rubens Kuhl Jr.; Jeff Fitzwater; cisco-nsp@puck.nether.net Subject:Re: [c-nsp] 12.2(33)SXH Sukumar, I opened a TAC case already about this but nobody has come back to me yet. Can you point me to a document which explains how to interpret this data? is it publically available? Also, I do not know how to get this information any other way, This is all I have: >From the 6500: 6500#sh int g7/1 | in rror|drop|throt Input queue: 1/2000/53/53 (size/max/drops/flushes); Total output drops: 0 0 runts, 352555400 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 10 output errors, 0 collisions, 1 interface resets 6500#sh int g7/2 | in rror|drop|throt Input queue: 0/2000/902/901 (size/max/drops/flushes); Total output drops: 0 0 runts, 1429767336 giants, 1 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 output errors, 0 collisions, 1 interface resets 6500#remote command switch show plat hard asicreg PINNACLE Slot 7 port 1 error-counters print-non-zero PINNACLE 7/1 0158: PI_PN_S_CRC_ERR_CNT_REG = 00FF PINNACLE 7/1 016F: PI_CI_S_CBL_DROP_REG = 0001 6500#remote command switch show plat hard asicreg PINNACLE Slot 7 port 2 error-counters print-non-zero >From the remote partner (GSR1) with link G7/1: GSR1# sh int g1/1/8 | in rror|drop|throt Output queue 0/40, 0 drops; input queue 0/2000, 0 drops Received 18 broadcasts, 0 runts, 3958399257 giants, 0 throttles 0 input errors, 10 CRC, 10 frame, 0 overrun, 0 ignored 0 output errors, 0 collisions, 0 interface resets >From the remote partner (GSR2) with link G7/2: GSR2#sh int g1/1/7 | in rror|drop|throt Output queue 0/40, 0 drops; input queue 0/2000, 0 drops Received 13 broadcasts, 0 runts, 1464946843 giants, 0 throttles 104 input errors, 0 CRC, 104 frame, 0 overrun, 0 ignored 0 output errors, 0 collisions, 0 interface resets Regards, Dave. Sukumar Subburayan (sukumars) wrote: > I might have missed the original post from David Freedman on : > > "CONST_DIAG-SP-4-ERROR_COUNTER_WARNING" > > Actually, printing this syslog is not a bug. In 12.2(33)SXH onwards, we > added 'LinkErrorMonitoring' feature, where > Diagnostics proactively checks for various ASIC/port related errors > periodically, and would print a syslog when these error > Counters exceed threshold. That is exactly what the customer we are > seeing in the case below. > > In this particular case, the error indicates, that there was 3484 Count > of Packet with CRC Error when packet was > Transmitted on the network from a port belonging to port ASIC (Pinnacle) > 0. > > A TAC case is in order, to investigate further if any issues are seen in > the network related to this. I am sure the customer > would have seen these errors even in SXF code, but simply diagnostics > was not monitoring and reporting these errors in that release. > > CSCsm84257 fix should be in SXH3, scheduled tentatively for release end > of next month. > > > sukumar > > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rubens Kuhl Jr. > Sent: Monday, June 23, 2008 6:48 AM > To: Jeff Fitzwater > Cc: cisco-nsp@puck.nether.net > Subject: Re: [c-nsp] 12.2(33)SXH > > "CONST_DIAG-SP-4-ERROR_COUNTER_WARNING - SXH problems?" > http://www.gossamer-threads.com/lists/cisco/nsp/89241?do=post_view_threa > ded > > "SXH2a broken with non-MDT SAFI peers" > http://puck.nether.net/pipermail/cisco-nsp/2008-May/050891.html > > Add to those the one from Oliver Gorwits today: > "CSCsm84257 (enabling NetFlow causes reload) on SXH2 on 6500 platform" > > > Rubens > > > On Sun, Jun 22, 2008 at 8:57 PM, Jeff Fitzwater <[EMAIL PROTECTED]> > wrote: >> Rubens, what issues do you mean? I am running H2a on 5 720-cxls. >> >> Very interested! >> >> >>
Re: [c-nsp] 12.2(33)SXH
I might have missed the original post from David Freedman on : "CONST_DIAG-SP-4-ERROR_COUNTER_WARNING" Actually, printing this syslog is not a bug. In 12.2(33)SXH onwards, we added 'LinkErrorMonitoring' feature, where Diagnostics proactively checks for various ASIC/port related errors periodically, and would print a syslog when these error Counters exceed threshold. That is exactly what the customer we are seeing in the case below. In this particular case, the error indicates, that there was 3484 Count of Packet with CRC Error when packet was Transmitted on the network from a port belonging to port ASIC (Pinnacle) 0. A TAC case is in order, to investigate further if any issues are seen in the network related to this. I am sure the customer would have seen these errors even in SXF code, but simply diagnostics was not monitoring and reporting these errors in that release. CSCsm84257 fix should be in SXH3, scheduled tentatively for release end of next month. sukumar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rubens Kuhl Jr. Sent: Monday, June 23, 2008 6:48 AM To: Jeff Fitzwater Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] 12.2(33)SXH "CONST_DIAG-SP-4-ERROR_COUNTER_WARNING - SXH problems?" http://www.gossamer-threads.com/lists/cisco/nsp/89241?do=post_view_threa ded "SXH2a broken with non-MDT SAFI peers" http://puck.nether.net/pipermail/cisco-nsp/2008-May/050891.html Add to those the one from Oliver Gorwits today: "CSCsm84257 (enabling NetFlow causes reload) on SXH2 on 6500 platform" Rubens On Sun, Jun 22, 2008 at 8:57 PM, Jeff Fitzwater <[EMAIL PROTECTED]> wrote: > Rubens, what issues do you mean? I am running H2a on 5 720-cxls. > > Very interested! > > > > Jeff Fitzwater > OIT Network Systems > Princeton University > > > On Jun 22, 2008, at 6:20 PM, Rubens Kuhl Jr. wrote: > >> After less than enthusiastic responses to 12.2(33)SXH2a (see the two >> messagens in the cisco-nsp archives about it), have anyone got a >> timetable to SXH3 or SXH2b ? >> >> >> Rubens >> ___ >> 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] C6k diag failure in lab, need to worry?
Agreed. We will strive to do whatever we can. Just want to point out that this is not a "crash", but a second reset on bootup. As Peter pointed out, this extends the bootup time in the 1% bootup case, it can happen. sukumar > -Original Message- > From: e ninja [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 09, 2008 11:11 PM > To: Sukumar Subburayan (sukumars) > Cc: Peter Rathlev; cisco-nsp > Subject: Re: [c-nsp] C6k diag failure in lab, need to worry? > > Sukumar, > > " You can ignore this one, as it _should_ not have any > impact, after the second reload." is not an acceptable answer. > > 1 crash in every 100 reboots = 1 million crashes out of every > 100 million reboots. In our quest for perfection, we should > strive to investigate and rectify every unexpected deviation > from the norm. > > Peter, > > Open a TAC case and submit all the captures for Cisco BU to > investigate and rectify so that all other customers can > benefit from the solution. > > /eninja > > > > On Wed, Apr 9, 2008 at 10:16 AM, Sukumar Subburayan > (sukumars) <[EMAIL PROTECTED]> wrote: > > > Peter, > > You can ignore this one, as it should not have any > impact, after the > second reload. > > We have seen this very rarely (once in 100+ reboots, on very few > systems), where an ASIC was not intialized properly, > and diagnostics was catching the condition, and resetting the > supervisor. > > sukumar > > > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf > Of Peter Rathlev > > Sent: Wednesday, April 09, 2008 8:40 AM > > To: cisco-nsp > > Subject: [c-nsp] C6k diag failure in lab, need to worry? > > > > 'ello, > > > > We just had a "funny" experience with a C6k/720 in our lab. > > We were testing SXF13 AIS, and during a reload we saw > the following: > > > > 00:01:36: %SCHED-SP-7-WATCH: Attempt to monitor uninitialized > > watched bitfield (address 0). > > -Process= "Shutdown", ipl= 0, pid= 256 > > -Traceback= 402C3A18 404ED840 4029C954 4029C940 > > 00:01:40: %DIAG-SP-3-MAJOR: Module 5: Online Diagnostics > > detected a Major Error. > > Please use 'show diagnostic result ' to see > test results. > > 00:01:40: %CONST_DIAG-SP-3-BOOTUP_TEST_FAIL: Module 5: > > TestAclDeny failed > > 00:01:41: %OIR-SP-6-INSCARD: Card inserted in slot 5, > > interfaces are now online Reload scheduled for 07:05:31 PST > > Wed Apr 9 2008 (in 13 seconds) > > > > Module 5 is the supervisor. Afterwards it reloaded and didn't > > do it again, also across several reboots. It's a Sup720-3B > > with a single WS-X6708-10GE and a WS-SVC-FWM-1. It never > > reaches starting GOLD for the DFC. > > > > I didn't have the time to do the "show diagnostics result" > > before reboot, and afterwards it say it never got a failure > > on TestAclDeny: > > > > fw1#sh diagnostic res mod 5 test 18 det > > Current bootup diagnostic level: minimal > > Test results: (. = Pass, F = Fail, U = Untested) > > __ > > _ > >18) TestAclDeny -> . > > Error code --> 3 (DIAG_SKIPPED) > > Total run count -> 1 > > Last test execution time > Apr 09 2008 07:08:26 > > First test failure time -> n/a > > Last test failure time --> n/a > > Last test pass time -> Apr 09 2008 07:08:26 > > Total failure count -> 0 > > Consecutive failure count ---> 0 > > __ > > _ > > fw1# > > > > None of the other tests show any failures either: "show > > diagnostics result module 5 detail | incl failure" gives only > > "0" and "n/a" stats. I can do "diagnostic start module 5 test > > 18" all I want and no fa
Re: [c-nsp] C6k diag failure in lab, need to worry?
Peter,
You can ignore this one, as it should not have any impact, after the
second reload.
We have seen this very rarely (once in 100+ reboots, on very few
systems), where an ASIC was not intialized properly,
and diagnostics was catching the condition, and resetting the
supervisor.
sukumar
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Peter Rathlev
> Sent: Wednesday, April 09, 2008 8:40 AM
> To: cisco-nsp
> Subject: [c-nsp] C6k diag failure in lab, need to worry?
>
> 'ello,
>
> We just had a "funny" experience with a C6k/720 in our lab.
> We were testing SXF13 AIS, and during a reload we saw the following:
>
> 00:01:36: %SCHED-SP-7-WATCH: Attempt to monitor uninitialized
> watched bitfield (address 0).
> -Process= "Shutdown", ipl= 0, pid= 256
> -Traceback= 402C3A18 404ED840 4029C954 4029C940
> 00:01:40: %DIAG-SP-3-MAJOR: Module 5: Online Diagnostics
> detected a Major Error.
> Please use 'show diagnostic result ' to see test results.
> 00:01:40: %CONST_DIAG-SP-3-BOOTUP_TEST_FAIL: Module 5:
> TestAclDeny failed
> 00:01:41: %OIR-SP-6-INSCARD: Card inserted in slot 5,
> interfaces are now online Reload scheduled for 07:05:31 PST
> Wed Apr 9 2008 (in 13 seconds)
>
> Module 5 is the supervisor. Afterwards it reloaded and didn't
> do it again, also across several reboots. It's a Sup720-3B
> with a single WS-X6708-10GE and a WS-SVC-FWM-1. It never
> reaches starting GOLD for the DFC.
>
> I didn't have the time to do the "show diagnostics result"
> before reboot, and afterwards it say it never got a failure
> on TestAclDeny:
>
> fw1#sh diagnostic res mod 5 test 18 det
> Current bootup diagnostic level: minimal
> Test results: (. = Pass, F = Fail, U = Untested)
> __
> _
>18) TestAclDeny -> .
> Error code --> 3 (DIAG_SKIPPED)
> Total run count -> 1
> Last test execution time > Apr 09 2008 07:08:26
> First test failure time -> n/a
> Last test failure time --> n/a
> Last test pass time -> Apr 09 2008 07:08:26
> Total failure count -> 0
> Consecutive failure count ---> 0
> __
> _
> fw1#
>
> None of the other tests show any failures either: "show
> diagnostics result module 5 detail | incl failure" gives only
> "0" and "n/a" stats. I can do "diagnostic start module 5 test
> 18" all I want and no failures by the way, just getting
> "%DIAG-SP-6-TEST_OK: Module 5: TestAclDeny{ID=18} has
> completed successfully" and no problems.
>
> Is this something we should try and dig into, reporting it to
> TAC? Or should we just ignore this ~5 min delay in a lab
> reboot? We can't seem to reproduce it. :'(
>
> The box had just been "upgraded" to SXF13 AES shortly before
> (from SXF6
> AIS) due to some miscommunications, and this was the first
> boot on SXF13 AIS, but I can't imagine this can have any impact.
>
> Regards,
> Peter
>
>
> ___
> 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] Would millions of TxPause mean my 6500 is too slow?
You are most likely oversubscribing the 6548-GE linecard (this card is 8:1 oversubscribed). This card is not designed for attaching your high bandwidth devices. If you turn off 'Tx' flowcontrol, you will probably start seeing indiscards, which is indicative of oversubscription. You probably should consider spreading some high-bandwidth devices across multiple linecards, or better look at other options (like a Sup720 with 67xx linecards etc..) sukumar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Deny IP Any Any Sent: Monday, March 17, 2008 7:11 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Would millions of TxPause mean my 6500 is too slow? I have a 6506 with a Sup2 running in Hybrid (7.6/12.1) mode. It has a X6548-GE-TX, with many high-bandwidth devices on it. I am not seeing any interface errors, and nothing but zero's in a 'show asicreg port pinnacle err', however, I am getting millions (per day) of flowcontrol TxPause frames on some of my ports. Does this mean I am overflowing the (limited) buffers on the 6548 card, or perhaps overworking the sup itself? Dal-6506> show port flowcontrol 4/13 Port Send FlowControl Receive FlowControl RxPauseTxPause adminoper admin oper - - - -- -- 4/13 desired on desired on 0 13826794 Dal-6506> show port flowcontrol 4/16 Port Send FlowControl Receive FlowControl RxPauseTxPause adminoper admin oper - - - -- -- 4/16 desired on desired on 0 11608252 -- deny ip any any (4393649193 matches) ___ 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] Can "power-on" mean anything other than power on?
Please ignore "Last reset from warm-reset". It is bogus, and should not be trusted. There is a software fix (in rommon) and IOS, which fixes this reset reason correctly. Since, 3 boxes rebooted all at the sam time, I agree with others that this is most likely a power related issue. sukumra -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Harris Sent: Friday, March 14, 2008 7:29 AM To: Howard Jones Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Can "power-on" mean anything other than power on? I'm no genius, but "Last reset from warm-reset" indicates to me there was no power loss. Robert Howard Jones wrote: > Hi, > > Please could I get the confirmation of your collective experience? > > We have a group of three older Catalysts at a customer site that > apparently reboot all together (within a second) and for no reason > every > 10-15 days or so. > > On each switch, for show version it shows: >System returned to ROM by power-on >[...] >Last reset from warm-reset > > Can this mean anything *other* than the obvious reason that something > onsite disconnected the switches from their power supply (bad PDU, > breaker, cable, office cleaner etc)? > > I'm hoping that it can't, because it would be a much simpler > explanation than anything software-related that affects two different > switch product ranges and two different IOS versions, but I was > curious for a second opinion before we get the witchhunt going ;-) > > Thanks in advance for any confirmation or extra info, > > Howie > ___ > 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/ -- Robert Harris Network Operations Information Resources, CaTS The University of Texas at Dallas ___ 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] WS-X6148-RJ-21 performance check
Since, the 6148 linecard does not have a DFC, and relies on central forwarding from the EARL on the sup, you could check the current forwarding rates of the Central EARL using either: sup-720#show mls statistics Statistics for Earl in Module 6 L2 Forwarding Engine Total packets Switched: 85667923 <--- L3 Forwarding Engine Total packets L3 Switched : 77712372 @ 20 pps < or 2-13-mid-720#show platform hardware capacity forwarding Forwarding engine load: Module pps peak-pps peak-time 5 20 2882 23:35:31 UTC Sun Nov 30 2008 6 22 2791 23:35:17 UTC Sun Nov 30 2008 < sukumar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Diogo Montagner Sent: Thursday, March 13, 2008 7:00 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] WS-X6148-RJ-21 performance check Hi all, how I can check if a C6513/WS-X6148-RJ-21 module reached the maximum forward capacity (in this case 15 Mpps) ? Best regards, Diogo -- ./diogo -montagner ___ 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] Sup720 MLS rate-limiting and truncated/compact mode
If the switch is either in 'bus-mode' or 'compact-mode' the below limitation with rate-limiters should not be there. So, if you only have fabric-enabled cards, you will be compact mode, so you are not affected. If you have 'force bus-mode', we will force to bus-mode, so you are not affected either. sukumar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Rathlev Sent: Monday, March 03, 2008 5:29 AM To: cisco-nsp Subject: [c-nsp] Sup720 MLS rate-limiting and truncated/compact mode Hello, Reading the documentation for 12.2SXF and MLS rate-limiters, I see the following sentence: "Layer 2 rate limiters are not supported in truncated mode." http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/na tive/configuration/guide/dos.html http://tinyurl.com/yqlylf Not that I'd be interested in this kind of rate-limiting for anything other than tests, but I was wondering what "in truncated mode" means exactly. Is it _only_ in truncated mode, or is one of "pure bus mode" or compact mode also affected? Like if I happen to have "fabric switching-mode force bus-mode" configured, or if I only have fabric-enabled cards? Thanks, Peter ___ 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] 7604/Sup720 not MLS/CEF switching
To answer your last question, since the packets that are punted to software for switching are handled by one of the EARL7 rate-limiters, which don't have counters and also you cannot see what packets, are being punted to software, the best option would be use CPU-SPAN, to SPAN the traffic destined to RP-CPU and analyse that. sukumar Oh well. I found the problem - someone leaked too many prefixes, and it's %MLSCEF-SP-7-FIB_EXCEPTION: FIB TCAM exception for IPv4 unicast, Some routes will be software switched. Dunno why it's showing *these* symptoms, affecting some interfaces more than others. But still I'm interested in finding out how to see what packets are not being MLS/CEF-switched, and why, for the next round of debugging :-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gert Doering Sent: Friday, January 25, 2008 8:07 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] 7604/Sup720 not MLS/CEF switching Hi, I could use a hint to start nailing this down. We have two 7604/Sup720s with 12.2(18)SXF7 here, doing a pretty similar traffic load (about 2-3 Gbit/s aggregate), and similar traffic pattern. IPv4, IPv6, MPLS, netflow export for IPv4. One of the boxes is running at 1-2% CPU, the other one is running at 60-80% (which started at 22:18 yesterday evening, with no significant change in traffic patterns). So, it's moving packets with a CPU not meant to be used for this. So I've checked two interfaces with very similar usage patterns (audio streaming of life radio, long-lasting flows with medium-to-large packets sizes), and there's a big difference in the percentage here: vlan1700, about 4% "not MLS/CEF switched": Protocol PathPkts In Chars In Pkts Out Chars Out IPProcess 25150 24734247 0 0 Cache misses 0 Fast 1328140746 1350996135423191 58674 Auton/SSE 30723864532 30882213532050 18184117236 1335974238797 vlan4062, about 0.1% "not MLS/CEF switched": Protocol PathPkts In Chars In Pkts Out Chars Out IPProcess 368914 54599634 31636639 3543640264 Cache misses 0 Fast 1670054191 1924596882515168 9913 Auton/SSE 1029709651247 1137649776167566 229040036204 16614962888496 there's difference on L2 for these interfaces (4062 is coming in via a dedicated port, 1700 is coming in via a trunk port), but I don't think this should make any difference. Most of the egress traffic for this is going via a L3 port-channel, or via a single L3 port. For both VLANs. Traffic level is about 400 Mbit on vlan 1700, 500 Mbit on vlan 4062, most of it "incoming". No big difference here either. Similar PPS levels, about 50.000 pps incoming. This is how vlan1700 looks like: interface Vlan1700 description Streaming2/Trust (an1) ip address 194.97.x.y 255.255.255.240 ip verify unicast source reachable-via rx allow-default ip flow ingress no mop enabled end Something is funny here... - so - how do I start figuring out why 1/20 of those packets are not being MLS/CEF switched? Oh well. I found the problem - someone leaked too many prefixes, and it's %MLSCEF-SP-7-FIB_EXCEPTION: FIB TCAM exception for IPv4 unicast, Some routes will be software switched. Dunno why it's showing *these* symptoms, affecting some interfaces more than others. But still I'm interested in finding out how to see what packets are not being MLS/CEF-switched, and why, for the next round of debugging :-) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025 [EMAIL PROTECTED] ___ 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] C6500 C6KERRDETECT-SP-2-FIFOCRITLEVEL
Also, I don't see any specific bug fixes related to this error msg. so, I don't think upgrading the code will do anything. As part of upgrade, you would reset the switch, which might clear some temporary condition which was causing this error message, however, I don't see any fixes which went in the latest release to fix any false positives. sukumar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sukumar Subburayan (sukumars) Sent: Saturday, October 13, 2007 10:34 AM To: [EMAIL PROTECTED]; Kevin Graham; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] C6500 C6KERRDETECT-SP-2-FIFOCRITLEVEL comments inline.. sukumar -Original Message- From: John Imison [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Saturday, October 13, 2007 7:43 AM To: Sukumar Subburayan (sukumars); 'John I'; 'Kevin Graham'; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] C6500 C6KERRDETECT-SP-2-FIFOCRITLEVEL Hi sukumar, Thanks for your reply. > There is actually no need to swap chassis. > > This error message indicates that the SP-CPU inband port (the internal > 1 Gig connection) FIFO pointers were not moving for certain amount of > time possibly indicating something wrong between the CPU and it's > inband connection. All this is internal to the Supervisor. > I've only started receiving this message after upgrading the supervisor memory on the module, otherwise, it has been fine for months. Could I have not reseated the MSFC properly onto the SUP? Could it be the memory? Could I have bumped something else? ##sukumars possible, as you are saying that this started happening only after upgrading memory. Are there any commands I can execute to see these fifo pointers you mention? ##sukumars there are some asic register commands on the SP-side for the ASIC (pinnacle), you can look at. But since these are debug type commands, I would not recommend using them without TAC help. > If the errors are persistant, the active sup might eventually reset or > switchover (in case there is standby). As part of the upgrade process, > the transient condition probably got cleared. > The errors have been going for a while now, however, the unit continues to switch/route packets without problem. What would you recommend I do? ##sukumars For Fifo stuck, we do try auto-recovering by soft resetting the internal ASIC path. So, if you are not really seeing any problems, I would suggest you don't have to do anything. If the errors are happening very very frequently, then I would suggest the below steps. (I will be trying what's been recommended already such as reseat module & upgrade IOS) Thanks, John ___ 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] C6500 C6KERRDETECT-SP-2-FIFOCRITLEVEL
comments inline.. sukumar -Original Message- From: John Imison [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Saturday, October 13, 2007 7:43 AM To: Sukumar Subburayan (sukumars); 'John I'; 'Kevin Graham'; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] C6500 C6KERRDETECT-SP-2-FIFOCRITLEVEL Hi sukumar, Thanks for your reply. > There is actually no need to swap chassis. > > This error message indicates that the SP-CPU inband port (the internal > 1 Gig connection) FIFO pointers were not moving for certain amount of > time possibly indicating something wrong between the CPU and it's > inband connection. All this is internal to the Supervisor. > I've only started receiving this message after upgrading the supervisor memory on the module, otherwise, it has been fine for months. Could I have not reseated the MSFC properly onto the SUP? Could it be the memory? Could I have bumped something else? ##sukumars possible, as you are saying that this started happening only after upgrading memory. Are there any commands I can execute to see these fifo pointers you mention? ##sukumars there are some asic register commands on the SP-side for the ASIC (pinnacle), you can look at. But since these are debug type commands, I would not recommend using them without TAC help. > If the errors are persistant, the active sup might eventually reset or > switchover (in case there is standby). As part of the upgrade process, > the transient condition probably got cleared. > The errors have been going for a while now, however, the unit continues to switch/route packets without problem. What would you recommend I do? ##sukumars For Fifo stuck, we do try auto-recovering by soft resetting the internal ASIC path. So, if you are not really seeing any problems, I would suggest you don't have to do anything. If the errors are happening very very frequently, then I would suggest the below steps. (I will be trying what's been recommended already such as reseat module & upgrade IOS) Thanks, John ___ 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] C6500 C6KERRDETECT-SP-2-FIFOCRITLEVEL
There is actually no need to swap chassis. This error message indicates that the SP-CPU inband port (the internal 1 Gig connection) FIFO pointers were not moving for certain amount of time possibly indicating something wrong between the CPU and it's inband connection. All this is internal to the Supervisor. If the errors are persistant, the active sup might eventually reset or switchover (in case there is standby). As part of the upgrade process, the transient condition probably got cleared. sukumar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John I Sent: Wednesday, October 10, 2007 1:33 PM To: 'Kevin Graham'; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] C6500 C6KERRDETECT-SP-2-FIFOCRITLEVEL Hi Kevin, > Try bumping up to a later 12.1E. > > This had cropped up twice on the same switch for me, the first time > TAC recommendation was to reseat the module, the second time it was to > swap the chassis. Prior to having time to schedule a fully chassis > swap, bumped up to 12.1(27b)E1 from 12.1(26)E1 and errors haven't > cropped up since. > Additionally, despite the scary sounding message, I don't think we > ever saw any evidence of something actually broken as a result... I too had the suggestion of reseating the module on the cisco forum. I agree with you in that the machine still seems to be processing packets fine and no evidence of problems. I will give the newer IOS a try and see if that helps as it did for you. Thanks for your suggestion. Regards, John ___ 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] GOLD error under SXF10
there is no specific issue related to this in SXF10, and there is nothing fixed in SXF11 related to this. If you can provide access to the setup via unicast, we can take a look. sukumar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of mack Sent: Monday, October 01, 2007 9:42 PM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] GOLD error under SXF10 The problem does not exist in SXF5, SXF6, SXF11 or SXH. It only occurs on SXF10 of the releases tested. Hopefully this will save someone else some headaches. Mack > -Original Message- > From: mack > Sent: Monday, October 01, 2007 5:19 PM > To: 'cisco-nsp@puck.nether.net' > Cc: 'Tinis, Phillip A' > Subject: GOLD error under SXF10 > > During testing we have discovered 6704-10GE line cards fail > diagnostics under SXF10. > They pass them fine under SXF6 and earlier. > Has anyone else encountered this problem? > Is it fixed in SXF11 and SXH? > > LR Mack McBride > Network Administrator > Alpha Red, Inc. ___ 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] Invisible CDP neighbours
Phil, Other than CDP, are you able to ping new-1/2, from core1/core2 to the directly connected Ten1/1 on new/1/2? I would like to know if all RP-terminated packets are affected coming in on Ten1/1 of new 1/2 (UDLD packets are terminated on the SP-side). There are a bunch of troubleshooting we can do on core1 and new-1 including packet-buffer capture and ELAM, LTL troubleshooting, which all would have been done by TAC, if you only had TAC maintainance, and your problem would have been resolved by now ;-) Anyway, if have access to the box, I can take a quick look at it if you can unicast me the details. Sukumar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phil Mayers Sent: Wednesday, September 19, 2007 3:15 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Invisible CDP neighbours Bah. 2 out of 9 two boxes, we decide to get vendor rather than TAC maintenance, and it all goes wrong... I wonder if it's encoded in the backplane PROM ;o) Whilst I'm waiting for my reseller to embarass themselves; we have the following setup: core1 [Te1/1] --- [Te1/1] core2 [Te1/3][Te2/3] | | | | [Te1/1][Te1/1] new-1 [Te1/2] --- [Te1/2] new-2 core1/core2 are old/existing routers; 6500 sup720-3B 12.2SXF10 and SXF6 respectively, 6704 w/ DFC-3B. They can see each other *and* new-1/2 on the correct ports with CDP. new-1/2 are new, 6500 sup720-3B 12.2SXF10, 6704 w/ CFC (i.e. no DFC) and ACE20 (currently unused). They can see no CDP neighbours on their 10gig ports. The 10gig ports are configured more or less identically on all 4 routers, and a "debug cdp blah" on core1/core2 shows they think they are emitting the CDP packets, but similar debug on new-1/2 never shows a receive. Weirdly, all 4 are connected to an out-of-band 10/100 network via the sup gi5/2 port, and can see each other just fine. I'm having a hard time believing 6704 needs a DFC to do CDP correctly; the only other differences are minor hardware revisions (the new routers are sup 5.4 as opposed to 4.4). Double oddness; "sh udld" has valid data in the "CDP device name" space, which is just annoying! Any thoughts? ___ 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/
