Re: [c-nsp] CSCti84025
On 05/16/2011 05:00 PM, Tim Durack wrote: Anyone run into CSCti84025 on a C6K, VS-S720-3C, 12.2(33)SXI3? VRFs hardware re-mapping causing MLS/CEF inconsistencies We've had something very like this on SXI3 - routing changes trigger MPLS label mis-programming resulting in CPU punt and high packet loss on affected LSPs. TAC logged in and did some poking at the TCAM and fixed it, then I reloaded the box a week or so later. We're on SXI5 and these seem to have gone away. On a Catalyst 6500 series switches, connectivity in VRFs may be affected after a large reconvergence. Another symptom of the issue is the presence of invalid mls mpls entries : Router#show mls cef mpls | i INVALID 583 731 INVALID punt 1377 675 INVALID punt 1379 9742 INVALID punt Conditions: This is observed on a PE running a fair amount of ebgp sessions between its own VRFs. That wasn't the trigger for us (although TAC was unable to determine exactly what was) hence very like rather than exactly this. Interested in knowing what it feels like. We are seeing these invalid entries, and have been experiencing random/cyclic packet loss. I'm guessing invalid labels punting to control plane with CoPP configured might result in seemingly random packet loss. That's exactly what we experienced. It seems to go away for a while after reload i.e. the TCAM mis-programming doesn't seem to happen until the box has been up a while. But that was very much an impression/gut feeling, no hard evidence. ___ 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] CSCti84025
On Tue, May 17, 2011 at 4:01 AM, Phil Mayers p.may...@imperial.ac.uk wrote: On 05/16/2011 05:00 PM, Tim Durack wrote: Anyone run into CSCti84025 on a C6K, VS-S720-3C, 12.2(33)SXI3? VRFs hardware re-mapping causing MLS/CEF inconsistencies We've had something very like this on SXI3 - routing changes trigger MPLS label mis-programming resulting in CPU punt and high packet loss on affected LSPs. TAC logged in and did some poking at the TCAM and fixed it, then I reloaded the box a week or so later. We're on SXI5 and these seem to have gone away. Good to know. We have case open with TAC, and are testing SXI6 as the fix. Interested in knowing what it feels like. We are seeing these invalid entries, and have been experiencing random/cyclic packet loss. I'm guessing invalid labels punting to control plane with CoPP configured might result in seemingly random packet loss. That's exactly what we experienced. It seems to go away for a while after reload i.e. the TCAM mis-programming doesn't seem to happen until the box has been up a while. But that was very much an impression/gut feeling, no hard evidence. Thanks for the comments. -- Tim: ___ 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] 6500 VSS question
Anyone? Otherwise gonna ask TAC, just want to verify my thoughts. Thanks, Chuck -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Church, Charles Sent: Monday, May 16, 2011 6:07 PM To: nsp-cisco Subject: [c-nsp] 6500 VSS question All, Noticed an unexpected result today when testing VSS failover. Our setup has dual sups in each chassis, with a supervisor port of each chassis connecting to the matching supervisor port on the other chassis, i.e. 1/5/4 connects to 2/5/4, and 1/6/4 connects to 2/6/4. Today when pulling out the active sup, the hot-standby took over immediately as it should, but we noticed all the linecards in the chassis with the pulled sup resetting. I was under the assumption that a sup transitioning from RPR-warm to standby hot would remain forwarding at L2, thus keeping the VSL up. Now I'm questioning that. It would explain the result, as the linecards couldn't get to an active supervisor. I'm thinking I should have a third VSL link (of that port channel) on a non-sup linecard. When we did the eFSU, we noticed real long outages of the linecards of the chassis getting the final reload as well. Possibly the same issue, no connectivity to the active sup? Thanks, Chuck ___ 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] 6500 VSS question
On 17/05/11 16:31, Church, Charles wrote: Anyone? Otherwise gonna ask TAC, just want to verify my thoughts. I know nothing much about VSS, but I see a couple of confusing aspects in your email; you refer to instant failover (which is SSO), RPR+ and eFSU. Can you elaborate on the exact sequence of events, and what the standby state of the other nodes and SUPs was at each point? ___ 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] 6500 VSS question
Is your redundancy mode set to RPR? I think what you are doing only works if the mode is set to SSO... -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Church, Charles Sent: Tuesday, May 17, 2011 10:31 AM To: nsp-cisco Subject: Re: [c-nsp] 6500 VSS question Anyone? Otherwise gonna ask TAC, just want to verify my thoughts. Thanks, Chuck -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Church, Charles Sent: Monday, May 16, 2011 6:07 PM To: nsp-cisco Subject: [c-nsp] 6500 VSS question All, Noticed an unexpected result today when testing VSS failover. Our setup has dual sups in each chassis, with a supervisor port of each chassis connecting to the matching supervisor port on the other chassis, i.e. 1/5/4 connects to 2/5/4, and 1/6/4 connects to 2/6/4. Today when pulling out the active sup, the hot-standby took over immediately as it should, but we noticed all the linecards in the chassis with the pulled sup resetting. I was under the assumption that a sup transitioning from RPR-warm to standby hot would remain forwarding at L2, thus keeping the VSL up. Now I'm questioning that. It would explain the result, as the linecards couldn't get to an active supervisor. I'm thinking I should have a third VSL link (of that port channel) on a non-sup linecard. When we did the eFSU, we noticed real long outages of the linecards of the chassis getting the final reload as well. Possibly the same issue, no connectivity to the active sup? Thanks, Chuck ___ 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] 6500 VSS question
I haven't looked TOO in-depth on this yet, but with VSS and 4 supervisors, do all 4 come up in SSO mode, or do the first 2 come up in SSO, and the other two come up in RPR+ mode? 4 Supervisor VSS is still VERY new, and I wouldn't be surprised if it's a hybrid of the 2 modes at this point still. Ken Matlock Network Analyst Exempla Healthcare (303) 467-4671 matlo...@exempla.org -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Murphy, William Sent: Tuesday, May 17, 2011 1:09 PM To: Church, Charles; nsp-cisco Subject: Re: [c-nsp] 6500 VSS question Is your redundancy mode set to RPR? I think what you are doing only works if the mode is set to SSO... -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Church, Charles Sent: Tuesday, May 17, 2011 10:31 AM To: nsp-cisco Subject: Re: [c-nsp] 6500 VSS question Anyone? Otherwise gonna ask TAC, just want to verify my thoughts. Thanks, Chuck -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Church, Charles Sent: Monday, May 16, 2011 6:07 PM To: nsp-cisco Subject: [c-nsp] 6500 VSS question All, Noticed an unexpected result today when testing VSS failover. Our setup has dual sups in each chassis, with a supervisor port of each chassis connecting to the matching supervisor port on the other chassis, i.e. 1/5/4 connects to 2/5/4, and 1/6/4 connects to 2/6/4. Today when pulling out the active sup, the hot-standby took over immediately as it should, but we noticed all the linecards in the chassis with the pulled sup resetting. I was under the assumption that a sup transitioning from RPR-warm to standby hot would remain forwarding at L2, thus keeping the VSL up. Now I'm questioning that. It would explain the result, as the linecards couldn't get to an active supervisor. I'm thinking I should have a third VSL link (of that port channel) on a non-sup linecard. When we did the eFSU, we noticed real long outages of the linecards of the chassis getting the final reload as well. Possibly the same issue, no connectivity to the active sup? Thanks, Chuck ___ 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/ *** Exempla Confidentiality Notice *** The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any other dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately by replying to the message and deleting it from your computer. Thank you. *** Exempla Confidentiality Notice *** ___ 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] 'hitless' XR upgrades on ASR9k?
Is there a way to do quasi-hitless XR upgrades on an ASR9k? I have two RSPs, so I'd be under the impression that I could load the new code onto the standby, reload it, then failover from the active to the standby but I can't find any specific instructions in any of the upgrade docs I'm reading, so I can't be sure. Anyone happen to have gone down this road before? ___ 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] 6500 VSS question
Phil, The VSS is the 'bonding' of 2 6500 chassis into one, with one CLI controlling both chassis. Kind of like a 3750 stack. Up until I think SXI3, you were limited to one sup in each chassis. One sup would be elected the active, and the other would be the hot standby, like normal SSO, but split between chassis. With SXI3 or 4, you can add a second sup into each chassis. These sups backup the other sup in that chassis. The additional sups take the role of RPR warm. Each chassis can have at most 1 sup as either active or hot-standby, and the other sup if up will be RPR warm. If your active sup is lost, the hot-standby (in other chassis) transitions to active, and the backup sup in the chassis which just lost the active sup will transition from RPR-warm to hot-standby. The VSS link exists between the two chassis to act almost like a backplane, carrying some traffic, but also state info, and other things you might find on the backplane. Chuck Church -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers Sent: Tuesday, May 17, 2011 12:39 PM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] 6500 VSS question On 17/05/11 16:31, Church, Charles wrote: Anyone? Otherwise gonna ask TAC, just want to verify my thoughts. I know nothing much about VSS, but I see a couple of confusing aspects in your email; you refer to instant failover (which is SSO), RPR+ and eFSU. Can you elaborate on the exact sequence of events, and what the standby state of the other nodes and SUPs was at each point? ___ 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/ smime.p7s Description: S/MIME cryptographic signature ___ 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] 6500 VSS question
First one up is active, the first one up in the opposite chassis becomes the standby. The other sups fall into RPR mode. Unfortunately the docs for eFSU and ISSU don't cover the 4 sup method well, the placement of the VSLs seems to be a bit of a mystery. Doesn't sound like you can have too many. Will know soon, tried to bring up another one today, but an odd bug involving an etherchannel looping frames after change to 'performance mode' killed us. Will try again soon. Chuck -Original Message- From: Matlock, Kenneth L [mailto:matlo...@exempla.org] Sent: Tuesday, May 17, 2011 4:44 PM To: Murphy, William; Church, Charles; nsp-cisco Subject: RE: [c-nsp] 6500 VSS question I haven't looked TOO in-depth on this yet, but with VSS and 4 supervisors, do all 4 come up in SSO mode, or do the first 2 come up in SSO, and the other two come up in RPR+ mode? 4 Supervisor VSS is still VERY new, and I wouldn't be surprised if it's a hybrid of the 2 modes at this point still. Ken Matlock Network Analyst Exempla Healthcare (303) 467-4671 matlo...@exempla.org -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Murphy, William Sent: Tuesday, May 17, 2011 1:09 PM To: Church, Charles; nsp-cisco Subject: Re: [c-nsp] 6500 VSS question Is your redundancy mode set to RPR? I think what you are doing only works if the mode is set to SSO... -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Church, Charles Sent: Tuesday, May 17, 2011 10:31 AM To: nsp-cisco Subject: Re: [c-nsp] 6500 VSS question Anyone? Otherwise gonna ask TAC, just want to verify my thoughts. Thanks, Chuck -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Church, Charles Sent: Monday, May 16, 2011 6:07 PM To: nsp-cisco Subject: [c-nsp] 6500 VSS question All, Noticed an unexpected result today when testing VSS failover. Our setup has dual sups in each chassis, with a supervisor port of each chassis connecting to the matching supervisor port on the other chassis, i.e. 1/5/4 connects to 2/5/4, and 1/6/4 connects to 2/6/4. Today when pulling out the active sup, the hot-standby took over immediately as it should, but we noticed all the linecards in the chassis with the pulled sup resetting. I was under the assumption that a sup transitioning from RPR-warm to standby hot would remain forwarding at L2, thus keeping the VSL up. Now I'm questioning that. It would explain the result, as the linecards couldn't get to an active supervisor. I'm thinking I should have a third VSL link (of that port channel) on a non-sup linecard. When we did the eFSU, we noticed real long outages of the linecards of the chassis getting the final reload as well. Possibly the same issue, no connectivity to the active sup? Thanks, Chuck ___ 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/ *** Exempla Confidentiality Notice *** The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any other dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately by replying to the message and deleting it from your computer. Thank you. *** Exempla Confidentiality Notice *** smime.p7s Description: S/MIME cryptographic signature ___ 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] off-topic NMS Suggestion
Hi List, Please could you suggest me a NMS for WAN/LAN? the WAN is a MPLS/VPN (300 remote offices) and the Switching is a campus LAN (aprox 1000 Network Devices) and three remote buildings (aprox Network 200 devices in each building). Before I tried Cisco Works but I faced some issues; HP Openview was difficult also. We need a easy web interface for monitoring and reporting (unfortunately no open source solutions are accepted). Thank you for your suggestions. Rgds. -- Omar E.P.T - Certified Networking Professionals make better Connections! ___ 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] off-topic NMS Suggestion
The best NMS solutions are open source. (My opinion... :-) You can get paid support if that is the issue, from installation to on-going configuration support. You should investigate what support teams are using to monitor large networks. Papa John's for example monitors 3400 locations requiring only one person on duty Open source NMS... You will save a ton of money as well... |--- | Dan Lacey daniel_p_la...@yahoo.com | PGP Key: 0xFE94668F @ http://pgp.mit.edu or http://keyserver.pgp.com | PGP Key fingerprint: 8A97 2996 266D A21C 0277 54EF 40D5 2B80 FE94 668F |--- On 5/17/11 7:38 PM, omar parihuana wrote: Hi List, Please could you suggest me a NMS for WAN/LAN? the WAN is a MPLS/VPN (300 remote offices) and the Switching is a campus LAN (aprox 1000 Network Devices) and three remote buildings (aprox Network 200 devices in each building). Before I tried Cisco Works but I faced some issues; HP Openview was difficult also. We need a easy web interface for monitoring and reporting (unfortunately no open source solutions are accepted). Thank you for your suggestions. Rgds. ___ 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] 'hitless' XR upgrades on ASR9k?
On Tue, 17 May 2011, Jason Lixfeld wrote: Is there a way to do quasi-hitless XR upgrades on an ASR9k? I have two RSPs, so I'd be under the impression that I could load the new code onto the standby, reload it, then failover from the active to the standby but I can't find any specific instructions in any of the upgrade docs I'm reading, so I can't be sure. Afaik, ISSU between XR versions isn't available yet. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Open Source netflow recommendations
Does anyone have any recommendations for an open source netflow solution? If there is nothing out there, what is recommended in the non-open source world? Are there any to absolutely stay away from? Thanks, Lee ___ 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] Open Source netflow recommendations
http://nfsen.sourceforge.net/ Tim on 5/17/11 8:21 PM Lee Starnes said the following: Does anyone have any recommendations for an open source netflow solution? If there is nothing out there, what is recommended in the non-open source world? Are there any to absolutely stay away from? Thanks, Lee ___ 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/ -- GPG Fingerprint: 4821 CFDA 06E7 49F3 BF05 3F02 11E3 390F 8338 5B04 http://www.lns.com/house/pozar/pozar_4096_rsa_public.asc ___ 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] 3845 aim problem
hello after install aim-ssl3 module in Router Cisco 3845 appear this message and cpu process after enabling the IPSEC over than 90% and Router Hang. pls help me to resolve this message: AIM Type 0x4f5 is not supported by this platform my ios is :C3845-adventerprisek9-mz.124-25a thank you ___ 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] 3845 aim problem
On 5/17/11 10:09 PM, hamid tavoli wrote: hello after install aim-ssl3 module in Router Cisco 3845 appear this message and cpu process after enabling the IPSEC over than 90% and Router Hang. pls help me to resolve this message: AIM Type 0x4f5 is not supported by this platform my ios is :C3845-adventerprisek9-mz.124-25a The Cisco IPsec and SSL VPN AIM requires Cisco IOS Software Version 12.4(9)T or higher. http://www.cisco.com/en/US/prod/collateral/routers/ps5853/data_sheet_vpn_aim_for_18128003800routers_ps5853_Products_Data_Sheet.html ~Seth ___ 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/
