Update for anyone interested: it's been classified as a new bug,
https://tools.cisco.com/bugsearch/bug/CSCuu15276. Cisco was able to
reproduce it in lab and are currently investigating the root cause.
Regards,
Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Ensc
On 04/21/2015 12:21 AM, Andrew Miehs wrote:
I actually meant line cards. So if I understand correctly both boxes
have at least 2x6904. How many of your cards have the low revision
number? 1 in the box or 2 ? Does moving these cards change which box
is software switching?
Router A:
mod 1 WS-X682
I actually meant line cards. So if I understand correctly both boxes have at
least 2x6904. How many of your cards have the low revision number? 1 in the box
or 2
? Does moving these cards change which box is software switching?
Sent from a mobile device
> On 21 Apr 2015, at 01:40, Jeroen van In
> What still bothers me is the exception generated when reprogramming the
> interfaces, ie when I change the config for a subinterface, this
> specific router has an exception in the debug output that isn't thrown
> when I make the exact same change on the other router:
>
> fm_core_notify_feat_exce
On 04/20/2015 05:39 PM, Matthew Huff wrote:
Traffic destined to the switch rather than through the switch is
generally software switched. Too much software switched traffic
causing CPU issues could cause other traffic not to be installed in
the ASIC causing a cascade failure.
I'm not sure that
On 04/20/2015 05:28 PM, Andrew Miehs wrote:
Have you tried swapping the two interfaces between the chassis?
Nope, because it happens on several interfaces in "router A", spread
across two line cards. Interfaces are in routed mode with several
subinterfaces configured; there's a clear pattern
c-nsp] One Cat6k/Sup2T is software switching, its identical
partner is not
Hi,
> Haven't followed this thread too carefully, so I apologize if I
> duplicated anyone's suggestion:
>
> Have you checked for:
>
> 1) Are these systems setup for NHRP (hsrp, glbp, vrrp)? If so,
Have you tried swapping the two interfaces between the chassis?
Sent from a mobile device
> On 21 Apr 2015, at 01:16, Jeroen van Ingen wrote:
>
> Hi,
>
>> Haven't followed this thread too carefully, so I apologize if I
>> duplicated anyone's suggestion:
>>
>> Have you checked for:
>>
>> 1) A
Hi,
Haven't followed this thread too carefully, so I apologize if I
duplicated anyone's suggestion:
Have you checked for:
1) Are these systems setup for NHRP (hsrp, glbp, vrrp)? If so, is
the box that is having the issue the active node?
Running HSRP, but doesn't make a difference which of t
Hi,
Are all of the acls the same on both boxes? It almost sounds like
one box had a tcam explosion due to differing ACLs.
Yes, ACLs are 100% identical, I've paid extra attention to that
when I vimdiff'd the configs.
Are you using the LI (Lawful Intercept) features on those boxes? LI
makes th
4-694-5669
-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Sander
Steffann
Sent: Monday, April 20, 2015 9:44 AM
To: Jeroen van Ingen
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] One Cat6k/Sup2T is software switching, its identical
partner is not
Hi,
> On 04/19/2015 06:08 AM, Mack McBride wrote:
>> Are all of the acls the same on both boxes?
>> It almost sounds like one box had a tcam explosion due to differing ACLs.
>
> Yes, ACLs are 100% identical, I've paid extra attention to that when I
> vimdiff'd the configs.
Are you using the LI
Hi Mack,
On 04/19/2015 06:08 AM, Mack McBride wrote:
Are all of the acls the same on both boxes?
It almost sounds like one box had a tcam explosion due to differing ACLs.
Yes, ACLs are 100% identical, I've paid extra attention to that when I
vimdiff'd the configs.
I'll let the list know if/
Hi,
those revisions wasn't answered though. Did you ever hear details about
differences in hw revisions?
Try http://tools.cisco.com/emco/pcnclei/prsc/pcnSearchEntry.do
Kudos to Cisco for being this open/professional about product changes.
Thanks! Didn't find anything that might be relevant (
: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jeroen
van Ingen
Sent: Saturday, April 18, 2015 9:34 AM
To: Łukasz Bromirski
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] One Cat6k/Sup2T is software switching, its identical
partner is not
Hi Łukasz,
>> We have two C
On (2015-04-18 17:33 +0200), Jeroen van Ingen wrote:
Hey,
> I mentioned this to TAC but the response was that that couldn't be related.
> My question about what sort of changes were made or could have been made in
> those revisions wasn't answered though. Did you ever hear details about
> differe
Hi Łukasz,
We have two Cat6k's with Sup2T in our network, both running IOS 15.1(1)SY3.
Are they really identical, down to Sw/Hw revisions and ROMMON
versions?
You got me there. PFC4 versions differ: the one doing everything in hw
has hw rev 2.0, the one partially software switching currentl
Hi Jeroen,
> On 17 Apr 2015, at 13:16, Jeroen van Ingen wrote:
>
> We have two Cat6k's with Sup2T in our network, both running IOS 15.1(1)SY3.
Are they really identical, down to Sw/Hw revisions and ROMMON
versions?
It seems that something on the device side either interprets
the configuration
On 04/17/2015 03:03 PM, Roland Dobbins wrote:
On 17 Apr 2015, at 18:16, Jeroen van Ingen wrote:
Anyone with ideas how to dig deeper?
sh fm sum
That's pretty similar to other "show fm" commands; "sh fm fea" says
these interfaces are partially reduced on ingress and "sh fm sum" says
"non-r
On 17 Apr 2015, at 18:16, Jeroen van Ingen wrote:
> Anyone with ideas how to dig deeper?
sh fm sum
Reseat the linecard in question?
---
Roland Dobbins
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck
Calling on your collective knowledge here, because our TAC case is
progressing quite slowly. I hope someone is around who has in-depth
knowledge of "feature manager" on Cat6k/Sup2T.
We have two Cat6k's with Sup2T in our network, both running IOS
15.1(1)SY3. They function as distribution switch
21 matches
Mail list logo
