Re: [c-nsp] Cisco trunk port startup delay

[Tóth András]

I would not encourage disabling STP at all, "portfast trunk" already
increases the chances of creating a loop, on the other hand it does allow
the port to transition to STP forwarding state immediately, so it should
have the same effect.

Given that the delay is due to the actual link down and likely re-ARP-ing,
the only option for further reduce the delay is to dual-home the servers,
preferably with a port-channel (etherchannel) such as 802.3ad LACP. That
will provide redundancy and sub-second failover if one member link goes
down or flaps.

Andras



On Fri, Jul 12, 2013 at 7:26 PM, Tom Storey  wrote:

> If they are connecting to servers, do you really need spanning tree?
>
> I assume that spanning tree is blocking for x period of time, where x is
> long or short depending on whether portfast is enabled.
>
> If you remove spanning tree then there is no blocking, and it should come
> up and be able to pass traffic as quickly as MAC tables can update?
>
>
>
> On 11 July 2013 01:32, Shanawaz Batcha  wrote:
>
> > Hi Guys,
> >
> > Question for you is how soon can we get a cisco trunk port (connecting to
> > some enterprise servers) to initialize and pass traffic.
> >
> > From
> >
> > interface GigabitEthernet4/40
> >
> > switchport
> >
> > switchport trunk encapsulation dot1q
> >
> > switchport trunk native vlan 104
> >
> > switchport mode trunk
> >
> > spanning-tree bpduguard enable
> >
> > end
> >
> >
> > With the above configuration, we were losing about 50 pings for an
> if-down
> > event
> >
> > Enabling "portfast trunk" (no redundant connections), we lost somewhere
> > between 10 and 15 pings. Which is way better.
> >
> > Running "switchport nonegotiate" to disable DTP gives me another ~2
> seconds
> >
> > Disabling inline power and "disabling lldp" gives me another ~1 or 2
> > seconds
> >
> > We are still losing about 6 pings. Anything else people do/tune to get
> > quicker convergence if I may call it?
> >
> > Regards,
> > Shan
> > ___
> > 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] nexus logging L3 ACL and mac source ?

[Tóth András]

Hi,

Point taken, indeed. However unfortunately I'm not aware of the ability to
see MAC address with ACL logs.

Honestly, it took a few years to get those two bugs fixed, mostly because
Cisco considered them enhancement requests (that you can't see the ACL name
and whether it's permit or deny).

Andras



On Fri, Jun 28, 2013 at 12:19 PM, Gert Doering  wrote:

> Hi,
>
> On Fri, Jun 28, 2013 at 10:58:50AM +0100, Tóth András wrote:
> > Manually looking at the MAC/ARP table is not flawed much more than
> relying
> > on ACL logging to print out the MAC because if it comes through a router,
> > both will display the router MAC anyway.
>
> That's the misunderstanding, that the MAC/ARP table will help you find
> the router MAC - it won't, unless you already know the router it's coming
> from.
>
> More verbose example:
>
>
>  sender PC   -- Router A  eth Router B
>  IP 1.1.1.1 10.0.0.1  10.0.0.2
>
> (with a "large enough" ethernet, having more than just A and B connected
> to it)
>
> In router B, I have an ACL that says, for example
>
>   deny tcp any any eq 23 log-input
>
> so I can see if someone fingers my routers.  The ACL logs
>
>   "source = 1.1.1.1, destination = 10.0.0.2, source interface = facing A"
>
> so how, exactly, do I find that the packet came in from Router A?
>
>
> For bonus points, assume that B has multiple possible paths to 1.1.1.1,
> so assuming "it will come from the router where I would send the response
> packet to" does not hold.
>
> gert
> --
> USENET is *not* the non-clickable part of WWW!
>//
> www.muc.de/~gert/
> Gert Doering - Munich, Germany
> g...@greenie.muc.de
> fax: +49-89-35655025
> g...@net.informatik.tu-muenchen.de
>
___
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 logging L3 ACL and mac source ?

[Tóth András]

Manually looking at the MAC/ARP table is not flawed much more than relying
on ACL logging to print out the MAC because if it comes through a router,
both will display the router MAC anyway.

Andras



On Fri, Jun 28, 2013 at 9:51 AM, Gert Doering  wrote:

> Hi,
>
> On Thu, Jun 27, 2013 at 10:54:32PM +0100, Tóth András wrote:
> > The MAC address of the packet will not be visible in the ACL logs. You
> can
> > see the port where the logged packet was received, then you can check the
> > learnt MACs on the port to narrow it down.
>
> Is this a hardware limitation on the N7K, or "just not implemented yet"?
>
> The assumption that "if you know the IP address and the ingress interface,
> you can see from the ARP table where it came from" is deeply flawed for
> a number of reasons - the most easily understood is "the packet might come
> from behind another router", so you need the MAC address of the
> previous-hop
> router to backtrack stuff.
>
> gert
> --
> USENET is *not* the non-clickable part of WWW!
>//
> www.muc.de/~gert/
> Gert Doering - Munich, Germany
> g...@greenie.muc.de
> fax: +49-89-35655025
> g...@net.informatik.tu-muenchen.de
>
___
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 logging L3 ACL and mac source ?

[Tóth András]

Hi Jeffrey,

The MAC address of the packet will not be visible in the ACL logs. You can
see the port where the logged packet was received, then you can check the
learnt MACs on the port to narrow it down.

Check the following link for further details about ACL logging on Nexus:
https://supportforums.cisco.com/community/netpro/network-infrastructure/switching/blog/2010/11/18/nexus-7000-acl-logging-oal

Best regards,
Andras



On Mon, Jun 24, 2013 at 3:29 PM, Jeffrey G. Fitzwater
wrote:

> In IOS when we had an L3 ACL with "deny log-input"   the log entry would
> show the VLAN  and MAC SRC for ACE hit….
>
> %SEC-6-IPACCESSLOGP: list router-in denied udp n.n.n.n(137) (Vlan176
> 00de.adee.675a) -> n.n.n.n(137), 67 packets
>
>
> But in NX-OS this does not appear possible with 6.1.2.
>
>
>
> FIXES in NX-OS 6.2.1
>
>
>
> I see from bug doc that in NX-OS 6.2.1 logging will now show vlan name,
> and if it was from a DENY or PERMIT action;  But no mention if the SRC MAC
> is part of these changes.
> https://tools.cisco.com/bugsearch/bug/CSCth67151
> https://tools.cisco.com/bugsearch/bug/CSCte69784
>
>
> Does anybody know if there will be a way to see  the SRC MAC when a DENY
> LOG or PERMIT log ACE is hit in NX-OS 6.2.1?
>
>
>
> Thanks for any help.
>
>
>
>
> Jeff FItzwater
> OIT Network Systems
> Princeton University
> ___
> 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] How Cisco TAC troubleshoots router/switch crash using the stack frames?

[Tóth András]

Hi,

Not sure how knowing the method helps you at all, but the decoding is done
using symbol tables which map the traceback values to function names which
can be then searched for in the source code or similar bugs/cases in the
database.

Best regards,
Andras



On Mon, Jun 3, 2013 at 11:53 AM, Martin T  wrote:

> Hello,
>
> 1) Am I correct that IOS, similarly to Linux kernel, has a separate
> stack for each process and each time a process makes a function call,
> a stack frame is added to stack containing information about function,
> it's arguments and variables and removed from stack once function
> returns to caller? As there is a command "show stack " I guess
> there is a stack per process..
>
>
> 2) For example if following information is logged to crashinfo file
> during the L3 switch crash right before the forced reload:
>
> Traceback: 110DFFB8 10B04E98 11A391D0 116F6428 1172171C 10A8FA34 10A86BB4
>
> Stack frames:
> Frame 1: pc=10B04E98 stack=20D0D670
> Frame 2: pc=11A391D0 stack=20D0D678
> Frame 3: pc=116F6428 stack=20D0D6B0
> Frame 4: pc=1172171C stack=20D0D730
> Frame 5: pc=10A8FA34 stack=20D0D7B0
> Frame 6: pc=10A86BB4 stack=20D0D7B8
>
>
> ..then how can TAC engineer trace back to certain function call? I
> understand that TAC engineers have probably access to IOS source code,
> symbol tables etc, but how how are the stack frames listed on
> "Traceback" line mapped to actual function calls and processes?
>
>
> 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/

Re: [c-nsp] Sup2T - poor netflow performance

[Tóth András]

Hi Jiri,

You could try with less collect parameters. I'd remove them and increase
gradually to find out which one causes the biggest performance decrease.

You might try the following netflow full-flow config:

flow record FULL
 match ipv4 source address
 match ipv4 destination address
 match transport source-port
 match transport destination-port
 match flow direction
 collect counter bytes

flow exporter FULL-EXPORT
 destination x.x.x.x
 source Vlan1
 transport udp 9996

flow monitor FULL-MONITOR
 record FULL
 exporter FULL-EXPORT

Best regards,
Andras



On Tue, Mar 26, 2013 at 4:37 PM, Jiri Prochazka <
jiri.procha...@superhosting.cz> wrote:

> Hi,
>
> after replacing one of our old vs-s720-3cxl and 6708-3cxl combo for a new
> sup2t-xl and 6908-2txl I'm struggling with a really poor netflow
> performance.
>
> In fact, enhanced netflow capacity and capabilities were the major reasons
> for upgrade.
>
> On the old vs-s720-3cxl setup we have used interface-src-dst flowmask.
> With aggresive timing, this setup was able to 'handle' around 6 Gbps of
> strandard Internet traffic (per DFC) without undercounting and overwhelming
> the whole box.
>
>
> Now, when using sup2t-xl, which has two times bigger netflow table (512k
> for ingress flows) and faster CPU, I'm not able to get it working with even
> with the same level of traffic.
>
>
> As soon as traffic on ingress reaches aproximately 3 Gbps, and number of
> flows per one cache(card) exceeds 200k, the whole box begins to be
> unresponsive to SNMP polls, timeouts some commands (for example show
> platform flow ip count module x) and the CLI begins to lag.
>
> Furthermore, I get a lot of following messages ->
>
> %IPC-DFC2-5-WATERMARK: 2013 messages pending in rcv for the port
> Card2/0:Request(202.7) seat 202
> %IPC-DFC2-5-WATERMARK: 2019 messages pending in rcv for the port
> Card2/0:Request(202.7) seat 202
>
>
> Utilization of CPU either of Sup or linecards is acceptable (under 60%,
> majority is taken by 'NF SE export thr' and 'NF SE Intr Task' processes).
>
>
> Settings of netflow is following ->
>
> flow record SRC-IP-IF-DST-IP-IF-AS
>  match ipv4 source address
>  match ipv4 destination address
>  collect routing source as
>  collect routing destination as
>  collect routing next-hop address ipv4
>  collect interface input
>  collect interface output
>  collect counter bytes
>  collect counter packets
>  collect timestamp sys-uptime first
>  collect timestamp sys-uptime last
>
>
> flow monitor LIVEBOX-MONITOR
>  description LIVEBOX v9 monitor
>  record SRC-IP-IF-DST-IP-IF-AS
>  exporter LIVEBOX-EXPORT
>  cache timeout inactive 3
>  cache timeout active 60
>
> flow exporter LIVEBOX-EXPORT
>  destination x.x.x.x
>  source Vlanx
>  transport udp 9996
>
>
>
>
> Did you notice any REAL perfomance boost compared to older Sup720 with
> B/CXL DFCs?
>
>
> Thank you!
>
>
>
> --
> Jiri Prochazka
> network administrator (AS39392)
> SuperNetwork s.r.o.
> __**_
> 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] Rancid causing reload SUP2T 12.2.50-SY3

[Tóth András]

That means the supervisor have crashed, reloaded and became the standby.
You should look for "crashinfo" files on the bootflash: of the supervisor
which have crashed (now standby). Looking into those crashinfo files you
might either find some clue about the reason, or you can upload it to the
Output Interpreter on Cisco.com, or open a TAC case attaching those files.

Best regards,
Andras



On Tue, Mar 26, 2013 at 5:19 PM, Peter Kranz  wrote:

> Had a 6506-E running redundant Sup2T's perform a failover from ACTIVE to
> HOT
> STANDBY yesterday with nothing showing in the logs right after the hourly
> RANCID collection completed. Running
> s2t54-advipservicesk9-mz.SPA.122-50.SY3.bin
>
> Anyone seen this?
>
>
>
> Peter Kranz
> Founder/CEO - Unwired Ltd
> www.UnwiredLtd.com 
> Desk: 510-868-1614 x100
> Mobile: 510-207-
> pkr...@unwiredltd.com 
>
>
>
>
>
> ___
> 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] HSRP v2 on 3750G

[Tóth András]

If the question is whether it's supported, then yes. Support for HSRP
Version 2 (HSRPv2) is available from 12.2(46)SE and later.

VRF-aware HSRP support is available from 12.2(40)SE and later. HSRPv6 in
IPBase is from 12.2(50)SE.

>From the config guide:
"Routers in an HSRP group can be any router interface that supports HSRP,
including Catalyst 3750 routed ports and switch virtual interfaces (SVIs)."

Best regards,
Andras



On Tue, Mar 26, 2013 at 9:59 PM, Jeff Kell  wrote:

> Anyone doing HSRP v2 on a 3750G (IP Services) ?   Bonus points if on a
> VRF SVI ?
>
> Jeff
>
> ___
> 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] Weird 6500 VSS + VPLS ARP problem

[Tóth András]

Hi Sander,

Sounds like the following defect:
CSCtq34985 - DCI: A-VPLS VCs not synced to standby Sup

This is fixed in 15.0(1)SY1. You could consider upgrading to the latest
15.1(1)SY which contains this fix already.

Best regards,
Andras



On Fri, Mar 15, 2013 at 3:11 PM, Sander Steffann  wrote:

> Hi,
>
> Short update for those interested:
>
> > The problem is in the ARP traffic. The plain 6500 sends an ARP request
> to the VSS side, which receives it but doesn't send a reply back over VPLS.
>
> And it turns out that this happens because the VSS doesn't learn the MAC
> addresses from packets coming in over VPLS. So it doesn't know it should
> send the ARP reply back over VPLS.
>
> Why adding static ARP entries helped here yesterday is a mystery to me.
> Today it doesn't... Probably has something to do with the VSS remembering
> stuff on a active/passive switchover.
>
> Is there anybody who has deployed c6500+Sup2t+VSS+VPLS?
>
> Cheers,
> Sander
>
>
> ___
> 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] 4500-X VSS %EC-5-CANNOT_BUNDLE2

[Tóth András]

And if you add "switchport" and "switch virtual link 1" on the port-channel
before adding Te1/16 as a member interface, like below?

int po5
 switchport
 switch virtual link 1

int te1/16
 channel-group 5 mode on

Best regards,
Andras



On Wed, Mar 13, 2013 at 4:57 AM, CiscoNSP List wrote:

>
> Thanks Andras -
>
>
> I removed portchan5, defaulted te1/16, re-added portchan5 and then only
> added "channel-group 5 mode on" under te1/16, and still get the following
> error:
>
>
> *Mar 12 19:51:33.155: %EC-5-CANNOT_BUNDLE2: Te1/16 is not compatible with
> Po5 and will be suspended (trunk mode of Te1/16 is dynamic, Po5 is trunk)
>
>
> These are 2 new switches, so dont have smartnet on them (yet)Ill get
> smartnet this week and open a TAC case as it does look like it is a bug.
>
>
> Thanks again for your help.
>
>
>
> --
> Date: Wed, 13 Mar 2013 03:14:14 +0100
>
> Subject: Re: [c-nsp] 4500-X VSS %EC-5-CANNOT_BUNDLE2
> From: diosbej...@gmail.com
> To: cisconsp_l...@hotmail.com
> CC: g...@greenie.muc.de; cisco-nsp@puck.nether.net;
> cisco-nsp-boun...@puck.nether.net
>
>
> Those config lines are added because it's a VSL (Virtual Switch Link)
> between the two VSS boxes.
>
> When you configure VSL, all existing configurations are removed from the
> interface except for specific allowed commands. When you configure VSL, the
> system puts the interface into a restricted mode. This means that only
> specific configuration commands can be configured on the interface.
>
> The following VSL configuration commands are inserted automatically on all
> VSL member ports:
> switchport mode trunk
> switchport nonegotiate
> no lldp transmit
> no lldp receive
> no cdp enable
> service-policy output VSL-Queuing-Policy
>
>
> Also note the following:
> In VSL restricted mode, only these configuration commands are available:
> channel-group
> ...
>
> This seems to suggest that you should not try to configure switchport
> commands on your VSL link. Please see the Configuration Guide below for
> details:
>
>
> http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/15.1.2/XE_340/configuration/guide/vss.html
>
>
> If you still find that there's an error in the simple process of adding
> interfaces to the port-channel when it's used as a VSL, then I'd suggest to
> open a TAC case because it might be a new bug, given that VSS on 4500 is a
> pretty new feature, but it seems you just don't need to mess with
> switchport config on VSL ports.
>
> Best regards,
> Andras
>
>
>
> On Wed, Mar 13, 2013 at 12:39 AM, CiscoNSP List  > wrote:
>
>
>
> Thanks for the reply Gert.
>
> On the 4500X, the sequence is (As you describe):
>
> Create portchan, then add portchan to physical/member Int.
>
> For VSS on the 4500X,  it is:
>
> SW1(config)#int port-channel 5
> SW1(config-if)#switchport
> SW1(config-if)#switch virtual link 1
> SW1(config-if)#no shut
> SW1(config-if)#exit
>
>
> SW1(config)#int TenGigabitEthernet1/16
> SW1(config-if)#switchport mode trunk
> SW1(config-if)#channel-group 5 mode on
>
>
> The 4500X then "automagically" adds the following to the physical Int (And
> also restricts what commands you can enter on the member Interface)
>
>  switchport nonegotiate
>  no lldp transmit
>  no lldp receive
>  no cdp enable
>  service-policy output VSL-Queuing-Policy
>
>
>
>
>
>
> > Date: Tue, 12 Mar 2013 09:39:58 +0100
> > From: g...@greenie.muc.de
> > To: cisconsp_l...@hotmail.com
> > CC: e...@edgeoc.net; cisco-nsp-boun...@puck.nether.net;
> cisco-nsp@puck.nether.net
> > Subject: Re: [c-nsp] 4500-X VSS  %EC-5-CANNOT_BUNDLE2
> >
> > Hi,
> >
> > On Tue, Mar 12, 2013 at 12:42:46PM +1100, CiscoNSP List wrote:
> > > Portchan conf (That fails):  (Hotmail will probably screw the
> formatting):
> > >
> > > interface Port-channel5
> > >  switchport
> > >  switchport mode trunk
> > >  switchport nonegotiate
> > >  switch virtual link 1
> > >
> > > And Int conf:
> > >
> > > interface TenGigabitEthernet1/16 switchport mode trunk
> > > switchport nonegotiate
> > > no lldp transmit
> > > no lldp receive
> > > no cdp enable
> > > channel-group 5 mode on
> > > service-policy output VSL-Queuing-Policy
> >
> > Don't configure stuff on member interfaces after joining a channel.
>  Ever.
> >
> > (IOS should just disallow this in the first place)
> >
> >
> > The "right" sequence of things is:
> >
> >   int te1/16
> > switchport
> > channel-group 5 mode on
> > no shut
> >
> > and then *everything else* is configured under "int port-channel 5",
> including
> > trunk/no trunk, vlans, service-policy, ...
> >
> > (For some stupid reasons, switchport/no switchport needs to be set on the
> > interface first, before joining the channel)
> >
> > gert
> > --
> > USENET is *not* the non-clickable part of WWW!
> >//
> www.muc.de/~gert/
> > Gert Doering - Munich, Germany
> g...@greenie.muc.de
> > fax: +49-89-35655025
> g...@net.informatik.tu-muenchen.de
>
> ___

Re: [c-nsp] NX-OS MPLS not answering to traces

[Tóth András]

Hi Bernhard,

It could be CoPP related as well if that's dropping packets arriving to the
control-plane. If you have upgraded the N7k from an older release (4.x or
5.1) you might not have all the latest and necessary CoPP rules in the
policy-map and class-maps matching MPLS. These were added in 5.2(1) but
during an ISSU or classic upgrade the CoPP policies are not updated
automatically.

One example is the "match protocol mpls" line in
the copp-system-p-class-l2-default class.

"5.2(1) - Updated the default class maps with support for MPLS LDP, MPLS
OAM, MPLS RSVP, DHCP relay, and OTV-AS." Please see the following link for
details and default copp templates.

http://www.cisco.com/en/US/docs/switches/datacenter/sw/6_x/nx-os/security/configuration/guide/b_Cisco_Nexus_7000_NX-OS_Security_Configuration_Guide__Release_6.x_chapter_011001.html

You can re-apply the latest factory default CoPP profile with the "copp
profile" global configuration command and choose between strict, moderate
and lenient profiles.

Best regards,
Andras



On Wed, Mar 13, 2013 at 8:06 AM, Bernhard Schmidt wrote:

> Hello Andras,
>
>
>  Long shot but you might need to change the revision for echo packets on
>> NX-OS to revision 3 (default is 4).
>>
>> 1.configure terminal
>> 2.mpls oam
>> 3.echo revision {3 | 4}
>> 4.echo vendor-extension
>> 5.exit
>>
>> http://www.cisco.com/en/US/**docs/switches/datacenter/sw/5_**
>> x/nx-os/mpls/configuration/**guide/mp_mpls_ping.html#**wp1078363
>>
>
> Interesting read, thanks. But unfortunately that does not change the
> behaviour.
>
> Best Regards,
> Bernhard
>
>  On Tue, Mar 12, 2013 at 6:57 PM, Bernhard Schmidt > > wrote:
>>
>> Hey everyone,
>>
>> just a quick question, can anyone confirm or deny that NX-OS 6.1(2)
>> (or
>> (3)) MPLS P-Routers do not answer to normal traces with propagate-ttl
>> set (which is the default)?
>>
>> csr1-kra# traceroute 129.187.0.9
>> traceroute to 129.187.0.9 (129.187.0.9), 30 hops max, 40 byte packets
>>   1  * * *
>>   2  129.187.0.142 (129.187.0.142) (AS 12816)  1.172 ms  1.404 ms
>>   0.981 ms
>>[Label=1151 E=0 TTL=1 S=1]
>>   3  * * *
>>   4  129.187.0.130 (129.187.0.130) (AS 12816)  1.252 ms *  1.735 ms
>>
>> csr1-kra# traceroute mpls ipv4 129.187.0.9/32 
>>
>>
>> Tracing MPLS Label Switched Path to 129.187.0.9/32
>> , timeout is 2 seconds
>>
>>
>> Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
>> 'L' - labeled output interface, 'B' - unlabeled output interface,
>> 'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
>> 'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
>> 'P' - no rx intf label prot, 'p' - premature termination of LSP,
>> 'R' - transit router, 'I' - unknown upstream index,
>> 'X' - unknown return code, 'x' - return code 0
>>
>> Type Ctrl-C to abort.
>>0 129.187.0.162 MRU 9216 [Labels: 71 Exp: 0]
>> . 1 *
>> L 2 129.187.0.142 MRU 9216 [Labels: 65 Exp: 0] 194 ms
>> . 3 *
>> ! 4 129.187.0.130 2 ms
>>
>> Hops 0, 1 and 3 are NX-OS, Hops 2 and 4 are IOS (6500).
>>
>> Thanks,
>> Bernhard
>>
>> __**_
>> 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] 4500-X VSS %EC-5-CANNOT_BUNDLE2

[Tóth András]

Those config lines are added because it's a VSL (Virtual Switch Link)
between the two VSS boxes.

When you configure VSL, all existing configurations are removed from the
interface except for specific allowed commands. When you configure VSL, the
system puts the interface into a restricted mode. This means that only
specific configuration commands can be configured on the interface.

The following VSL configuration commands are inserted automatically on all
VSL member ports:
switchport mode trunk
switchport nonegotiate
no lldp transmit
no lldp receive
no cdp enable
service-policy output VSL-Queuing-Policy


Also note the following:
In VSL restricted mode, only these configuration commands are available:
channel-group
...

This seems to suggest that you should not try to configure switchport
commands on your VSL link. Please see the Configuration Guide below for
details:

http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/15.1.2/XE_340/configuration/guide/vss.html


If you still find that there's an error in the simple process of adding
interfaces to the port-channel when it's used as a VSL, then I'd suggest to
open a TAC case because it might be a new bug, given that VSS on 4500 is a
pretty new feature, but it seems you just don't need to mess with
switchport config on VSL ports.

Best regards,
Andras



On Wed, Mar 13, 2013 at 12:39 AM, CiscoNSP List
wrote:

>
>
> Thanks for the reply Gert.
>
> On the 4500X, the sequence is (As you describe):
>
> Create portchan, then add portchan to physical/member Int.
>
> For VSS on the 4500X,  it is:
>
> SW1(config)#int port-channel 5
> SW1(config-if)#switchport
> SW1(config-if)#switch virtual link 1
> SW1(config-if)#no shut
> SW1(config-if)#exit
>
>
> SW1(config)#int TenGigabitEthernet1/16
> SW1(config-if)#switchport mode trunk
> SW1(config-if)#channel-group 5 mode on
>
>
> The 4500X then "automagically" adds the following to the physical Int (And
> also restricts what commands you can enter on the member Interface)
>
>  switchport nonegotiate
>  no lldp transmit
>  no lldp receive
>  no cdp enable
>  service-policy output VSL-Queuing-Policy
>
>
>
>
>
>
> > Date: Tue, 12 Mar 2013 09:39:58 +0100
> > From: g...@greenie.muc.de
> > To: cisconsp_l...@hotmail.com
> > CC: e...@edgeoc.net; cisco-nsp-boun...@puck.nether.net;
> cisco-nsp@puck.nether.net
> > Subject: Re: [c-nsp] 4500-X VSS  %EC-5-CANNOT_BUNDLE2
> >
> > Hi,
> >
> > On Tue, Mar 12, 2013 at 12:42:46PM +1100, CiscoNSP List wrote:
> > > Portchan conf (That fails):  (Hotmail will probably screw the
> formatting):
> > >
> > > interface Port-channel5
> > >  switchport
> > >  switchport mode trunk
> > >  switchport nonegotiate
> > >  switch virtual link 1
> > >
> > > And Int conf:
> > >
> > > interface TenGigabitEthernet1/16 switchport mode trunk
> > > switchport nonegotiate
> > > no lldp transmit
> > > no lldp receive
> > > no cdp enable
> > > channel-group 5 mode on
> > > service-policy output VSL-Queuing-Policy
> >
> > Don't configure stuff on member interfaces after joining a channel.
>  Ever.
> >
> > (IOS should just disallow this in the first place)
> >
> >
> > The "right" sequence of things is:
> >
> >   int te1/16
> > switchport
> > channel-group 5 mode on
> > no shut
> >
> > and then *everything else* is configured under "int port-channel 5",
> including
> > trunk/no trunk, vlans, service-policy, ...
> >
> > (For some stupid reasons, switchport/no switchport needs to be set on the
> > interface first, before joining the channel)
> >
> > gert
> > --
> > USENET is *not* the non-clickable part of WWW!
> >//
> www.muc.de/~gert/
> > Gert Doering - Munich, Germany
> g...@greenie.muc.de
> > fax: +49-89-35655025
> g...@net.informatik.tu-muenchen.de
>
> ___
> 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] NX-OS MPLS not answering to traces

[Tóth András]

Hi Bernhard,

Long shot but you might need to change the revision for echo packets on
NX-OS to revision 3 (default is 4).

1. configure terminal
2. mpls oam
3. echo revision {3 | 4}
4. echo vendor-extension
5. exit

http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/mpls/configuration/guide/mp_mpls_ping.html#wp1078363

Best regards,
Andras



On Tue, Mar 12, 2013 at 6:57 PM, Bernhard Schmidt wrote:

> Hey everyone,
>
> just a quick question, can anyone confirm or deny that NX-OS 6.1(2) (or
> (3)) MPLS P-Routers do not answer to normal traces with propagate-ttl
> set (which is the default)?
>
> csr1-kra# traceroute 129.187.0.9
> traceroute to 129.187.0.9 (129.187.0.9), 30 hops max, 40 byte packets
>  1  * * *
>  2  129.187.0.142 (129.187.0.142) (AS 12816)  1.172 ms  1.404 ms  0.981 ms
>   [Label=1151 E=0 TTL=1 S=1]
>  3  * * *
>  4  129.187.0.130 (129.187.0.130) (AS 12816)  1.252 ms *  1.735 ms
>
> csr1-kra# traceroute mpls ipv4 129.187.0.9/32
>
> Tracing MPLS Label Switched Path to 129.187.0.9/32, timeout is 2 seconds
>
> Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
>   'L' - labeled output interface, 'B' - unlabeled output interface,
>   'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
>   'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
>   'P' - no rx intf label prot, 'p' - premature termination of LSP,
>   'R' - transit router, 'I' - unknown upstream index,
>   'X' - unknown return code, 'x' - return code 0
>
> Type Ctrl-C to abort.
>   0 129.187.0.162 MRU 9216 [Labels: 71 Exp: 0]
> . 1 *
> L 2 129.187.0.142 MRU 9216 [Labels: 65 Exp: 0] 194 ms
> . 3 *
> ! 4 129.187.0.130 2 ms
>
> Hops 0, 1 and 3 are NX-OS, Hops 2 and 4 are IOS (6500).
>
> Thanks,
> Bernhard
>
> ___
> 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 software forwarding

[Tóth András]

Hi Peter,

MAC learning is fully hardware based on 6500 Sup720, therefore even if it's
flapping it will not cause packets to be software switched, nor CPU usage
to increase due to learning.

Did you rectify the MAC flapping issue? If so, did you see an improvement
with those flows, i.e. did they disappear from ibc/netdr and the CPU usage
went down?

Any traces of warnings in the logs? Any resources exhausted? "sh pla ha ca"
might reveal it.

Best regards,
Andras



On Mon, Mar 11, 2013 at 7:18 AM, Peter Rathlev  wrote:

> On Sat, 2013-03-09 at 04:15 -0600, William McCall wrote:
> > On 03/08/2013 09:57 AM, Peter Rathlev wrote:
> > > Is there a way to rate-limit this kind of punting? Standard "mls
> > > rate-limit" doesn't seem to have anything useful, unless I'm just too
> > > tired to see it.
> >
> > Looks like CoPP might do it in this case (I want to be more certain, but
> > time constraints make it prohibitive to lab up right now).
>
> We'll try that in a test-setup. The device in question was actually
> using a CoPP profile but not a very strict one. We tried disabling it
> and saw no improvement, but that was of course expected. :-)
>
> If the punting is only for logging then discarding the packets is okay.
>
> But if they need to be software forwarded it's worse. The MAC flapping
> was the only hint that something was wrong, and I had not expected MAC
> flapping to make a Sup720 punt packets. If CoPP would discard traffic
> I'd rather have the sup forward what it can until I can find a fix.
>
> --
> 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] nx-os ssh connection startup delay ?

[Tóth András]

Hi Jeffrey,

As Chuck highlighted this could be due to a delay reaching the AAA server.

I would also try disabling DNS lookups with "no ip domain-lookup" because
when SSH is established the reverse record for the IP might be requested
causing a delay.

You could also do an ethanalyzer capture in the main vdc in one session
while doing an SSH connection to the N7k and check what's happening.

Best regards,
Andras



On Mon, Mar 11, 2013 at 4:55 PM, Jeffrey G. Fitzwater
wrote:

> cisco 7k 6.1.2
>
> We are seeing delays when ssh-ing to system just before the banner page
> comes up.
>
> Once session is up we see no delay.
>
>
> It has become very consistent when we log-in recently and the delay is
> always just before the banner is displayed.
>
>
>
> Debugging of the SSH session at client end just shows an approx 10 sec
> pause just before the banner is displayed.
>
>
> I would like to debug at the nx-os end but I cannot find the correct
> commands.
>
>
>
> Has anybody seen this delay issue or know the correct DEBUG commands for
> SSH?
>
>
>
> Thanks for any help…
>
>
>
> Jeff Fitzwater
> OIT Network Systems
> Princeton University
> ___
> 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] 4500-X 'Lite' IOS

[Tóth András]

>From the Release Notes
http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/release/note/OL_27989-01.html

Image Categories

Universal_lite image includes two levels of feature sets—LAN Base and IP
Base. Anyone with guest access can download the Universal_lite image from
cisco.com. If you purchase LAN Base or IP Base, you will receive free
software updates.

Universal Image includes three level of feature sets—LAN Base, IP Base, and
Enterprise Services. To download the Universal Image, you must have a valid
technical support service agreement associated with your Cisco.com user ID.
If you purchase a SMARTnet contract, you will receive software updates for
all levels of feature sets.


Best regards,
Andras



On Wed, Mar 6, 2013 at 4:38 PM, Brandon Applegate  wrote:

> I can't find any info on what the difference is on this.  This is of
> course 4500 Sup 7 IOS - and 'universal', so licensed.  But on the download
> page there is a lite and a non-lite version.  Strangely - the non-crypto
> lite version of the latest is actually BIGGER than the non-lite.
>
> I would imagine that 'lite' takes things away - but what ?  Is this more
> for the 4500 chassis based line ?  On a fairly fixed config 1U switch like
> the 4500-X I can't imagine why I would need so many options.
>
> Apologies if I've missed something obvious (all searches for 'lite' just
> hit on vrf-lite related stuff).  Thanks.
>
> --
> Brandon Applegate - CCIE 10273
> PGP Key fingerprint:
> 8779 B023 7637 CEC8 C5C6 4052 664D 7E08 3CBB 1739
> "SH1-0151.  This is the serial number, of our orbital gun."
>
> __**_
> 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] New to Nexus gear.... how does the licenses work?

[Tóth András]

You need to install certain licenses for certain features to be available.
This is how it works:
http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/configuration/guide/cli/Licensing.html

Best regards,
Andras



On Wed, Feb 13, 2013 at 7:06 PM, Scott Voll  wrote:

> So we just got our new 5548UPs in the door.  per the doc's it says the
> licenses are installed from the factor.  But doing a show license usage we
> get all the pkg files saying install --> no.  license count --
>
> What am I missing here?
>
> TIA
>
> Scott
> ___
> 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] Arrows in the output of "show tcam interface" on 7600

[Tóth András]

As far as I remember when the hitcount for the particular VMR is not 0, it
will get an arrow.

Andras



On Wed, Feb 13, 2013 at 6:29 AM, John Neiberger wrote:

> I was looking through the output of "show tcam interface  acl
> out ip detail" and I'm wondering what arrows at the end of the lines mean.
> Most lines don't have them, but occasional entries do have them.
>
>  V 10172 0.0.0.0 0.0.0.0   P=0 P=0
> --   0  0 192 -- C-- 0-0  <-
>  M 10178 0.0.0.0 0.0.0.0 0   0
> --   0  0 252 <-
>  R rslt: PERMIT_RESULT (*) rtr_rslt: PERMIT_RESULT
> (*)   hit_cnt=4521  <-
>
>  V 10173 0.0.0.0 0.0.0.0   P=0 P=0
> --   0  0 136 -- C-- 0-0
>  M 10178 0.0.0.0 0.0.0.0 0   0
> --   0  0 252
>  R rslt: PERMIT_RESULT (*) rtr_rslt: PERMIT_RESULT
> (*)   hit_cnt=0
>
> Any idea what those indicate?
> ___
> 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 ICMP redirects "once per second"

[Tóth András]

I don't see in RFC 1122 that the original packet should/must be dropped
when a redirect condition is triggered and an icmp redirect message is
sent. So I think it's normal that the supervisor forwards all packets, RFC
792 seems to confirm this. If you want to avoid packets to be punted, "no
ip redirects" and "mls rate-limit" are there.

Are you sure that the traffic triggering the redirects is 10 Mbit/s? Are
you sure it's subject to CoPP at all? Maybe that's why you're not seeing
matches in CoPP counters. You can do an inband SPAN or netdr capture to see
if packets are really punted. I would keep on the table that maybe some
pings between host1 and host2 or some other hosts trigger the redirects and
that original traffic is 1 pps.

If doing a CPU capture confirms that 10Mbps is punted indeed, TAC can help
you to perform an ELAM capture for that traffic to see if it will trigger a
redirect (based on destination index) or not. They can also assist in
performing CPU captures using netdr in RX and TX directions to see how many
and what kind of packets are punted to CPU and what is generated by the CPU.

Best regards,
Andras



On Mon, Feb 11, 2013 at 7:07 PM, Phil Mayers wrote:

> On 11/02/13 17:42, Tóth András wrote:
>
>> Hi Phil,
>>
>> As I understand you have disabled the MLS rate-limiter for redirects, so
>> that should not cause throttling, but you can check with "sh ibc" to see
>> the rate at which packets arrive to the CPU.
>>
>
> For clarity, I haven't disabled it; it's disabled by default. But yes, the
> MLS redirect limiter is disabled.
>
>
>
>> With mls rate-limit redirect disabled, packets will be still subject to
>> CoPP because they require CPU processing to generate a redirect, so
>> perhaps your CoPP policy (probably class default) is limiting them? That
>> can also cause packet loss between those stations if the traffic
>> requires punting.
>>
>
> Good guess, but I don't think so; removing the control-plane service
> policy has no effect (and in any case, the packets which are generating the
> redirect would be hitting a class-map with a 10Mbit/sec rate-limit, which
> is too high to make 1 redirect/sec).
>
> At this point, all the evidence suggests that:
>
>  1. The box is forwarding the packets back out
>  2. No more than once a second, the DFC/PFC is leaking a packet to the CPU
>  3. This packet generates the redirect
>
> I'm trying to determine what is going on in step 2; specifically, what's
> the "key" value for the rate-limit? Ingress interface, source IP, per
> forwarding engine?
>
> It's worth noting that this behaviour is also undocumented; all the docs
> I've seen imply that redirects happen every packet. What if you had a
> (weird!) config where you didn't *want* the sup720 to forward the original
> packet, and always wanted to *just* send the redirect?
>
> As you say, I *assume* the punts are subject to CoPP, but who knows?
>
>
>  You could also check the "ip icmp rate-limit unreachable" command, might
>> be applicable here too.
>>
>
> No effect sadly.
>
> Very weird...
>
___
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 6509 LACP

[Tóth András]

Hi Mike,

You can configure one unassigned IP address to each switch's "interface
Vlan x", and check if they can ping each other when using a port-channel.
This should not cause any harm if you use an unassigned IP. The configured
IP then can be used for testing between the force10 and vmware, by doing a
direct ping test between them, then between the 6500 and the vmware.

Best regards,
Andras



On Mon, Feb 11, 2013 at 6:36 PM, Mike Glass  wrote:

>  Here are the results
>
> 
> 6509
> 
> #sh spanning-tree int port-channel 1---
>
> Vlan Role Sts Cost  Prio.Nbr Type
>   --- - 
> 
> VLAN0002 Desg FWD 3 128.1665 P2p
> VLAN0004 Desg FWD 3 128.1665 P2p
> Cat6509#
>
> 
>
> -
> force10
> -
> AIS-Prod-1#sh spanning-tree rstp int Port-channel 1
>
> Port-channel 1 is designated forwarding
>
> Edge port:no (default) port guard :none (default)
> Link type: point-to-point (auto) bpdu filter:disable (default)
> Bpdu guard :disable bpduguard shutdown-on-violation : disable
> Bpdus sent 25200, received 135714
>
> InterfaceDesignated
>  Name PortID   Prio CostSts   Cost   Bridge ID
> PortID
> -   --- - --- 
> 
> Po 1  128.2128  18000   FWD   0   32768 0001.e88b.52b8
> 128.2
> AIS-Prod-1#sh spanning-tree rstp int Port-channel 2
>
> Port-channel 2 is designated forwarding
>
> Edge port:no (default) port guard :none (default)
> Link type: point-to-point (auto) bpdu filter:disable (default)
> Bpdu guard :disable bpduguard shutdown-on-violation : disable
> Bpdus sent 129288, received 0
>
> InterfaceDesignated
>  Name PortID   Prio CostSts   Cost   Bridge ID
> PortID
> -   --- - --- 
> 
> Po 2  128.3128  1800FWD   0   32768 0001.e88b.52b8
> 128.3
>
> ---
>
> The Dell switch does has not have cdp, just lldp, on the cisco switch I
> see nothing in cdp for the interfaces, the dell lldp I do see the vmware
> interfaces.
> I have switched to mode active with same results.
>
> I have not configured address on the vlans, not sure if that will break
> anything in our existing system, If I do put ip address on a vlan on our
> production system will it cause any problems?
> The force 10 vlans are tagged for vlans 4 and 2
>
> interface Vlan 4
>  no ip address
>  tagged Port-channel 1-2
>  no shutdown
>
> when I shut the port-channel off on either switch I see messages on both
> switches that eh protocol is down, so I think I am close but still cannot
> pass traffic from the a vm guest.
> I also wonder if I already have the Vmware server hooked up to the 6509 on
> another interface that uses the same vlan could be causing some problems.
> Thanks
> Mike
>
>
> >>> Tóth András 2/10/2013 1:42 PM >>>
> Hi Mike,
>
> First of all, how do you see that traffic is not passing? Could you please
> elaborate on how do you test it, from where to where are you trying to send
> traffic or ping tests? Does traffic pass if links are used as standalone
> (not being in a channel)?
>
> If you configure an IP address for each vlan interface, can you ping
> between the 6500 and the force10? If yes, the problem might be between the
> vmware and force10 instead.
>
> Are the force10 ports configured for dot1q trunk as well to be able to
> carry multiple vlans? Are they set with the same native vlan as the Cisco?
> (Default native vlan is 1)
>
> Could you do a sh spanning-tree on both switches for the po interfaces to
> make sure they are not blocking? sh span int po1
>
> Do you see the correct neighbors in cdp table? sh cdp nei
>
> Can you confirm that the same issue is observed when using 'mode active'?
>
> Best regards,
> Andras
>
>
___
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 ICMP redirects "once per second"

[Tóth András]

Hi Phil,

As I understand you have disabled the MLS rate-limiter for redirects, so
that should not cause throttling, but you can check with "sh ibc" to see
the rate at which packets arrive to the CPU.

With mls rate-limit redirect disabled, packets will be still subject to
CoPP because they require CPU processing to generate a redirect, so perhaps
your CoPP policy (probably class default) is limiting them? That can also
cause packet loss between those stations if the traffic requires punting.

You could also check the "ip icmp rate-limit unreachable" command, might be
applicable here too.

Best regards,
Andras



On Mon, Feb 11, 2013 at 4:22 PM, Phil Mayers wrote:

> On 11/02/13 15:18, Tassos Chatzithomaoglou wrote:
>
>> "show standby redirect" should provide some info.
>>
>
> Not that I can see:
>
> InterfaceRedirects Unknown   Adv  Holddown
> VlXXXenabled   enabled   30   180
>
> Active   Hits  Interface Group Virtual IPVirtual MAC
> local0 Vl9   0 x.x.x.1   .0c9f.f000
>
>
>  Since these redirects are controlled by HSRP (which changes the internal
>> IPs), maybe there is no way to change their
>> interval.
>>
>
> Maybe. The specific thing I'm interested in is understanding how the
> forwarding happens, and what path the punts take (via CoPP, MLS limits, or
> other); I'm assuming from the lack of CPU problems on this box that the
> PFC/DFC is forwarding the packets, except for the ones it is leaking to the
> CPU, but I can't be sure.
>
>
>  There is a command to disable them though.
>>
>
> Maybe, but I want to understand the problem before I do that, and to do
> that, I need to understand the path the packets take through the box.
>
> __**_
> 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 6509 LACP

[Tóth András]

Hi Mike,

First of all, how do you see that traffic is not passing? Could you please
elaborate on how do you test it, from where to where are you trying to send
traffic or ping tests? Does traffic pass if links are used as standalone
(not being in a channel)?

If you configure an IP address for each vlan interface, can you ping
between the 6500 and the force10? If yes, the problem might be between the
vmware and force10 instead.

Are the force10 ports configured for dot1q trunk as well to be able to
carry multiple vlans? Are they set with the same native vlan as the Cisco?
(Default native vlan is 1)

Could you do a sh spanning-tree on both switches for the po interfaces to
make sure they are not blocking? sh span int po1

Do you see the correct neighbors in cdp table? sh cdp nei

Can you confirm that the same issue is observed when using 'mode active'?

Best regards,
Andras

On Friday, February 8, 2013, Mike Glass wrote:

> I hope somebody can help me, I am trying to configure a 6509 as the
> passive receiver from a Dell Force10 10Ge switch with 2 sfp to 2 gig ports
> on our 6509 switch, I see LACP is up on both sides but cannot pass traffic,
> I have only 2 vlans that will carry across the aggregate link from our
> vmware boxes, this is just a temp until I get a 10ge in our 6509 chassis.
>
> Attached is the config on both sides.
>
> Make sense?
>
> ---
> Cisco 6509 Config
> ---
>
> interface GigabitEthernet6/7
>  switchport
>  no ip address
>  spanning-tree portfast
>  switchport mode trunk
>  channel-protocol lacp
>  channel-group 1 mode passive
> !
> interface GigabitEthernet6/8
>  switchport
>  no ip address
>  spanning-tree portfast
>  switchport mode trunk
>  channel-protocol lacp
>  channel-group 1 mode passive
>
>
> interface Port-channel1
>  description lacp Force10
>  switchport
>  switchport trunk encapsulation dot1q
>  Switchport mode trunk
>  no ip address
>  logging event link-status
> 
>
>
> ---
> show etherchannel detail
>
> ---
>
> Channel-group listing:
> ---
>
> Group: 1
> --
> Group state = L2
> Ports: 2   Maxports = 16
> Port-channels: 1 Max Port-channels = 16
> Protocol:   LACP
> Minimum Links: 0
> Ports in the group:
> ---
> Port: Gi6/7
> 
>
> Port state= Up Mstr In-Bndl
> Channel group = 1   Mode = Active  Gcchange = -
> Port-channel  = Po1 GC   =   - Pseudo port-channel = Po1
> Port index= 0   Load = 0x55Protocol =   LACP
>
> Flags:  S - Device is sending Slow LACPDUs   F - Device is sending fast
> LACPDUs.
> A - Device is in active mode.P - Device is in passive mode.
>
> Local information:
> LACP port Admin OperPort
>  Port
> Port  Flags   State Priority  Key   Key Number
>  State
> Gi6/7 SA  bndl  32768 0x1   0x1 0x607
> 0x3D
>
> Partner's information:
>
>   Partner Partner   LACP Partner  Partner   Partner  Partner
> Partner
> Port  Flags   State Port Priority Admin Key Oper Key Port Number
> Port State
> Gi6/7 FA  bndl  32768 0x0   0x1  0xA5
>  0x3F
>
> Age of the port in the current state: 0d:00h:08m:06s
>
> Port: Gi6/8
> 
>
> Port state= Up Mstr In-Bndl
> Channel group = 1   Mode = Active  Gcchange = -
> Port-channel  = Po1 GC   =   - Pseudo port-channel = Po1
> Port index= 1   Load = 0xAAProtocol =   LACP
>
> Flags:  S - Device is sending Slow LACPDUs   F - Device is sending fast
> LACPDUs.
> A - Device is in active mode.P - Device is in passive mode.
>
> Local information:
> LACP port Admin OperPort
>  Port
> Port  Flags   State Priority  Key   Key Number
>  State
> Gi6/8 SA  bndl  32768 0x1   0x1 0x608
> 0x3D
>
> Partner's information:
>
>   Partner Partner   LACP Partner  Partner   Partner  Partner
> Partner
> Port  Flags   State Port Priority Admin Key Oper Key Port Number
> Port State
> Gi6/8 FA  bndl  32768 0x0   0x1  0xA4
>  0x3F
>
> Age of the port in the current state: 0d:00h:08m:06s
>
> Port-channels in the group:
> --
>
> Port-channel: Po1(Primary Aggregator)
>
> 
>
> Age of the Port-channel   = 1d:01h:24m:05s
> Logical slot/port   = 14/1  Number of ports = 2
> Port state  = Port-channel Ag-Inuse
> Protocol=   LACP
>
> Ports in the Po

Re: [c-nsp] 6500e and Enhanced Poe

[Tóth András]

Hi Dan,

You don't need enterprise image for this, ipservices is sufficient.

More details about PoE config and support features can be found below:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/power_over_ethernet.html

Best regards,
Andras



On Fri, Jan 18, 2013 at 9:24 PM, Dan Benson  wrote:

> Hello all and thanks in advance for the help on this topic.
>
> I have a 6500e that I want to power a few AP1250s using Enhanced Poe.
>
> According to a lot of documentation, I should be able to get more then
> 16.8Watts from my PoE WS-X6148E-GE-45AT ge-tx blade (which says it can
> support upto 30Watts).  My issue is that I am yet able to get more then the
> 16.8Watts on the line.  I am running advipservicesk 122-33.SXJ which is
> newer then the minimal SXH2, do I need to be running adventerprise?
>
> Thanks again for any insight on this,
>
> db
>
>
>
>
>
> ___
> 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] vs interface problem on nexus7K

[Tóth András]

Hi Arne,

You seem to be in the main vdc (vdc 1) which does not have any allocated
interfaces. Note that vdc 0 means unallocated interfaces. Make sure you
change the VDC with "switchto vdc x" or do "sh run vdc-all" which should
show the interfaces in the relevant vdc.

Do you see the interfaces in "sh run vdc-all" ? Do you see them with "show
int" in the correct vdc?

Best regards,
Andras



On Tue, Jan 15, 2013 at 6:26 PM, Arne Larsen / Region Nordjylland <
a...@rn.dk> wrote:

> Hi all.
>
> I have a problem with Nexus7K
> It's 7009 chassis and dual sup2. The line cards are N7K-F132XP-15 and
> N7K-M108X2-12L.
> I can't se the interfaces in the config.
> If I do sh vdc membership, it says that the interfaces are allocated to
> the vdc.
> Have anyone seen something like this or am I missing something here.
>
> abs1nxq2(config)# sh vdc membership
>
> vdc_id: 0 vdc_name: Unallocated interfaces:
> Ethernet3/13  Ethernet3/14  Ethernet3/15
> Ethernet3/16  Ethernet3/17  Ethernet3/18
> Ethernet3/19  Ethernet3/20  Ethernet3/21
> Ethernet3/22  Ethernet3/23  Ethernet3/24
> Ethernet3/25  Ethernet3/26  Ethernet3/27
> Ethernet3/28  Ethernet3/29  Ethernet3/30
> Ethernet3/31  Ethernet3/32
>
> Ethernet4/4   Ethernet4/5   Ethernet4/6
> Ethernet4/7   Ethernet4/8
>
> vdc_id: 1 vdc_name: abs1nxq2 interfaces:
>
> vdc_id: 2 vdc_name: RN_DRIFT interfaces:
> Ethernet3/1   Ethernet3/2   Ethernet3/3
> Ethernet3/4   Ethernet3/5   Ethernet3/6
> Ethernet3/7   Ethernet3/8   Ethernet3/9
> Ethernet3/10  Ethernet3/11  Ethernet3/12
>
> Ethernet4/1   Ethernet4/2   Ethernet4/3
>
> /Arne
>
> ___
> 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] L2 car/policing on C3560X (IOS 15.0(1)SE3, ip services licence)

[Tóth András]

Append the "statistics" keyword to the "show mls qos int g0/4" command to
see more details. "show mls qos int g0/4 statistics".

Andras



On Tue, Jan 15, 2013 at 3:37 PM, Victor Sudakov  wrote:

>
> Terry Cheema wrote:
> > Yes, you should be able to do that, but on 3560/3750 I think there's
> > a limitation, it's not going to show the output of show policy-map
> > interface correctly. You can use show mls qos int g0/4 instead - it
> > should give you a view of whats going on...
> >
> > Another thing, By default qos is disabled on 3560, so no
> > classification occurs, make sure to add "mls qos" to enable, just in
> > case you havent done that...
>
> Thanks a lot, "mls qos" did the job, at least policing works.
> "show mls qos int g0/4" shows that there is a policy map, but it is
> not as informative as "show policy-map interface" would be.
>
> Could you advice a good white paper on QoS on L3 switches?
>
> --
> Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
> sip:suda...@sibptus.tomsk.ru
> ___
> 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] L2 car/policing on C3560X (IOS 15.0(1)SE3, ip services licence)

[Tóth András]

Cisco Catalyst 3750 QoS Configuration Examples
http://www.cisco.com/en/US/products/hw/switches/ps5023/products_tech_note09186a0080883f9e.shtml

Best regards,
Andras


On Tue, Jan 15, 2013 at 3:37 PM, Victor Sudakov  wrote:

>
> Terry Cheema wrote:
> > Yes, you should be able to do that, but on 3560/3750 I think there's
> > a limitation, it's not going to show the output of show policy-map
> > interface correctly. You can use show mls qos int g0/4 instead - it
> > should give you a view of whats going on...
> >
> > Another thing, By default qos is disabled on 3560, so no
> > classification occurs, make sure to add "mls qos" to enable, just in
> > case you havent done that...
>
> Thanks a lot, "mls qos" did the job, at least policing works.
> "show mls qos int g0/4" shows that there is a policy map, but it is
> not as informative as "show policy-map interface" would be.
>
> Could you advice a good white paper on QoS on L3 switches?
>
> --
> Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
> sip:suda...@sibptus.tomsk.ru
> ___
> 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] N7K QoS with FEXes

[Tóth András]

The four ports on the Cisco Nexus 7000 Series switch that connect to the
uplink ports are fabric ports. Only QoS policies can be configured on the
server-facing FEX ports. Currently, queuing on the FEX interfaces is not
supported.

http://www.cisco.com/en/US/docs/switches/datacenter/sw/6_x/nx-os/qos/configuration/guide/overview.html

Since it's not possible to apply QoS config on the FEX fabric ports, by
applying DSCP marking on the FEX host ports, packets ingressing on those
ports will retain the DSCP value while going to the parent N7k. In any
case, you might want to confirm with a SPAN capture.

Best regards,
Andras


On Mon, Jan 14, 2013 at 4:26 PM, Pavel Vraštiak wrote:

> Hi list,
> suppose you have two n7ks (F2 modules) connected to each other (vpc) and
> several FEXes directly connected to them. Now, is it neccesary/possible to
> configure any qos-related stuff on the link between fex and n7k? I was not
> successful with that. I read somewhere that there are pause frames which
> push congestion to other links.
>
> Would setting DSCP values on ingress n2ks and prioritizing traffic on
> egress from n7k based on these DSCP values be sufficient and working as
> expected?
>
> I mean, I found tons of stuff on that for n5k/n2ks, but n7k is way too
> different.
>
> Paul
> __**_
> 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 Nexus and Port-VLAN limits

[Tóth András]

Hi Adam,

The reason for having a limit is that the switch needs to program the
hardware to allow or deny packets on each port for each vlan which is
allowed on the port. In other words, based on whether a port is up/down,
whether in one particular vlan it can receive traffic or not (STP BLK), the
forwarding hardware needs to be programmed in order to process the packets
at wire-rate and this programming needs time and processing power, hence
the limit.

As the document mentions for Logical interfaces: "This parameter reflects
the load of handling port programming...". This needs to be done a per-vlan
basis, regardless of the STP mode.

Sometimes you can go above these limits a little, however be very cautious
about it, because:
1) it can result in unexpected behavior, mostly instability of STP and
other errors,
2) not supported by TAC, so if you go above the limit and some error
messages start to appear or STP goes crazy, TAC will ask you to reduce the
number of vlans on your ports so that you're below the documented limit.

Best regards,
Andras



On Sat, Jan 12, 2013 at 3:45 PM, Adam Chappell wrote:

> Hello all. Does anyone have extensive experience and familiarity with Cisco
> Nexus and specifically the causes and effects of the Port-VLAN product
> limit described here (mentioned as "Logical interfaces"):
>
>
> http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/configuration_limits/limits_521/nexus_5000_config_limits_521.html#wp327738
>
> The number appears to have varied in different software releases, but in
> 5.2.1, it's claimed as 16,000 verified, and 32,000 theoretical maximum. I
> am interpreting this to mean that I can run 320 layer-2 ports if I run them
> with 100 VLANs, but if I decide to run them with 1000 VLANs, I am limited
> to 32 ports etc. etc (depending on the limit I trust).
>
> I've got a topology probably not uncommon for cloud service provider
> environments: multi-VLAN, MAC-aware switching for a number of 10G trunk
> edge ports, which are hosting virtualisation servers with per-customer
> VLAN-based logical separation.
>
> The Nexus gives me fabulous port density, especially with the fabric
> extenders, but really I want the flexibility for the edge virtualisation
> servers to be able to manage the VM load and "tap into" VLANs
> however/whenever they wish, without manipulating switchport trunk allow
> lists, or active VLAN lists.
>
> It isn't the case that any single trunk would have anything like 1000 VLANs
> on it at any one time - but I simply want the option for the end-host to be
> able to use VLANs in that space without needing switch reconfiguration.
>
> The active topology for all VLANs would be the same, and MST is proposed
> with all VLANs mapped to single instance, so there is no per-VLAN STP tax
> that would cause a burden. I note though that the Cisco docs explicitly
> note that these limits exist independent of STP choice, so it's something
> causing the limit.
>
> It seems though that running this sort of promiscuous trunk port
> configuration seriously hampers the number of physical ports I could run.
> The number isn't disastrous  but it's not ideal either, and I am very
> curious to understand the causes of the limit, and possible actions I might
> take to mitigate its effects.  Creative suggestions I've had so far:
>
> - run the edge trunks as 802.1Q tunnel, so as to only really consume a
> single VLAN on the Nexus.
>
> - switch off or otherwise disable VLAN-awareness on the Nexus, or change
> the EtherType recognised for VLANs.
>
> These options are interesting, but they would both collapse the MAC
> switching into a single VLAN-space as well, which I'm concerned wouldn't be
> ideal for any protocols with well-known MACs (router upstreams with
> VRRP/HSRP for example?).
>
> Any experiences or suggestions welcomed and appreciated.
>
> -- Adam.
> ___
> 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-SUP720-3B and DOM/DDM enabled SFPs

[Tóth András]

According to Gigabit Transceiver Matrix, DOM is not supported for SX/LH/ZX
modules on 6500, neither Sup720 nor Sup2T nor 6824/6848 linecards.
http://www.cisco.com/en/US/docs/interfaces_modules/transceiver_modules/compatibility/matrix/OL_6981.pdf

Best regards,
Andras



On Wed, Jan 9, 2013 at 11:22 AM, Phil Mayers wrote:

> On 01/09/2013 08:24 AM, Florian Bauhaus wrote:
>
>  According to Cisco documentation (I found) the Sup720-3B does support
>> GLC-LH-SMD and GLC-SX-MMD Transceivers but does not support their DOM
>> functionality. Is that true?
>>
>
> It depends.
>
> There's a long-standing bug/limitation that means DOM doesn't work on
> 6748-SFP linecards for *any* optic. This has been discussed on the list
> previously - search the archives for details e.g.
>
> http://puck.nether.net/**pipermail/cisco-nsp/2007-**January/037234.html
> http://puck.nether.net/**pipermail/cisco-nsp/2008-**March/049187.html
>
> ...and other threads I can't find right now.
>
>
> I *believe* the SFP ports on the sup itself support DOM, but I've never
> tried it because it's completely useless - two whole ports, wow, hold on
> while I pass out with excitement!
>
>
> Basically 1gig DOM == no on sup720 platforms.
>
> Does anyone know if this is fixed on 6948/sup2T linecards?
> __**_
> 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] monitoring dropped CoPP packets ?

[Tóth András]

Hi Jeffrey,

Currently there's no simple option to show which packets are dropped or see
which actual match statement is causing drops. There's an enhancement
request filed already for doing SPAN of CoPP drops though.

You can try one of the following options:
1) Create a copy of the default copp policy with 'copp copy profile'
command and spread the match statements so you have one per class, then
apply the new policy. See the CoPP config guide below.

http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/security/configuration/guide/b_Cisco_Nexus_7000_NX-OS_Security_Configuration_Guide__Release_5.x_chapter_011001.html

2) Do an ethanalyzer capture to see what packets are arriving to the CPU.
Although this will not show the dropped packets obviously, it might give
you an indication which packets are coming with a high rate, for example if
you see high amount of ARP packets, most likely the drops are due to "match
protocol arp".

http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9402/ps9512/white_paper_c11-55.html
http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps11541/white_paper_c11-673817_ps9670_Products_White_Paper.html

Best regards,
Andras



On Fri, Jan 4, 2013 at 6:19 PM, Jeffrey G. Fitzwater wrote:

> nexus 7k with sup-1  5.2
>
>
> How can I tell which MATCH statement within a CLASS-MAP is causing CoPP
> drops shown in example below?
>
>
> Here are the two I am concerned with.  The CoPP stats were cleared 10 min
> prior to this output.
>
>
>
>
> --
> class-map copp-system-class-normal (match-any)
>  match access-group name copp-system-acl-dhcp
>  match access-group name copp-system-acl-mac-dot1x
>  match redirect dhcp-snoop
>  match protocol arp
>  set cos 1
>  police cir 680 kbps , bc 250 ms
>  module 1 :
>conformed 4741991 bytes; action: transmit
>violated 235956 bytes; action: drop
>
>
>
>
> class-map copp-system-class-l2-default (match-any)
>  match access-group name copp-system-acl-mac-undesirable
>  match protocol mpls
>  police cir 100 kbps , bc 250 ms
>  module 1 :
>conformed 1038344 bytes; action: transmit
>violated 1333130 bytes; action: drop
>
> --
>
>
>
> Thanks for any help;
>
>
>
>
>
> Jeff Fitzwater
> OIT Network Systems
> Princeton University
>
>
>
>
> ___
> 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] Enhanced IPv6 Neighbor Discovery Cache Management in 12.2SX

[Tóth András]

Why not? 'ipv6 nd cache expire' is one of the commands which has been added.

The following commands were introduced or modified: ipv6 nd cache expire,
ipv6 nd na glean, ipv6 nd nud retry.

This is mentioned in the second link you pasted.

Best regards,
Andras


On Sun, Dec 30, 2012 at 11:45 AM, David Freedman <
david.freed...@uk.clara.net> wrote:

> According to the release notes, this feature was backported into SX:
>
> http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/releas
> e/notes/features.html#wp4808396
>
> http://www.cisco.com/en/US/docs/ios-xml/ios/ipv6_basic/configuration/15-sy/
> ip6-nd-cache-mgmt.pdf
>
>
> This appears not to be so:
>
> sxi10-box-advip(config-if)#ipv6 nd cache ?
>   expire  Expiry time for ND entries
>
>
> Does anybody know if this actually took place?
>
> Feature navigator doesn't think so.
>
> Dave.
>
>
> ___
> 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] N7K with FEX - Port-Channel Load Distribution

[Tóth András]

Hi Oliver,

Verify the port-channel load-balance configuration and make sure it's set
to dest-ip-port or try out other options for more granular distribution of
traffic. The default load-balancing mode for Layer 3 interfaces is the
source and destination IP address. The load-balance configuration needs to
be done in the default VDC.

http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/interfaces/configuration/guide/if_portchannel.html

After changing the load-balance method to include L4 ports, you could run
multiple iterations of iperf which will by default use a random source port
so you can check if traffic is hashed to multiple links.

Best regards,
Andras


On Mon, Dec 17, 2012 at 12:09 AM, Oliver Garraux wrote:

> Hey,
>
> Has anyone seen issues with the load balancing on port-channels going
> to hosts connected to FEX's attached to Nexus 7k's?
>
> We have a few hosts that are connected via port-channels to either a
> 2248 or 2232 FEX.  The FEX's are hanging off of a 7k.  This is working
> as far as I can tell, in that all of the ports appear to be
> operational in the port-channel.  On the switch though, I'm seeing
> 99.99% of the traffic being sent out of one of the links in the 4 port
> port-channels (with "show port-channel traffic").  Some of the
> port-channels show 100% of traffic over one link, a few are just
> 99.99% or something like 99.92%.  I'm seeing reasonably balanced stats
> for received traffic.
>
> One of the 7k's is using L3+L4 hashing, one is using just L3.  With
> "show port-channel load-balance forwarding-path", I can see that if I
> change one of the source IP's, the 7k says that it will choose a
> different link in the port-channel.  I'm still waiting on one of the
> server guys to let me know what IP's are connecting to these servers,
> but it seems somewhat implausible to me that this is caused by there
> just being a very small number of large flows that happen to get
> hashed onto the same link.  I'm seeing this on all of the host facing
> port-channels that we have off of the FEX's, and I see this
> historically looking through our monitoring system, as well as right
> now.
>
> These are 7k's running 5.2(3a).  I'm noticing this on two different
> 7k's, with both 2248 and 2232 FEX's, and across 10+ different
> port-channels to hosts.  I'm not seeing this on any of the routed L3
> port-channels to other network devices though.  The load balancing on
> the port-channels between the 7k and the FEX's themselves also looks
> reasonable.
>
> Thanks,
>
> Oliver
>
> -
>
> Oliver Garraux
> Check out my blog:  blog.garraux.net
> Follow me on Twitter:  twitter.com/olivergarraux
> ___
> 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] Copper SFP with ME3600X

[Tóth András]

According to the transceiver matrix, GLC-T is not supported in ASR1k, only
the SFP-GE-T. If you meant that, still you might either need "speed 1000"
or if that's not supported, it might not work in SFP+ ports which is the
case for ME3600X (also confirmed by the matrix pdf).
http://www.cisco.com/en/US/docs/interfaces_modules/transceiver_modules/compatibility/matrix/OL_6981.pdf

Andras


On Tue, Dec 11, 2012 at 3:05 PM,  wrote:

> We have the same issue.
> Booth on the 3600 and the ASR1001.
> From what we gather only some Copper SFPs are working.
> GLC-T is a hit miss type of thing.
> When using 3rd party SFPs it seems that using ones that dosent support
> 10/100/1000 but is fixed at 1000 mbit almost always solves the issue. Could
> it be that the 10/100/1000 portion of the GLC-T isnt supported in SFP+
> ports?
>
> Gustav Uhlander
> Communication & Infrastructure Engineer
>
> Steria AB
> Kungsbron 13
> Box 169
> SE-101 23 Stockholm
> Sweden
>
> Tel: +46 8 622 42 15
> Fax: +46 8 622 42 23
> Mobile: +46 70 962 71 03
> gustav.ulan...@steria.se
> www.steria.se
>
>
> -cisco-nsp-boun...@puck.nether.net skrev: -
> Till: Tóth András 
> Från: Lobo **
> Sänt av: cisco-nsp-boun...@puck.nether.net
> Datum: 2012-12-10 21:30
> Kopia: Cisco-nsp 
> Ärende: Re: [c-nsp] Copper SFP with ME3600X
>
> Ahhh interesting.  So it looks like the GLC-T is actually NOT supported
> on those two SFP ports according to that matrix.
>
> BTW, this switch's client ports are copper 10/100/1000 RJ-45 so no SFP
> is required on them.  Looks like this particular model number only
> supports the fiber based SFPs.
>
> Thanks!
>
> Jose
>
> On 12/10/2012 2:55 PM, Tóth András wrote:
> > GLC-T does not seem to be supported in the SFP+ port, only supported
> > in the client ports.
> >
> http://www.cisco.com/en/US/docs/interfaces_modules/transceiver_modules/compatibility/matrix/OL_6981.pdf
> >
> > If you move the SFP to a client port, does it work?
> >
> > Andras
> >
> >
> > On Mon, Dec 10, 2012 at 8:44 PM, Lobo  > <mailto:loboti...@gmail.com >> wrote:
> >
> > Normally I would agree with this command but it's not supported.
> > The only "speed" command is nonegotiate and it doesn't make a
> > difference when plugging the SFP in.
> >
> > Jose
> >
> >
> > On 12/10/2012 2:40 PM, Tóth András wrote:
> >> Given that this is a 1G in a 10G port, you might need to add
> >> "speed 1000" to the interface config?
> >>
> >> Best regards,
> >> Andras
> >>
> >>
> >> On Mon, Dec 10, 2012 at 8:12 PM, Lobo  >> <mailto:loboti...@gmail.com >> wrote:
> >>
> >> Hi everyone.  Been having a hard time trying to get a copper
> >> SFP to work on our ME-3600X-24TS-Ms.  According to Cisco
> >> documentation, the GLC-T SFP is supposed to be supported on
> >> one of the fiber ports. However every Cisco SFP we've tried
> >> always spits back an error message:
> >>
> >> Switch#
> >>
> >> *Dec  6 19:48:30.448: %PHY-4-SFP_NOT_SUPPORTED: The SFP in
> >> Te0/1 is not supported
> >>
> >> *Dec  6 19:48:30.448: %PM-4-ERR_DISABLE: gbic-invalid error
> >> detected on Te0/1, putting Te0/1 in err-disable state
> >>
> >> Switch#
> >>
> >>
> >> Has anyone had any success with trying to use these on this
> >> platform?  Fiber based SFPs are fine so long as they're Cisco
> >> branded.  Are there different versions of GLC-T that we may
> >> have the wrong type?
> >>
> >> Thanks.
> >>
> >> Jose
> >> ___
> >> cisco-nsp mailing list cisco-nsp@puck.nether.net
> >> <mailto: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] Copper SFP with ME3600X

[Tóth András]

GLC-T does not seem to be supported in the SFP+ port, only supported in the
client ports.
http://www.cisco.com/en/US/docs/interfaces_modules/transceiver_modules/compatibility/matrix/OL_6981.pdf

If you move the SFP to a client port, does it work?

Andras


On Mon, Dec 10, 2012 at 8:44 PM, Lobo  wrote:

>  Normally I would agree with this command but it's not supported.  The
> only "speed" command is nonegotiate and it doesn't make a difference when
> plugging the SFP in.
>
> Jose
>
>
> On 12/10/2012 2:40 PM, Tóth András wrote:
>
> Given that this is a 1G in a 10G port, you might need to add "speed 1000"
> to the interface config?
>
>  Best regards,
> Andras
>
>
>  On Mon, Dec 10, 2012 at 8:12 PM, Lobo  wrote:
>
>> Hi everyone.  Been having a hard time trying to get a copper SFP to work
>> on our ME-3600X-24TS-Ms.  According to Cisco documentation, the GLC-T SFP
>> is supposed to be supported on one of the fiber ports. However every Cisco
>> SFP we've tried always spits back an error message:
>>
>> Switch#
>>
>> *Dec  6 19:48:30.448: %PHY-4-SFP_NOT_SUPPORTED: The SFP in Te0/1 is not
>> supported
>>
>> *Dec  6 19:48:30.448: %PM-4-ERR_DISABLE: gbic-invalid error detected on
>> Te0/1, putting Te0/1 in err-disable state
>>
>> Switch#
>>
>>
>> Has anyone had any success with trying to use these on this platform?
>>  Fiber based SFPs are fine so long as they're Cisco branded.  Are there
>> different versions of GLC-T that we may have the wrong type?
>>
>> Thanks.
>>
>> Jose
>> ___
>> 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] Copper SFP with ME3600X

[Tóth András]

Given that this is a 1G in a 10G port, you might need to add "speed 1000"
to the interface config?

Best regards,
Andras


On Mon, Dec 10, 2012 at 8:12 PM, Lobo  wrote:

> Hi everyone.  Been having a hard time trying to get a copper SFP to work
> on our ME-3600X-24TS-Ms.  According to Cisco documentation, the GLC-T SFP
> is supposed to be supported on one of the fiber ports. However every Cisco
> SFP we've tried always spits back an error message:
>
> Switch#
>
> *Dec  6 19:48:30.448: %PHY-4-SFP_NOT_SUPPORTED: The SFP in Te0/1 is not
> supported
>
> *Dec  6 19:48:30.448: %PM-4-ERR_DISABLE: gbic-invalid error detected on
> Te0/1, putting Te0/1 in err-disable state
>
> Switch#
>
>
> Has anyone had any success with trying to use these on this platform?
>  Fiber based SFPs are fine so long as they're Cisco branded.  Are there
> different versions of GLC-T that we may have the wrong type?
>
> Thanks.
>
> Jose
> __**_
> 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] Multiple flow-masks

[Tóth András]

Gert,

As far as I know it's not on the roadmap for Sup720 but will be available
for Sup2T with Flexible Netflow. In Sup2T FNF you can also have
per-interface flowmask for Netflow.

Best regards,
Andras


On Mon, Dec 10, 2012 at 2:03 PM, Gert Doering  wrote:

> Hi,
>
> On Mon, Dec 10, 2012 at 01:50:04PM +0100, Tóth András wrote:
> > The reason you start seeing a conflict as soon as you enable mls flow
> ipv6
> > is that IPv6 Netflow can only be enabled globally, not per-interface.
>
> Which is actually an interesting topic on its own.  It used to be that
> way for IPv4 Netflow, too, but later the code was changed to make that
> per-interface (and it seems to really do that at flow collection time,
> not only at flow-export time - so it helps TCAM contention if netflow
> collection doesn't have to be on on all interfaces).
>
> Now the $5M question - is the hardware capable of doing IPv6 per-interface
> netflow, and if yes, is this on Cisco's roadmap?  For the Sup720, or
> only for the Sup2T?
>
> (I'm more curious about the details, and not going to rant either way...)
>
> gert
> --
> USENET is *not* the non-clickable part of WWW!
>//
> www.muc.de/~gert/
> Gert Doering - Munich, Germany
> g...@greenie.muc.de
> fax: +49-89-35655025
> g...@net.informatik.tu-muenchen.de
>
___
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] Multiple flow-masks

[Tóth András]

Robert,

I was trying on 12.2(33)SXJ2 but that shouldn't cause a difference. I think
you are not seeing the conflict because netflow (ip flow ingress) is not
enabled on your interface now.

The reason you start seeing a conflict as soon as you enable mls flow ipv6
is that IPv6 Netflow can only be enabled globally, not per-interface. If
you disable ipv6 on the interface by removing the 'ipv6 enable' command,
the conflict will be resolved.

With IPv4, you can disable NDE/Netflow on the interface level, so you can
avoid a conflict by using dest-only mask for QoS and disabling netflow on
that interface only. However as soon as you enable IPv6 netflow, it applies
globally and you'll get a conflict (which I believe will only affect IPv6
traffic) due to the fact that you use a QoS mask for microflow policer
other than 'full'.

The syslog message will not tell you if it was v4 or v6 causing the
conflict, but sh fm fie interface reveals it, example from my device:
 Flowmask conflict status for protocol IP : FIE_FLOWMASK_STATUS_SUCCESS
 Flowmask conflict status for protocol OTHER : FIE_FLOWMASK_STATUS_SUCCESS
 Flowmask conflict status for protocol IPV6 : FIE_FLOWMASK_STATUS_FAIL

Best regards,
Andras


On Mon, Dec 10, 2012 at 10:48 AM, Robert Williams wrote:

>  Hi Andras,
>
> Thanks for that – very strange as I do see different behaviour,
> specifically it works 100% fine with IPv4 NDE and my policy enabled.
>
> What IOS are you running?
>
> I’ve used that command and confirmed that I don’t see any conflicts unless
> the command mls flow ipv6 full is enabled.
>
> mls ipv6 acl compress address unicast
> mls netflow interface
> mls flow ip interface-destination-source
> mls nde sender
> mls qos
>
> My policy is using:
>  police flow mask dest-only 2 512000 conform-action transmit
> exceed-action drop
>
> And the interface is:
>  ip access-group 121 in
>  no ip redirects
>  no ip proxy-arp
>  speed nonegotiate
>  ipv6 enable
>  ipv6 nd ra suppress
>  no ipv6 redirects
>  arp timeout 300
>  spanning-tree bpdufilter enable
>  service-policy input Inbound-Transit
>
> Other info:
> # sh fm fie int gi3/16
> Interface Gi3/16:
> Feature interaction state created: Yes
>  Flowmask conflict status for protocol IP : FIE_FLOWMASK_STATUS_SUCCESS
>  Flowmask conflict status for protocol OTHER : FIE_FLOWMASK_STATUS_SUCCESS
>  Flowmask conflict status for protocol IPV6 : FIE_FLOWMASK_STATUS_SUCCESS
> Interface Gi3/16 [Ingress]:
>  Slot(s) using the protocol IP : 1
>  FIE Result for protocol IP : FIE_SUCCESS_NO_CONFLICT
>  Features Configured : RACL   - Protocol : IP
>  FM Label when FIE was invoked : 23
>  Current FM Label : 23
>  Last Merge is for slot: 0
>  Features in Bank2 = RACL
> +-+
> Action Merge Table
> +-+
>RACL RSLTR_RSLT  COL
> +-+
>L2R  L2R P   0
>SB   HB  P   0
>HB   HB  P   0
>L3D  L3D L3D 0
>PP   P   0
> +-+
>  num# of strategies tried : 1
>  Description of merging strategy used:
>   Serialized Banks: FALSE
>   Bank1 Only Features: [empty]
>   Bank2 Only Features: [empty]
>   Banks Swappable: TRUE
>  Merge Algorithm: ODM
>   num# of merged VMRs in bank 1 = 0
>   num# of free TCAM entries in Bank1 = 32652
>   num# of merged VMRs in bank 2 = 12
>   num# of free TCAM entries in Bank2 = 32732
>  Slot(s) using the protocol OTHER : 1
>  FIE Result for protocol OTHER : FIE_SUCCESS_NO_CONFLICT
>  Features Configured : OTH_DEF   - Protocol : OTHER
>  FM Label when FIE was invoked : 23
>  Current FM Label : 23
>  Last Merge is for slot: 0
>  Features in Bank2 = OTH_DEF
> +-+
> Action Merge Table
> +-+
>OTH_DEF  RSLTR_RSLT  COL
> +-+
>SB   HB  P   0
>XP   P   0
> +-+
>  num# of strategies tried : 1
>  Description of merging strategy used:
>   Serialized Banks: FALSE
>   Bank1 Only Features: [empty]
>   Bank2 Only Features: [empty]
>   Banks Swappable: TRUE
>  Merge Algorithm: ODM
>   num# of merged VMRs in bank 1 = 0
>   num# of free TCAM entries in Bank1 = 32682
>   num# of merged VMRs in bank 2 = 1
>   num# of free TCAM entries in Bank2 = 32741
>  Slot(s) using the protocol IPV6 : 1
>  FIE Result for protocol IPV6 : FIE_SUCCESS_NO_CONFLICT
>  Features Configured : [empty] - Protocol : IPV6
>  FM Label when FIE was invoked : 23
>  Current FM Label : 23
>  Last Merge is for slot: 0
>  num# of strategies tried : 1
>   num# of merged VMRs in bank 1 = 0
>   num# of free TCAM entries in Bank1 = Unknown
>   num# of merged VMRs in bank 2 = 1
>   num# of free TCAM entries in Bank2 = Unknown
> Interface Gi3/16 [Egress]:
>  No Features Configured
> No IP Guar

Re: [c-nsp] Multiple flow-masks

[Tóth András]

Hi Robert,

Thanks for the clarification. What I meant is that QoS microflow policy
which needs to have full-flow mask, otherwise you might likely have a
conflict with NDE. I understand that it's a requirement for you to have
destination based policing.
In addition to that, if the NDE flowmask is interface-full-flow, it will
not work with QoS microflow policing.

Try configuring the following:
mls flow ip interface-destination-source
mls flow ipv6 full

policy-map test-policy
  class class-default
 police flow mask full-flow 2 512000 conform-action transmit
exceed-action drop

This should work but this will use full-flow mask for the QoS.

Best regards,
Andras


On Sun, Dec 9, 2012 at 4:36 PM, Robert Williams wrote:

>  Hi Andras,
>
> Many thanks for that – sorry the outputs were misleading but I have
> already tried all 6 variants of the mls flow ipv6 <…> command, including
> "mls flow ipv6 full" – they all produce the same results, culminating in
> the %FM-2-FLOWMASK_CONFLICT error.
>
> I have removed all other policies off the device to rule them out, so a
> clean test / demonstration of the issue is as follows:
>
> mls commands currently set:
>
> mls ipv6 acl compress address unicast
> mls netflow interface  <- (there is no non-interface
> version of this command)
> mls nde sender
> mls qos
> mls flow ip interface-destination-source   <- (there is no version of this
> command which doesn’t include the ‘interface’ keyword for ipv4)
> mls flow ipv6 full
>
> flow commands currently set:
>
> ip flow-export source xx
> ip flow-export version 9
> ip flow-export destination x.x.x.x 
> ip flow-top-talkers
>
>
> With all the above in place, I do get the Full Flow mask as you say:
>
>   IPv6:   0   reservednone
>   IPv6:   1   Full FloFM_IPV6_GUARDIAN
>   IPv6:   2   Null
>   IPv6:   3   reservednone
>
> Plus there is a space in slot 2 - however, when I try to apply my policy:
>
> policy-map test-policy
>   class class-default
> police flow mask dest-only 2 512000 conform-action transmit
> exceed-action drop
>
> interface xx
>  service-policy input test-policy
>
> I still get: %FM-2-FLOWMASK_CONFLICT: Features configured on interface xx
> have conflicting flowmask requirements, traffic may be switched in software
>
> My policy has to be destination based so I cannot change that, but apart
> from that I think I'm trying what you are describing, but my apologies if
> I'm still missing the point!
>
> Cheers!
>
>
> From: Tóth András [mailto:diosbej...@gmail.com ]
> Sent: 09 December 2012 14:47
> To: Robert Williams
> Cc: cisco-nsp NSP
> Subject: Re: [c-nsp] Multiple flow-masks
>
> The outputs you pasted suggests that you're using "interface-full"
> flowmask. The workaround is to use "full" flowmask instead of
> "interface-full" as mentioned in my last email. IPv6 entries consume more
> TCAM space than IPv4, so comparing them should take this fact into account.
>
> Best regards,
> Andras
>
> On Sun, Dec 9, 2012 at 2:52 PM, Robert Williams 
> wrote:
> Hi,
>
> Thanks very much for that, I’ll have to run through everything in that
> document because the tests I’m doing suggest that it ‘should’ work, for
> example:
>
> With both my policy and the mls ipv6 flow interface-full disabled I see
> one entry, which is presumably because ‘mls qos’ is enabled:
>
>   IPv6:   1   Intf FulFM_IPV6_QOS
>   IPv6:   2   Null
>
> Then if I enable only “mls ipv6 flow interface-full”, the FM_IPV6_GUARDIAN
> ‘feature’ appears:
>
>   IPv6:   1   Intf FulFM_IPV6_GUARDIAN FM_IPV6_QOS
>   IPv6:   2   Null
>
> As you can see there is still a gap for the policy to take the second flow
> mask and use whatever type of mask it wants.
>
> As a test - if I disable the ipv6 flow and just enable my policy by
> itself, it goes in the second slot correctly - and uses the Destination
> Only mask:
>
>   IPv6:   1   Intf FulFM_IPV6_QOS
>   IPv6:   2   Dest onlFM_IPV6_QOS
>
> So, I was assuming that a combination of these two features would be
> acceptable to it, since they operate in different mask slots when enabled
> separately anyway I didn’t see why they should collide.
>
> I am correct as far as its operation in IPv4 goes because for v4 there is
> no conflict warning (and the policy works in hardware perfectly!). However,
> in IPv6 that does not appear to be the case.
>
> Looks like yet another unhappy IPv6 feature on the Sup-720, unless any

Re: [c-nsp] Multiple flow-masks

[Tóth András]

The outputs you pasted suggests that you're using "interface-full"
flowmask. The workaround is to use "full" flowmask instead of
"interface-full" as mentioned in my last email. IPv6 entries consume more
TCAM space than IPv4, so comparing them should take this fact into account.

Best regards,
Andras


On Sun, Dec 9, 2012 at 2:52 PM, Robert Williams wrote:

>  Hi,
>
> Thanks very much for that, I’ll have to run through everything in that
> document because the tests I’m doing suggest that it ‘should’ work, for
> example:
>
> With both my policy and the mls ipv6 flow interface-full disabled I see
> one entry, which is presumably because ‘mls qos’ is enabled:
>
> IPv6:   1   Intf Ful*FM_IPV6_QOS*
> IPv6:   2   Null
>
> Then if I enable only “*mls ipv6 flow interface-full*”, the
> FM_IPV6_GUARDIAN ‘feature’ appears:
>
> IPv6:   1   Intf Ful*FM_IPV6_GUARDIAN* *FM_IPV6_QOS*
> IPv6:   2   Null
>
> As you can see there is still a gap for the policy to take the second flow
> mask and use whatever type of mask it wants.
>
> As a test - if I disable the ipv6 flow and just enable *my policy** *by
> itself, it goes in the second slot correctly - and uses the Destination
> Only mask:
>
> IPv6:   1   Intf Ful*FM_IPV6_QOS*
> IPv6:   2   Dest onl*FM_IPV6_QOS*
>
> So, I was assuming that a combination of these two features would be
> acceptable to it, since they operate in different mask slots when enabled
> separately anyway I didn’t see why they should collide.
>
> I am correct as far as its operation in IPv4 goes because for v4 there is
> no conflict warning (and the policy works in hardware perfectly!). However,
> in IPv6 that does not appear to be the case.
>
> Looks like yet another unhappy IPv6 feature on the Sup-720, unless anyone
> can see a way around it that I’m missing?
>
> As an aside, does anybody know why it is called *FM_IPV6_GUARDIAN*instead of
> *FM_IPV**6**_QOS* (like in v4)? I’m wondering if this difference is the
> reason for its inability to combine the two masks successfully…
>
> Cheers!
>
> *From:* Tóth András [mailto:diosbej...@gmail.com ]
> *Sent:* 08 December 2012 21:09
> *To:* Robert Williams
> *Cc:* cisco-nsp NSP
> *Subject:* Re: [c-nsp] Multiple flow-masks
>
> Hi Robert,
>
> A few things to keep in mind.
>
> With Release 12.2(33)SXI4 and later releases, when appropriate for the
> configuration of the policer, microflow policers use the interface-full
> flow mask, which can reduce flowmask conflicts. Releases earlier than
> Release 12.2(33)SXI4 use the full flow mask.
>
> The flowmask requirements of QoS, NetFlow, and NetFlow data export (NDE)
> might conflict, especially if you configure microflow policing.
>
> *
> http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/qos.html
> *<http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/qos.html>
>
> To add to this, note the following restrictions/recommendations well:
>
> The micro-flow policing full flow mask is compatible with NDE’s flow masks
> that are shorter than or equal to full flow (except for destination source
> interface).
> With any micro-flow policing partial mask an error message is displayed
> and either the micro-flow policer or NDE might get disabled.
>
> Best regards,
> Andras
>
>
> On Sat, Dec 8, 2012 at 3:50 PM, Robert Williams 
> <*rob...@custodiandc.com*>
> wrote:
> Hi,
>
> Unfortunately we use Netflow for an automated system we have (it doesn't
> need to accurately record everything, just the highest number of flows /
> packets etc). So I cannot just remove it, however I have made some progress.
>
> I've tracked it down to the problem actually being with the IPv6 netflow /
> masks. With all netflow removed I am able to add my policy-map in and it
> works. Then by adding netflow commands back in I can get everything back
> except the command:
>
>  mls flow ipv6 
>
> So even if I specify:
>
>  mls flow ipv6 destination
>
> I still get:
>
> %FM-2-FLOWMASK_CONFLICT: Features configured on interface  have
> conflicting flowmask requirements, traffic may be switched in software
>
> At this point in time, with my policy attached and working I'm showing:
>
>  Flowmasks:   Mask#   TypeFeatures
>   IPv4:   0   reservednone
>   IPv4:   1   Intf FulFM_QOS Intf NDE L3
> Feature
>   IPv4:   2   Dest onlFM_QOS <---
> My policy (V4)
>   IPv4:   3   reservednone
>
>  

Re: [c-nsp] IPv6 weirdness

[Tóth András]

Try tracing down further things on the next occurence, such as checking
Vlan interface status, gathering ipv6 nd table 'sh ipv6 neighbors', and 'sh
mac address-table' to see where those MACs are pointing to.

Andras


On Sun, Dec 9, 2012 at 3:03 PM, Randy  wrote:

> On 12/08/2012 6:59 pm, Dobbins, Roland wrote:
>
>> On Dec 9, 2012, at 9:26 AM, Randy wrote:
>>
>>  Rogue RA?
>>>
>>
>> That was actually my first thought.  Is this an access VLAN in a
>> customer colo (real or virtual) environment?
>>
>
> It's a colo cabinet full of unmanaged VM's bridged onto the VLAN so it's
> conceivable they could have done just about anything.  IPv4 continued to
> function normally but I guess someone was able to either disable or steal
> the v6 GW.
>
> --
> ~Randy
>
> __**_
> 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] Making SUP720 cope better under BGP load

[Tóth András]

Adrian,

Inband channel (link to CPU) is a 1GE full-duplex link in both Sup720 and
Sup2T.

Best regards,
Andras


On Sun, Dec 9, 2012 at 10:25 AM, Adrian Minta wrote:

> On 12/09/12 07:10, Andrew Jones wrote:
>
>> Sup720 cpu is around 600mhz if i remember correctly, whilst sup2t is 1.5
>> ghz dual core, so one would sup2t would handle this much better. Also,
>> sup2t has much better CoPP capability with built in default config
>> templates, ready for you to tune if needed.
>>
>>
>>  The CPU network interface is still 10mbps half duplex ?
>
> --
> Best regards,
> Adrian Minta
>
>
>
> __**_
> 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] OSPFv3 Adjacency issues between 2921 and 3750

[Tóth András]

Hi Peter,

I would also suggest upgrading to 12.2(55)SE6, that should work.

Note that if the switch has not joined the FF02::5 group address, you'll
not see the packets destined to ff02::5 in 'debug ipv6 icmp' output. You
can check this with 'sh ipv6 int ' command.

Best regards,
Andras


On Fri, Dec 7, 2012 at 3:59 PM, Gabor Ivanszky wrote:

> Hi Peter,
>
> I've seen the same phenomenon on 12.2(50)SE3.
> After upgrading to 12.2(55)SE6, OSPFv3 started to work(adjacency
> FULL-FULL and stable)
> However ping to ff02::5 still doesn't work.
>
> regards,
> Gabor
>
> On Tue, Jul 3, 2012 at 1:01 PM, Peter Subnovic
>  wrote:
> > Hi Peter,
> >
> > thank you for your suggestion. Unfortunately QoS is disabled on the 3750.
> >
> > 3750#show mls qos
> > QoS is disabled
> > QoS ip packet dscp rewrite is enabled
> >
> > 3750#show mls qos interface g1/0/24
> > GigabitEthernet1/0/24
> > QoS is disabled.
> >
> > Kind regards,
> > Peter
> >
> > On Tue, Jul 3, 2012 at 1:49 PM, Peter Rathlev  wrote:
> >
> >> On Tue, 2012-07-03 at 05:43 -0400, Chuck Church wrote:
> >> > Long shot, but don't the 3750s have a certain SDM they need enabled to
> >> use
> >> > IPv6?
> >>
> >> And on that note, what about MLS QoS on the 3750? I seem to recall
> >> having debugged something that turned out to be much (all?) IPv6 traffic
> >> ending up in queue 3 or 4, and we have set buffer sizes for these to 0.
> >> Does "no mls qos" make any difference? (If it's enabled of course.)
> >>
> >> --
> >> 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/
>
___
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] IPv6 weirdness

[Tóth András]

The first case shows /64 while the second is /128 as John pointed out as
well. Perhaps the Vlan interface (SVI) was in down state, therefore the
router did not have the /128 receive entry and the address was covered by a
"backup" /64 static route instead.

Did you do a 'sh int vlan x" before doing a shut/no shut? Anything in the
logs?

Best regards,
Andras


On Fri, Dec 7, 2012 at 11:04 PM, Randy  wrote:

> User complained his ipv6 gw on his vlan interface was down.  On checking,
> I couldn't ping it either from the local router.
>
> This looked interesting to me on a sh ipv6 route for the gw IP (note
> 'backup from...' line):
>
> rtr1.ash#sh ipv6 route x:x:x:6::1
> Routing entry for x:x:x:6::/64
>   Known via "connected", distance 0, metric 0, type connected
>   Backup from "static [1]"
>   Route count is 1/1, share count 0
>   Routing paths:
> directly connected via VlanXX
>   Last updated 7w0d ago
>
> After shut/no shut the interface now it's normal and pingable again:
>
> router#sh ipv6 route x:x:x:6::1
> Routing entry for x:x:x:6::1/128
>   Known via "connected", distance 0, metric 0, type receive
>   Route count is 1/1, share count 0
>   Routing paths:
> receive via VlanXX
>   Last updated 00:00:01 ago
>
> What are the differences implying on these two outputs?
>
> --
> ~Randy
> __**_
> 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] Multiple flow-masks

[Tóth András]

Hi Robert,

A few things to keep in mind.

With Release 12.2(33)SXI4 and later releases, when appropriate for the
configuration of the policer, microflow policers use the interface-full
flow mask, which can reduce flowmask conflicts. Releases earlier than
Release 12.2(33)SXI4 use the full flow mask.

The flowmask requirements of QoS, NetFlow, and NetFlow data export (NDE)
might conflict, especially if you configure microflow policing.

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/qos.html

To add to this, note the following restrictions/recommendations well:

The micro-flow policing full flow mask is compatible with NDE’s flow masks
that are shorter than or equal to full flow (except for destination source
interface).
With any micro-flow policing partial mask an error message is displayed and
either the micro-flow policer or NDE might get disabled.

Best regards,
Andras



On Sat, Dec 8, 2012 at 3:50 PM, Robert Williams wrote:

> Hi,
>
> Unfortunately we use Netflow for an automated system we have (it doesn't
> need to accurately record everything, just the highest number of flows /
> packets etc). So I cannot just remove it, however I have made some progress.
>
> I've tracked it down to the problem actually being with the IPv6 netflow /
> masks. With all netflow removed I am able to add my policy-map in and it
> works. Then by adding netflow commands back in I can get everything back
> except the command:
>
>  mls flow ipv6 
>
> So even if I specify:
>
>  mls flow ipv6 destination
>
> I still get:
>
> %FM-2-FLOWMASK_CONFLICT: Features configured on interface  have
> conflicting flowmask requirements, traffic may be switched in software
>
> At this point in time, with my policy attached and working I'm showing:
>
>  Flowmasks:   Mask#   TypeFeatures
>   IPv4:   0   reservednone
>   IPv4:   1   Intf FulFM_QOS Intf NDE L3
> Feature
>   IPv4:   2   Dest onlFM_QOS <---
> My policy (V4)
>   IPv4:   3   reservednone
>
>   IPv6:   0   reservednone
>   IPv6:   1   Intf FulFM_IPV6_QOS
>   IPv6:   2   Dest onlFM_IPV6_QOS<---
> My policy (V6)
>   IPv6:   3   reservednone
>
> The command "mls flow ipv6 " just plain refuses to go active in
> the config, so if I re-send it I get the error shown above every time.
>
> The flowmasks are correctly showing "Intf Full" and "Dest only" in slots 1
> and 2 respectively. So, why does my netflow request not attach alongside
> either one of them when it's looking for the same mask as is already active
> in those slots?
>
> The policy itself is working correctly at this point, but I cannot enable
> IPv6 netflow.
>
> Can anyone help?
>
> Robert Williams
> Backline / Operations Team
> Custodian DataCentre
> tel: +44 (0)1622 230382
> email: rob...@custodiandc.com
> http://www.custodiandc.com/disclaimer.txt
>
>
>
> ___
> 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] Ping with vrf intermittent but ping mpls normal

[Tóth András]

Hi Nanda,

Maybe you have multiple paths between the source and destination? Like
etherchannel or Layer-3 ECMP (route with multiple nexthops on different
links)? That would explain this, possibly the MPLS ping and ping to
Loopback is taking one link, while the previous ping vrf takes a different
one and that link might have some errors on it.

I'd suggest to check the following commands along the path on all possible
physical interfaces both inbound and outbound.
sh interface 
sh int  counters error
sh counters error
sh interface  transceiver detail
sh platform port-asic stats drop  (this only works on the 3750)

Best regards,
Andras


On Sat, Dec 8, 2012 at 2:42 AM, nanda pradana ramadhan putra <
animusa...@gmail.com> wrote:

> Hi Oliver,
>
>
> The topology like this JKT-PAJAK-C3750-UPE-01 - MPLS CLOUD
> - JATENG-UNGARAN-R7606-NPE-01 - JATENG-GI.RAWALO-R3845-UPE-01
> The ping is just from gateway vrf on pajak to gateway vrf on rawalo the
> result is always have RTO on it. But ping vrf from pajak to ungaran the
> result is OK. The user on pajak said that they always have packet loss when
> trying to reach user on rawalo. I've investigated it and created new vrf on
> rawalo but the result still same RTO always occur. the other issue when i
> ping using all vrf on rawalo to the other remote site is always RTO. Can be
> it caused by transmission problem? ungaran is upstream path for rawalo.
> Ping p2p interface from ungaran to rawalo always good. The connection is
> using L2DWDM broadcast.
>
> if it caused by ICMP limiter what kind of CoPP that jusl limit icmp ping
> just on vrf? but user also have rto i think it is not caused by CoPP
>
> i try to without mpls just ping using its loopback the result is smooth
> rather ping vrf
>
> JKT-PAJAK-C3750-UPE-01#ping 202.162.222.241 repeat 1000
>
> Type escape sequence to abort.
> Sending 1000, 100-byte ICMP Echos to 202.162.222.241, timeout is 2 seconds:
> !!
> !!
> !!
> !!
> !!
> !!
> !!
> !!
> !!
> !!
> !!
> !!
> !!
> !!
> 
> Success rate is 100 percent (1000/1000), round-trip min/avg/max = 8/15/118
> ms
>
> Thanks,
> Nanda
>
> On Sat, Dec 8, 2012 at 4:08 AM, Oliver Boehmer (oboehmer) <
> oboeh...@cisco.com> wrote:
>
> >
> >
> > >
> > >i have problem here with ping vrf, when i do ping vrf there is always
> > >packet drop but when i ping using mpls it seems normal. is there some
> > >strange here? i do tracing ping p2p and the result is ok too, but why if
> > >do
> > >ping vrf always have a packet drop
> >
> > you might run into an ICMP rate limiter at the destination (like CoPP or
> > something), which is not effective for MPLS ping (as it isn't based on
> > ICMP)?
> >
> > oli
> >
> >
> >
> ___
> 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] Ping with vrf intermittent but ping mpls normal

[Tóth András]

Hi,

I don't think it has anything to do with the fact that you have VRF, try
removing the VRF configuration on both sides, then do a ping and compare
the results.
Do you see packet loss if traffic is transiting the device and not sent
between the switch and gateway, rather between two servers or laptops
instead?
Try doing a packet capture on the other end which you're pinging to
identify the direction of the loss.

Best regards,
Andras


On Fri, Dec 7, 2012 at 8:02 PM, nanda pradana ramadhan putra <
animusa...@gmail.com> wrote:

> hi
>
> i have problem here with ping vrf, when i do ping vrf there is always
> packet drop but when i ping using mpls it seems normal. is there some
> strange here? i do tracing ping p2p and the result is ok too, but why if do
> ping vrf always have a packet drop
>
>
> JKT-PAJAK-C3750-UPE-01#ping vrf VPN_PAJAK_HO 192.168.51.189 repeat 1000
>
> Type escape sequence to abort.
> Sending 1000, 100-byte ICMP Echos to 192.168.51.189, timeout is 2 seconds:
> !!
> !!
> !!
> !!
> !!
> !!
> !!
> !!
> !!
> !!
> !!.!!!
> !!
> !!
> !!
> 
> Success rate is 99 percent (999/1000), round-trip min/avg/max = 8/17/118 ms
> JKT-PAJAK-C3750-UPE-01#ping mpl
> JKT-PAJAK-C3750-UPE-01#ping mpls ip
> JKT-PAJAK-C3750-UPE-01#ping mpls ipv4 202.162.222.241/32 repea
> JKT-PAJAK-C3750-UPE-01#ping mpls ipv4 202.162.222.241/32 repeat 1000
> Sending 1000, 100-byte MPLS Echos to 202.162.222.241/32,
>  timeout is 2 seconds, send interval is 0 msec:
>
> Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
>   'L' - labeled output interface, 'B' - unlabeled output interface,
>   'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
>   'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
>   'P' - no rx intf label prot, 'p' - premature termination of LSP,
>   'R' - transit router, 'I' - unknown upstream index,
>   'X' - unknown return code, 'x' - return code 0
>
> Type escape sequence to abort.
> !!
> !!
> !!
> !!
> !!
> !!
> !!
> !!
> !!
> !!
> !!
> !!
> !!
> !!
> 
> Success rate is 100 percent (1000/1000), round-trip min/avg/max = 16/17/135
> ms
>
>
> 192.168.51.189 = ip gateway vpn on the other side (drop on device that have
> ip lo0 202.162.222.241)
>
>
> Thanks,
> ___
> 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] UCS blade internal vlan fixed range ??

[Tóth András]

Hi Jeffrey,

You can use vlan 4048 and 4049 as described on the links below but the
other vlans are reserved and their allocation cannot be changed.

https://supportforums.cisco.com/thread/2148709

http://www.cisco.com/en/US/docs/unified_computing/ucs/sw/gui/config/guide/2.0/b_UCSM_GUI_Configuration_Guide_2_0_chapter_01.html

Best regards,
Andras


On Thu, Dec 6, 2012 at 5:48 PM, Jeffrey G. Fitzwater wrote:

> We are looking at using the CISCO UCS blades but we have a problem with
> the vlan ID we have in use not available on the UCS blade.
>
> Is there any way to change the internal VLAN range (3968 to 4048) that is
> fixed in in the USC blade code?
>
> They fixed this problem for the NX-OS to allow it to be user defined so
> there is no conflict with existing vlan ID a customer may already be using.
>
>
>
> Thanks for any help.
>
>
>
> Jeff Fitzwater
> OIT Network Systems
> Princeton University
> ___
> 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] SPAN destinations on ME3600/15.3(1)S

[Tóth András]

Hi Jason,

The ME3600 supports SPAN/RSPAN/ERSPAN apparently. The destination interface
can be physical only indeed.

ME3600X(config)#monitor session 1 type ?
  erspan-destination  Encapsulated RSPAN Destination Session
  erspan-source   Encapsulated RSPAN Source Session
  local   Local SPAN Session
  local-txLocal SPAN Session TX only
  rspan-destination   RSPAN Destination Session
  rspan-sourceRSPAN Source Session

ME3600X(config-mon-local)#destination interface ?
  GigabitEthernet GigabitEthernet IEEE 802.3z
  Port-channelEthernet Channel of interfaces
  TenGigabitEthernet  Ten Gigabit Ethernet

Best regards,
Andras


On Fri, Nov 30, 2012 at 4:06 PM, Jason Lixfeld  wrote:

> The long awaited 15.3 release is here and it finally brings SPAN to the
> ME3600.
>
> Looking through the documentation though, it appears as though a SPAN
> destination can only be a physical interface and not a pseudowire.  Is that
> actually true or is that just lacking documentation?
>
> --
>
> Sent from my mobile device
> ___
> 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] QoS (dscp-to-exp mutation) on Sup-2T/Cat6500

[Tóth András]

Hi Alex,

The command is hidden, as far as I know because it is not supported and
replaced by "table-maps". If you press enter after "platform qos map" it
will say incomplete command, so it's still there but hidden.

You could use the "table-map" command instead and "show table-map" to
verify the config. Details in the guide below:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/15.0SY/configuration/guide/qos_global_and_if.html

Best regards,
Andras


On Thu, Nov 29, 2012 at 3:45 PM, Alex K.  wrote:

> Hi All,
>
> I ran into interesting issue on Sup-2T. As you probably know, QoS CLI is
> changed on this new supervisor. I'm looking to translate incoming
> dscp-marked packets, into exp-marked on egress.
> Now, according to documentation - Catalyst 6500 Release 15.0SY Software
> Configuration Guide<
> http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/15.0SY/configuration/guide/15_0_sy_swcg.html
> >-
> this functionality is still called mutation-map and is configured
> under
> 'platform qos map exp-mutation'. The problem is quite simple – there is no
> 'platform qos map exp-mutation' on 2 different machines I checked upon.
> Here:
>
> Some-6513(config)#platform qos ?
>   10g-only qos pure 10G mode
>   aggregate-policer Named aggregate policer
>   marking marking keyword
>   police police keyword
>   protocol protocol keyword
>   queueing-only queueing-only (no QoS rewrite, no policing)
>   rewrite packet qos rewrite enable/disable
>   statistics-export qos statistics data export
>
>
> What do you think I'm missing?
>
> Alex.
> ___
> 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] URPF MAC check

[Tóth András]

I don't see the benefit because L2 address is only visible until your
next-hop, it does not validate the original sender which might be several
hops away. Also, MAC addresses are easily spoofable.

DoS attacks? Most often come from a spoofed source IP, so why wouldn't they
spoof the MAC as well (in case it's a DoS coming from a directly connected
network)? If coming from directly connected network, you can just consult
netflow/interface stats to see where is it coming from.

Additionally this would break HSRP which is certainly not common in IX
environments, but in theory having the virtual MAC in your ARP table would
cause legitimate traffic coming from the physical MAC being dropped.

Andras


On Fri, Nov 23, 2012 at 12:15 PM, Aled Morris  wrote:

> On 23 November 2012 11:06, Dobbins, Roland  wrote:
>
> >
> > On Nov 23, 2012, at 5:49 PM, Aled Morris wrote:
> >
> > > It would be handy if URPF could use both the L3 FIB (as it does now)
> and
> > the L2 ARP table to validate source addressess
> >
> > I guess I don't understand what you mean by this . . .
> >
> > Regarding some combination of layer-2 and layer-3, how would your box
> have
> > prior knowledge of what path(s) packets are going to take through the
> > Internet to reach the given interface on your box?
> >
>
> When URPF has a packet, it checks the L3 forwarding table to get the L3
> next hop for the given packet's source IP address.
>
> What I'm suggesting is that it would then use the ARP table for that L3
> next hop IP address to further validate the packet in hand.
>
> Does that explain what I am trying to ask for?
>
> Aled
> ___
> 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] High CPU: punted packets

[Tóth András]

Hi,

Dest Index 0x380 means the traffic is punted to the RP CPU. That can be due
to several reasons, such as various exceptions, or simply because traffic
is destined to the switch.

The all-0 src mac seems strange. I would recommend doing a full packet
capture of the interface where this is coming from to see how the packets
look like. Maybe they're corrupted, or have IP Options which require
punting. You could try configuring 'ip options drop' as well.

Any fancy thing on the ingress port or the destination port (where traffic
should be sent based on dest IP), or the Vlan interface? Things like uRPF,
ACL, Netflow, PBR, Tunneling, etc? Try turning these off to see if there's
any improvement.

Best regards,
Andras


On Thu, Nov 22, 2012 at 8:49 AM, Saku Ytti  wrote:

> On (2012-11-22 09:50 +0700), Jefri Abdullah wrote:
>
> > --- dump of incoming inband packet ---
> > interface NULL, routine mistral_process_rx_packet_inlin, timestamp
> > 10:21:58.298
> > dbus info: src_vlan 0x402(1026), src_indx 0x342(834), len 0x5D(93)
> >   bpdu 0, index_dir 0, flood 0, dont_lrn 0, dest_indx 0x380(896)
> >   2D020C01 0402 0342 5D00 0011 2000 
> > 0380
> > mistral hdr: req_token 0x0(0), src_index 0x342(834), rx_offset
> > 0x76(118)
> >   requeue 0, obl_pkt 0, vlan 0x402(1026)
> > destmac 00.24.C4.C0.0B.40, srcmac 00.00.00.00.00.00, protocol 0800
> > protocol ip: version 0x04, hlen 0x05, tos 0xBA, totlen 75, identifier 0
> >   df 0, mf 0, fo 0, ttl 61, src *.*.*.*, dst *.*.*.*
> >   udp src 20868, dst 19342 len 55 checksum 0xA915
> >
> > We've no idea why the incoming interface is NULL, and why this packet
> > is punted. Do you guys have any clue about this?
>
> Clue here is 'dest_indx', we can determine this is not interface LTL index
> as
> 0x380.divmod(64) gives 14,0 and we don't have 15 slots.
>
> You can do 'remote command switch show platform hardware tycho register 0
> 1794
> | i 000380' to see potential reasons for punt.
>
> On my box, I see:
> 
>  0x017F:PP_RF_SRC_IDX0 = 0x0380 [896   ]
>  0x03C4:RED_SW_ERR_IDX = 0x0380 [896   ]
>  0x0456:RED_FINRST_IDX = 0x0380 [896   ]
>  0x045B:  RED_IPV6_SCP_IDX = 0x0380 [896   ]
> ---
>
> I happen to know from heart that one reason for 380 is MTU-failure, while
> it is
> not obvious from above. If there is some way to know for sure which of
> those
> registers the punt is hitting, I don't know it, but would love to hear.
>
> But as you're having very small frame, I doubt it is MTU-failure. I'm
> pretty
> much out of ideas. You could verify it's not URPF, but I think URPF is
> using
> different index. (Just because uRPF is not now configured in interface in
> CLI,
> does not mean uRPF/strict isn't dropping your frames)
>
> If you can reliably produce it and measure via ping, you could try setting
> mls
> rate-limites to 10/10 one by one, to see exactly which one it is hitting,
> it
> could give more data.
>
> --
>   ++ytti
> ___
> 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] loose uRPF on Sup720/3B

[Tóth András]

Hi Gert,

Note that although uRPF is done in hardware, a certain number of packets
will be punted to the CPU, which can be rate-limited with the 'mls
rate-limit unicast ip rpf-failure' command, details below in "uRPF Check
Failure" section.

By default this is enabled with a non-zero value (100 pps with 10 burst).
Use a value of 0 to avoid packets punted to CPU, however in this case
you'll not see verification statistics in the 'sh ip int' output.

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/dos.html

Best regards,
Andras



On Wed, Nov 14, 2012 at 12:45 PM, Gert Doering  wrote:

> Hi,
>
> consider me confused on the operation of Sup720/3b with "loose uRPF"
> configured.  So far, I thought I understood what it can and can not do:
>
>  - uRPF for IPv4 can be done in hardware
>  - loose or strict mode uRPF is a global setting for the whole box
>
> so I decided to enable loose uRPF on one of our peering/uplink routers
> today, in preparation for BGP-signalled S-RTBH (no customer interfaces
> there
> , no need for strict-mode interfaces):
>
> interface GigabitEthernet1/1
>  ip address 1.2.3.4 255.255.255.0
>  ip access-group 110 in
>  ip verify unicast source reachable-via any allow-default
>  ip flow ingress
> ...
>
> To see what it will do, I turned on "debug ip cef drops rpf", and got
> lots of output - which I didn't expect, as nothing is null-routed yet:
>
> Nov 14 12:33:55: CEF-Drop-Suppress: Packet from 62.176.255.250 via
> GigabitEthernet1/1 -- ip verify check (via-any)
> Nov 14 12:33:55: CEF-Drop: Packet from 62.176.255.250 via
> GigabitEthernet1/1 -- via-rx
> Nov 14 12:33:55: CEF-Drop-Suppress: Packet from 62.176.255.250 via
> GigabitEthernet1/1 -- ip verify check (via-any)
> Nov 14 12:33:55: CEF-Drop: Packet from 62.176.255.250 via
> GigabitEthernet1/1 -- via-rx
> Nov 14 12:33:55: CEF-Drop-Suppress: Packet from 62.176.255.250 via
> GigabitEthernet1/1 -- ip verify check (via-any)
>
> ... now, I can actually ping this address just fine, so it is not dropping,
> and reading between the lines, it tells me so "I would drop, but I
> suppressed
> the dropping":
>
> cisco> show ip int g1/1
> ...
>   Input features: Ingress-NetFlow, Access List, uRPF, MCI Check
> ...
>   IP verify source reachable-via ANY, allow default
>0 verification drops
>34 suppressed verification drops
>0 verification drop-rate
>
> so what is a "suppressed verification drop"?  And, much more important,
> "will it still do that in hardware", or will loose-uRPF ("via any") punti
> it into the software path for "some packets"?
>
> This is on a Sup720/3B with 12.2(33)SXI2, and the amount of
> "suppressed verification drops" is fairly tiny compared to the
> 58403 packets/sec input rate this particular interface has at the
> moment - but I'm still slightly worried...
>
> gert
> --
> USENET is *not* the non-clickable part of WWW!
>//
> www.muc.de/~gert/
> Gert Doering - Munich, Germany
> g...@greenie.muc.de
> fax: +49-89-35655025
> g...@net.informatik.tu-muenchen.de
>
> ___
> 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] Monitoring 3750x power supplies

[Tóth András]

Hi Aaron,

Seems like it's caused by one of the following defects:

CSCtq97867 - SNMP Generating "Faulty" status for Power supply when PS is
inserted

This is fixed in 15.0(2)SE and 12.2(55)SE4.

CSCtx16194 - C3750 stack switches ciscoEnvMonSupplyState returns
notFunctioning (6)

This has not been fixed yet. You can follow bug details on Cisco website.

Best regards,
Andras



On Tue, Nov 13, 2012 at 1:48 AM, Aaron Riemer  wrote:

> Hey guys,
>
>
>
> We are having issues monitoring our 3750x power supplies via the cisco
> envmon MIB that hopefully someone out there has experienced.
>
>
>
> When one of the power supplies loses power the OID will change state to
> 6:notFunctioning but once power is reset the state does not change back to
> normal.
>
>
>
> This is causing issues for our monitoring application.
>
>
>
> See below for the OID:
>
>
>
> Object ciscoEnvMonSupplyState OID 1.3.6.1.4.1.9.9.13.1.5.1.3 Type
> CiscoEnvMonState
> 1:normal
> 2:warning
> 3:critical
> 4:shutdown
> 5:notPresent
> 6:notFunctioning
> Permission read-only Status current MIB
>
> Description The current state of the power supply being instrumented.
>
>
>
> snmpwalk result:
>
>
>
> SNMPv2-SMI::enterprises.9.9.13.1.5.1.3.1058 = INTEGER: 1
>
> SNMPv2-SMI::enterprises.9.9.13.1.5.1.3.1086 = INTEGER: 6
>
>
>
> switch#show env power
>
>
>
> SW  PID Serial# Status   Sys Pwr  PoE Pwr
>  Watts
>
> ---  --  --  ---  ---  ---
> -
>
> 1A  C3KX-PWR-1100WAC OK  Good Good 1100/0
>
> 1B  C3KX-PWR-1100WAC OK  Good Good 1100/0
>
>
>
> Any ideas? I believe a reload of the switch will resolve but we can't do
> this for every switch that loses power to one of the supplies.
>
>
>
> Thanks,
>
>
>
> Aaron.
>
>
>
>
>
> ___
> 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

[Tóth András]

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?method=fetchBugDetails&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.

Upgrading from 5.2(3a) to 5.2(7) can be done using the install all
(ISSU) method.

Best regards

On Tue, Nov 6, 2012 at 11:38 AM, Antonio Soares  wrote:
> Hello group,
>
>
>
> Anyone knows the difference between using the install all script or just
> update the boot system flash command when upgrading NX-OS on a Nexus 7K ?
>
>
>
> The question applies to a single supervisor setup.
>
>
>
> The official documentation mentions the two ways of doing it:
>
>
>
> - using the install all script:
>
>
>
> http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/upgrade/gui
> de/b_Cisco_Nexus_7000_Series_NX-OS_Software_Upgrade_and_Downgrade_Guide__Rel
> ease_5.x_chapter_00.html#con_314241
>
>
>
> - using the traditional procedure:
>
>
>
> http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/upgrade/gui
> de/b_Cisco_Nexus_7000_Series_NX-OS_Software_Upgrade_and_Downgrade_Guide__Rel
> ease_5.x_chapter_00.html#task_39E26688E1204F8CAAE876450A575E73
>
>
>
> I had a bad experience in the past with the install all script. I was doing
> an upgrade to a 7010 with only 1 supervisor that was installed in slot 6.
> The install all script has a problem, may a bug, it only correctly updates
> the boot variables for slot 5:
>
>
>
> boot kickstart bootflash:/n7000-s1-kickstart.5.2.3a.bin sup-1
>
> boot system bootflash:/n7000-s1-dk9.5.2.3a.bin sup-1
>
> boot kickstart bootflash:/n7000-s1-kickstart.5.1.3.bin sup-2
>
>
>
> The install all script assumes that if there is only one supervisor, it
> should be on slot 5. Above we can see that the boot system is missing for
> sup-2.
>
>
>
> In summary, is there any problem if I simply update the boot variables and
> reload ? May I end up with the supervisor running the new NX-OS release and
> the modules the old NX-OS release ?
>
>
>
>
>
> Regards,
>
>
>
> Antonio Soares, CCIE #18473 (R&S/SP)
> amsoa...@netcabo.pt
>
> http://www.ccie18473.net 
>
> ___
> 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] forced up/up on a fiber link

[Tóth András]

Hi,

The "hw-module module  simulate link-up" command will probably help
you. It causes all ports on a specified module to be up/up. It might
require "service internal" too.

http://www.cisco.com/en/US/products/ps6017/products_command_reference_chapter09186a0080882963.html#wp1011675

Best regards,
Andras

On Mon, Oct 22, 2012 at 12:35 PM, LM  wrote:
> Hi all,
>
> For copper ethernet port I know there is an option to force up/up with "no
> keepalive"
>
> But, what about a fiber link?
> I have here a 7606 with...
> "Cisco 7600 Series SPA Interface Processor-400 Rev. 2.5"
> "5-port Gigabit Ethernet Shared Port Adapter"
>
>
> "no keepalive" command available under gi3/2/2, which it is a fiber port on
> the related cards I wrote before.
>
> Now, I need to test a config, and I need to force up/up to one port without
> a fiber connected, is it possible? how?
> I am still doing research but, not success so far.
>
> ___
> 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] Cat 4900M crash

[Tóth András]

Hi Artyom,

I have decoded the crashinfo and you're hitting the following bug:
CSCtn68186 - crash on BGP up when 'ip cef accounting non-recursive' is
configured

This is fixed in 12.2(53)SG5 and 15.0(2)SG and later releases.
Workaround is to disable 'ip cef accounting' which is not supported on
the 4500/4900 platform.

Best regards,
Andras

On Wed, Oct 17, 2012 at 7:38 AM, Artyom Viklenko  wrote:
> Hi, list!
>
> We have cisco WS-C4900M (MPC8548) processor (revision 2)
> with cat4500e-entservicesk9-mz.122-54.SG.bin IOS on it
> at remote location.
>
> It is used to connect to some IXP an have BGP peerings.
> Some strange things happens when techs on IXP perform
> maintenance tasks such as software upgrade on their equipment.
> If they need to reboot their switch our connection terminates on
> our cat 4900m crashes.
>
> The physical port for this connection was replaced.
> IOS was upgraded to cat4500e-entservicesk9-mz.122-54.SG1.bin.
> Nothing changed.
>
> Last lines from log always the same:
>
> %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/5,
> changed state to down
> %LINK-3-UPDOWN: Interface Vlan95, changed state to down
> %LINK-3-UPDOWN: Interface TenGigabitEthernet1/5, changed state to down
> %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan95, changed state to dow
>
> Traceback always the same for corresponding IOS version
>
> Build: 12.2(54)SG1 ENTSERVICESK9
> buildversion addr: 13D50E74
>
> Traceback: 11D21BA0 11D21CD0 11EF5EEC 11EF6958 11EF79F0 11EF7BE8 11EF7C30
> 11D24514 10EFABD8 10E92950 10E96658 10E9BC20 10E9C128 10E9C1D8 10EB9210
> 10EC5B34 10F09C50 10F05C08 10F06A78 10EC889C 10EC8A38 109A05C4 109975B4
>
> Build: 12.2(54)SG ENTSERVICESK9
> buildversion addr: 13D4321C
>
> Traceback: 11D21684 11D217B4 11EF5188 11EF5BF4 11EF6C8C 11EF6E84 11EF6ECC
> 11D23FF8 10EFAB28 10E928A0 10E965A8 10E9BB70 1
> 0E9C078 10E9C128 10EB9160 10EC5A84 10F09BA0 10F05B58 10F069C8 10EC87EC
> 10EC8988 109A0594 10997584
>
>
> Several cat 4900m-s in another locations works fine with the same IOS
> versions.
>
> Does anybody has similar problems with these switches?
> Unfortunatelly we havn't smartnet for these switches and I can't open
> TAC case. I have several crashinfo files and can send them to anybody
> who can help.
>
> Thanks in advance!
>
> --
>Sincerely yours,
> Artyom Viklenko.
> ---
> ar...@aws-net.org.ua | http://www.aws-net.org.ua/~artem
> ar...@viklenko.net   | JID: ar...@jabber.aws-net.org.ua
> FreeBSD: The Power to Serve   -  http://www.freebsd.org
> ___
> 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] Fabric buffer-reserve high: what does it actually do?

[Tóth András]

Hi Dale,

Only an internal one. This command was not officially documented in
the past, that's why no external documentation mentions this change.

Best regards,
Andras

On Tue, Aug 28, 2012 at 8:04 PM, Dale W. Carder  wrote:
> Hi Andras,
>
> Do you have a link to documentation/ddts that describes this change?
>
> Dale
>
> Thus spake John Neiberger (jneiber...@gmail.com) on Mon, Aug 27, 2012 at 
> 12:00:02PM -0600:
>> An app owner (Oracle database) has recommended that we enable "fabric
>> buffer-reserve high" to solve some Oracle problem they seem to be
>> running into. We haven't had a chance to investigate their problem
>> yet, so we're not going to change that just because they asked us to.
>> However, I'm curious about what it actually does and how it interacts
>> with the hardware buffers on the 67xx line cards. I did a quick Google
>> search, but didn't find a lot of detail.
>>
>> 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] Fabric buffer-reserve high: what does it actually do?

[Tóth András]

Hi John,

It will cause outdated settings on recent versions (that is, newer
than SXF8 because SXF8 already includes a fix which makes fabric
buffer-reserve command unnecessary) and by default, system settings
are more optimal. This command was meant to be used long ago before
the current default settings and should not be used.

Best regards,
Andras

On Mon, Aug 27, 2012 at 8:00 PM, John Neiberger  wrote:
> An app owner (Oracle database) has recommended that we enable "fabric
> buffer-reserve high" to solve some Oracle problem they seem to be
> running into. We haven't had a chance to investigate their problem
> yet, so we're not going to change that just because they asked us to.
> However, I'm curious about what it actually does and how it interacts
> with the hardware buffers on the 67xx line cards. I did a quick Google
> search, but didn't find a lot of detail.
>
> 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] Output drops mysteriously appear/disappear on 3750X

[Tóth András]

Hi Eric,

This seems to be caused by the below software bug.

CSCtq86186 - Switch stack shows incorrect values for output drops on
show interfaces
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtq86186

I've verified that this affects 15.0(1)SE3 and it'll be fixed in 15.0(2)SE.

You can use the 'show platform port-asic stats drop' command to check
hardware drop counters.

Best regards,
Andras

On Wed, Aug 22, 2012 at 12:38 AM, Eric Van Tol  wrote:
> Hi all,
> I've got a pair of stacked 3750X switches running 15.0(1)SE3 and I'm noticing 
> something funky.  On a pair of mirror destination ports, I'm seeing output 
> drops appear and disappear in the CLI output of 'show interface' at random 
> intervals.  What I mean by this is, after clearing counters on all 
> interfaces, I can do a 'show int gi1/0/16' and see 'output drops 0' re-run 
> the command one second later and see 'output drops 39428200', then re-run the 
> command another second later and see 'output drops 0' again.  I see it on 
> four monitor session destination ports.  The problem started somewhat 
> randomly one day last week, after having working fine for two days prior 
> after being put into production use.
>
> Anyone ever seen this before?  I'm pretty sure it's not just a cosmetic 
> issue, as the analyzer attached to these ports is seeing "packet loss" on the 
> traffic its analyzing, but I don't believe the source ports are actually 
> seeing any loss.
>
> Output is below - take note of the 'Last clearing of counters' times.
>
> -evt
>
> ~~
> vsw1-1213c.ss.sls.md#sh int gi2/0/17
> GigabitEthernet2/0/17 is up, line protocol is down (monitoring)
>   Hardware is Gigabit Ethernet, address is d48c.b549.4511 (bia d48c.b549.4511)
>   Description: VL Mirror Port
>   MTU 9198 bytes, BW 100 Kbit/sec, DLY 10 usec,
>  reliability 255/255, txload 1/255, rxload 1/255
>   Encapsulation ARPA, loopback not set
>   Keepalive set (10 sec)
>   Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX
>   input flow-control is off, output flow-control is unsupported
>   ARP type: ARPA, ARP Timeout 04:00:00
>   Last input never, output never, output hang never
>   Last clearing of "show interface" counters 01:23:22
>   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
>   Queueing strategy: fifo
>   Output queue: 0/40 (size/max)
>   30 second input rate 0 bits/sec, 0 packets/sec
>   30 second output rate 3868000 bits/sec, 2243 packets/sec
>  0 packets input, 0 bytes, 0 no buffer
>  Received 0 broadcasts (0 multicasts)
>  0 runts, 0 giants, 0 throttles
>  0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
>  0 watchdog, 0 multicast, 0 pause input
>  0 input packets with dribble condition detected
>  24027518 packets output, 5217538085 bytes, 0 underruns
>  0 output errors, 0 collisions, 0 interface resets
>  0 unknown protocol drops
>  0 babbles, 0 late collision, 0 deferred
>  0 lost carrier, 0 no carrier, 0 pause output
>  0 output buffer failures, 0 output buffers swapped out
> vsw1-1213c.ss.sls.md#sh int gi2/0/17
> GigabitEthernet2/0/17 is up, line protocol is down (monitoring)
>   Hardware is Gigabit Ethernet, address is d48c.b549.4511 (bia d48c.b549.4511)
>   Description: VL Mirror Port
>   MTU 9198 bytes, BW 100 Kbit/sec, DLY 10 usec,
>  reliability 255/255, txload 1/255, rxload 1/255
>   Encapsulation ARPA, loopback not set
>   Keepalive set (10 sec)
>   Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX
>   input flow-control is off, output flow-control is unsupported
>   ARP type: ARPA, ARP Timeout 04:00:00
>   Last input never, output never, output hang never
>   Last clearing of "show interface" counters 01:23:23
>   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 39428034
>   Queueing strategy: fifo
>   Output queue: 0/40 (size/max)
>   30 second input rate 0 bits/sec, 0 packets/sec
>   30 second output rate 3868000 bits/sec, 2243 packets/sec
>  0 packets input, 0 bytes, 0 no buffer
>  Received 0 broadcasts (0 multicasts)
>  0 runts, 0 giants, 0 throttles
>  0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
>  0 watchdog, 0 multicast, 0 pause input
>  0 input packets with dribble condition detected
>  24027518 packets output, 5217538085 bytes, 0 underruns
>  0 output errors, 0 collisions, 0 interface resets
>  0 unknown protocol drops
>  0 babbles, 0 late collision, 0 deferred
>  0 lost carrier, 0 no carrier, 0 pause output
>  0 output buffer failures, 0 output buffers swapped out
> vsw1-1213c.ss.sls.md#sh int gi2/0/17
> GigabitEthernet2/0/17 is up, line protocol is down (monitoring)
>   Hardware is Gigabit Ethernet, address is d48c.b549.4511 (bia d48c.b549.4511)
>   Description: VL Mirror Port
>   MTU 9198 bytes, BW 100 Kbit/sec, DLY 10 usec,
>  reliability 255/255, txload 1/255, rxload 1/255
>   Encapsulation ARPA, loop

Re: [c-nsp] 3550-12 interrupts out of control, possibly hardware?

[Tóth András]

Hi Andy,

The only thing which comes to my mind when you mention vlan 1 is that
by default it is untagged. Therefore you might have some misconfig or
miscabling or not having routing enabled, something similar which
causes traffic from or to a routed port to arrive untagged which is
interpreted as vlan 1 traffic by the other side. Perhaps the switch is
not running IP Routing properly as you say.

Having high CPU usage is strange, that suggests either a L2 loop or
software switching most often, latter can be caused by lack of
resources with incorrect SDM template.

There would be some additional details needed to better understand,
exact topolgy diagram, config of devices, etc. 12.2(44)SE6 is the
latest for 3550 though. Have you seen anything strange in logs during
the issue?

Best regards,
Andras

On Fri, Aug 17, 2012 at 12:23 AM, Andy Dills  wrote:
>
> Thanks, I appreciate those suggestions. I verified both the SDM and VTP
> configs are identical.
>
> Did you see my followup from earlier? I identified that for some reason
> unknown to me, the traffic was hitting the vlan1 interface before exiting
> via the L3 interface facing that network, which was forcing all of the
> traffic to get process switched. I have no idea why, though, and would
> love suggestions.
>
> My best guess is that because they configured the port for L3 mode before
> they enabled ip routing on the failover 3550-12, something didn't happen
> right and perhaps a reload would have fixed it. I do know that in the past
> when I have done "ip routing" on a live 3550, it goes unresponsive for
> about 10-15 seconds, so I have to assume a lot goes on behind the scenes.
> And I do know from the transcript of their changes that they configured
> the port for L3 mode before realizing ip routing had never been enabled on
> that switch. Given the "illogical" (in quotes because perhaps there
> is some logic that is escaping me) nature of the behavior observed, I have
> to assume it was some sort of quirk of bug like this. For what it's worth,
> they're both running c3550-ipservices-mz.122-44.SE6.
>
> Thanks,
> Andy
>
> On Fri, 17 Aug 2012, Tóth András wrote:
>
>> Hi Andy,
>>
>> One idea is different SDM templates being used. The SDM template is
>> not showing up in running-config, and changing it requires a reload as
>> well. I would compare them with 'sh sdm prefer' command. You might be
>> running out of IPv4 routes, which causes rest of routes to be applied
>> in software, so packets are software switched by the CPU which can
>> cause high utilization.
>>
>> http://www.cisco.com/en/US/products/hw/switches/ps646/products_tech_note09186a0080094bc6.shtml
>>
>> http://www.cisco.com/en/US/docs/switches/lan/catalyst3550/software/release/12.2_44_se/configuration/guide/swadmin.html#wp1235565
>>
>> Best regards,
>> Andras
>>
>> On Thu, Aug 16, 2012 at 6:36 PM, Andy Dills  wrote:
>> >
>> > I've got a customer with a weird situation.
>> >
>> > They have a pretty straightforward setup, two 7200s fronting two cisco
>> > 3550-12s, distributing to a series of 48 port 3550s. It's a bit dated, but
>> > works very well for their needs.
>> >
>> > They have one special network attached to (only) one of the copper gige
>> > ports on (one of) the 3550-12s which gets a decent amount of traffic
>> > (~100mbps or so). It's a layer 3 connection.
>> >
>> > Well, one of their 3550-12s died, taking down that network. They moved the
>> > IP configuration of the port and moved the cable immediately, restoring
>> > service, and racked/configured a replacement switch, but left that network
>> > on the second 3550-12, as it seemed fine.
>> >
>> > However, once it began to come under load this morning, the CPU pegged
>> > (80-99%, normally at 1-2%), causing packet drops and latency.
>> >
>> > At that point I got involved, and for the life of me I can't figure out
>> > why this happened. Clearly it's interrupts, as there were no processes in
>> > the "sh proc cpu" that had more than 1% of CPU. However, cef was working
>> > fine, everything looked normal in terms of the traditional interrupt-based
>> > troubleshooting.
>> >
>> > So, after scratching our heads for a bit, I had them move the connection
>> > back to the original, newly-replaced switch. Note that these switches are
>> > configured 100% identically with the exception of IP address and hostname.
>> > Same IOS versions. I mean literally, if you diff the two 

Re: [c-nsp] 3550-12 interrupts out of control, possibly hardware?

[Tóth András]

Hi Andy,

One idea is different SDM templates being used. The SDM template is
not showing up in running-config, and changing it requires a reload as
well. I would compare them with 'sh sdm prefer' command. You might be
running out of IPv4 routes, which causes rest of routes to be applied
in software, so packets are software switched by the CPU which can
cause high utilization.

http://www.cisco.com/en/US/products/hw/switches/ps646/products_tech_note09186a0080094bc6.shtml

http://www.cisco.com/en/US/docs/switches/lan/catalyst3550/software/release/12.2_44_se/configuration/guide/swadmin.html#wp1235565

Best regards,
Andras

On Thu, Aug 16, 2012 at 6:36 PM, Andy Dills  wrote:
>
> I've got a customer with a weird situation.
>
> They have a pretty straightforward setup, two 7200s fronting two cisco
> 3550-12s, distributing to a series of 48 port 3550s. It's a bit dated, but
> works very well for their needs.
>
> They have one special network attached to (only) one of the copper gige
> ports on (one of) the 3550-12s which gets a decent amount of traffic
> (~100mbps or so). It's a layer 3 connection.
>
> Well, one of their 3550-12s died, taking down that network. They moved the
> IP configuration of the port and moved the cable immediately, restoring
> service, and racked/configured a replacement switch, but left that network
> on the second 3550-12, as it seemed fine.
>
> However, once it began to come under load this morning, the CPU pegged
> (80-99%, normally at 1-2%), causing packet drops and latency.
>
> At that point I got involved, and for the life of me I can't figure out
> why this happened. Clearly it's interrupts, as there were no processes in
> the "sh proc cpu" that had more than 1% of CPU. However, cef was working
> fine, everything looked normal in terms of the traditional interrupt-based
> troubleshooting.
>
> So, after scratching our heads for a bit, I had them move the connection
> back to the original, newly-replaced switch. Note that these switches are
> configured 100% identically with the exception of IP address and hostname.
> Same IOS versions. I mean literally, if you diff the two in rancid, those
> are the only config changes.
>
> Zero problems from the point they moved the connection off of the switch
> in question, both switches now have 1-2% CPU and things are humming along
> fine.
>
> So, my question is: What could be the possible causes of this? Could this
> be a symptom of failing hardware, perhaps some bad memory requiring
> constant CPU corrections?
>
> Thanks,
> Andy
>
> ---
> Andy Dills
> Xecunet, Inc.
> www.xecu.net
> 301-682-9972
> ---
> ___
> 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] Loop/Unreachable problem with C6500/SUP720

[Tóth András]

Hi Sebastian,

The CEF entries indeed seem to be correct. Could you do a SPAN capture
on the 6500 interface towards the server and compare the working and
non-working scenario? It'd be interesting to see if the packet indeed
leaves the correct interface at all or not and how the packet headers
look like.

Additionally, if you see the packet going out, do a packet capture on
the server to see if it arrives there, what the server is doing with
it. I'd not be surprised if the server is just routing or bridging the
packet back somehow. Just an idea though.

If all else is unsuccessful, a TAC case might be helpful to perform
ELAM captures to see where the packets are destined and sent out, etc.

Best regards,
Andras

On Thu, Aug 9, 2012 at 11:45 AM, Sebastian Wiesinger
 wrote:
> * Randy  [2012-08-08 21:35]:
>> ...also curious:
>>
>> If there is a discrepancy between "sh ip cef " and "sh ip
>> cef  internal" for prefixes in question.
>
> Here is the working prefix:
>
> $ ping 10.1.66.51
> PING 10.1.66.51 (10.1.66.51) 56(84) bytes of data.
> 64 bytes from 10.1.66.51: icmp_req=1 ttl=60 time=3.93 ms
> 64 bytes from 10.1.66.51: icmp_req=2 ttl=60 time=3.97 ms
> 64 bytes from 10.1.66.51: icmp_req=3 ttl=60 time=3.98 ms
>
> And the bad one:
>
> $ ping 10.1.66.84
> PING 10.1.66.84 (10.1.66.84) 56(84) bytes of data.
> From 10.2.14.9 icmp_seq=1 Time to live exceeded
> From 10.2.14.9 icmp_seq=2 Time to live exceeded
> From 10.2.14.9 icmp_seq=3 Time to live exceeded
>
>
> We start with show ip cef:
>
> lab-rtr1#show ip cef 10.1.66.51
> 10.1.66.51/32
>   attached to Vlan412
>
> lab-rtr1#show ip cef 10.1.66.84
> 10.1.66.84/32
>   attached to Vlan412
>
>
> We go on with show ip cef internal:
>
> lab-rtr1#show ip cef 10.1.66.51 internal
> 10.1.66.51/32, epoch 7, flags attached, refcount 5, per-destination sharing
>   sources: Adj
>   feature space:
>NetFlow: Origin AS 0, Peer AS 0, Mask Bits 25
>   subblocks:
>Adj source: IP adj out of Vlan412, addr 10.1.66.51 5136EEC0
> Dependent covered prefix type adjfib cover 10.1.66.0/25
>   ifnums:
>Vlan412(180): 10.1.66.51
>   path 5110F968, path list 5110C090, share 1/1, type adjacency prefix, for 
> IPv4
>   attached to Vlan412, adjacency IP adj out of Vlan412, addr 10.1.66.51 
> 5136EEC0
>   output chain: IP adj out of Vlan412, addr 10.1.66.51 5136EEC0
>
> lab-rtr1#show ip cef 10.1.66.84 internal
> 10.1.66.84/32, epoch 7, flags attached, refcount 5, per-destination sharing
>   sources: Adj
>   feature space:
>NetFlow: Origin AS 0, Peer AS 0, Mask Bits 25
>   subblocks:
>Adj source: IP adj out of Vlan412, addr 10.1.66.84 5136A6C0
> Dependent covered prefix type adjfib cover 10.1.66.0/25
>   ifnums:
>Vlan412(180): 10.1.66.84
>   path 51110C70, path list 5110D2F8, share 1/1, type adjacency prefix, for 
> IPv4
>   attached to Vlan412, adjacency IP adj out of Vlan412, addr 10.1.66.84 
> 5136A6C0
>   output chain: IP adj out of Vlan412, addr 10.1.66.84 5136A6C0
>
>
> And show mls cef detail / mls adjacency:
>
> lab-rtr1#show mls cef 10.1.66.51 detail
>
> Codes: M - mask entry, V - value entry, A - adjacency index, P - priority bit
>D - full don't switch, m - load balancing modnumber, B - BGP Bucket sel
>V0 - Vlan 0,C0 - don't comp bit 0,V1 - Vlan 1,C1 - don't comp bit 1
>RVTEN - RPF Vlan table enable, RVTSEL - RPF Vlan table select
> Format: IPV4_DA - (8 | xtag vpn pi cr recirc tos prefix)
> Format: IPV4_SA - (9 | xtag vpn pi cr recirc prefix)
> M(313): E | 1 FFF  0 0 0 0   255.255.255.255
> V(313): 8 | 1 00 0 0 0   10.1.66.51  (A:425985 ,P:1,D:0,m:0 ,B:0 )
>
> lab-rtr1#show mls cef adjacency entry 425985
>
> Index: 425985  smac: 0003.3245., dmac: 0023.ae67.936e
>mtu: 1518, vlan: 412, dindex: 0x0, l3rw_vld: 1
>packets: 0, bytes: 0
>
> lab-rtr1#show mls cef 10.1.66.84 detail
>
> Codes: M - mask entry, V - value entry, A - adjacency index, P - priority bit
>D - full don't switch, m - load balancing modnumber, B - BGP Bucket sel
>V0 - Vlan 0,C0 - don't comp bit 0,V1 - Vlan 1,C1 - don't comp bit 1
>RVTEN - RPF Vlan table enable, RVTSEL - RPF Vlan table select
> Format: IPV4_DA - (8 | xtag vpn pi cr recirc tos prefix)
> Format: IPV4_SA - (9 | xtag vpn pi cr recirc prefix)
> M(345): E | 1 FFF  0 0 0 0   255.255.255.255
> V(345): 8 | 1 00 0 0 0   10.1.66.84  (A:442370 ,P:1,D:0,m:0 ,B:0 )
>
> lab-rtr1#show mls cef adjacency entry 442370
>
> Index: 442370  smac: 0003.3245., dmac: 0023.ae67.936e
>mtu: 1518, vlan: 412, dindex: 0x0, l3rw_vld: 1
>packets: 0, bytes: 0
>
>
> As far as I see, it looks OK. The problem lies somewhere deeper at the
> hardware level.
>
> Regards
>
> Sebastian
>
> --
> GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
> 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE 
> SCYTHE.
> -- Terry Pratchett, The Fifth Elephant
> ___

Re: [c-nsp] simple link aggregation

[Tóth András]

You might want to use src-ip and dst-ip instead of mac depending on
your topology and on the location of the L2 boundary. If there's a
router in between, the src/dst mac might be static, being the router
mac.

Andras

On Tue, Jul 31, 2012 at 6:34 PM, Mike
 wrote:
> On 07/31/2012 01:06 AM, Peter Rathlev wrote:
>>
>>
>> Cisco's hardware forwarding platforms only support deterministic hashed
>> load sharing. What link member a specific packet uses is determined from
>> L2, L3 or L4 information or a combination of these. The 3560 and 2970
>> platforms support using L2 and/or L3 information:
>>
>> Switch(config)#port-channel load-balance ?
>>dst-ip   Dst IP Addr
>>dst-mac  Dst Mac Addr
>>src-dst-ip   Src XOR Dst IP Addr
>>src-dst-mac  Src XOR Dst Mac Addr
>>src-ip   Src IP Addr
>>src-mac  Src Mac Addr
>>
>>
>
>
>
> Damm, you are right. My problem is that I have many pppoe subscribers on one
> side of the link, talking to essentially 1 server. So if rr isn't an option,
> then I would likely need to do load-balance per source mac on the subscriber
> side and by dest mac on the server side.
>
> Thanks for the rest of the info, thats enough to get me started.
>
> Mike-
>
>
> ___
> 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] Unable to clear vty session on 3750

[Tóth András]

Hi,

Try the 'clear line vty ' command as well to clear out the stuck session.

The version number you provided is the rommon version, you need the
first line of 'sh ver' instead. You might be hitting CSCte52821
though.

Best regards,
Andras

On Tue, Jul 31, 2012 at 1:02 PM, Nick Hilliard  wrote:
> On 31/07/2012 10:29, Bouazza Djamel wrote:
>> I have an issue today with nombers of vty sessions.We have no console
>> access for this device.See below please :
>
> three options here:
>
> 1.  configure a timer on the vty and use TCP keepalives to stop this from
> happening in future:
>
> switch#conf t
> switch(config)#service tcp-keepalives-in
> switch(config)#service tcp-keepalives-out
> switch(config)#line vty 0 15
> switch(config)# exec-timeout 5
>
> If this fails to clear things after 30 minutes, then try:
>
> 2.  clear the TCB (transmission control block - an internal TCP data
> structure) for each vty line.
>
> You can get the TCB id for each line using:
>
> switch#show tcp brief
>
> It's in the first column.  Confirm it first with:
>
> switch#show tcp tcb 
>
> You can clear the TCB using:
>
> switch#clear tcp tcb 
>
> If this fails:
>
> 3. reboot.
>
> Probably #2 will work this time and #1 will prevent the problem from
> recurring in future.
>
> 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/
___
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 5010 error %STP-2-VLAN_PORT_LIMIT_EXCEEDED:

[Tóth András]

Hi Arne,

The error message itself is pretty self-explanatory, you are having
too many active STP instances (vlans) on ethernet interfaces. Try
pruning the vlans by modifying the allowed vlan list on your trunk
ports and remove unnecessary vlans.

You can see the limitations for 4.1(3) release here:
http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/configuration_limits/limits_413/Cisco_Nexus_5000_Series_Configuration_Limits_for_Cisco_NX_OS_Release_413_chapter1.html


Release 4.1(3) is pretty old and you can increase the scalability and
configuration limits by upgrading to a newer release such as 5.0(3) or
5.1(3). I've included the configuration limits for these versions
below:
http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/configuration_limits/limits_503/nexus_5000_config_limits_503_n2_1.html

http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/configuration_limits/limits_513/nexus_5000_config_limits_513.html


Upgrading from 4.1(3) to 5.1(3) will be disruptive, unless you go
through some interim versions. More information is in the Release
Notes in the "Supported Upgrade and Downgrade Paths" section.

Best regards,
Andras


On Sat, Jun 30, 2012 at 7:56 AM, Arne Larsen  / Region Nordjylland
 wrote:
> Hi all.
>
> Can someone give me a hint about what I might be looking for, or how can I 
> track this.
> %STP-2-VLAN_PORT_LIMIT_EXCEEDED: The number of vlan-port instances (3300) 
> exceeded [MST mode] recommended limit of 3140.
> We use nexus 5010 with vpc and the Nexus2K are dualhomed. The Nexus5010 are 
> connected to a vss6500 also with vpc.
>
> spanning-tree mst configuration
>   name xx-yy
>   instance 1 vlan 1-999
>   instance 2 vlan 3000-3899
>
> System version: 4.1(3)N2(1a)
>
>
> /Arne
>
> ___
> 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 3k track option for static route

[Tóth András]

Hi,

You can configure IP Route Tracking on Nexus 3k using the track configuration:
track 2 ip route 192.0.2.0/8 reachability

Configuring Object Tracking for Route Reachability
http://www.cisco.com/en/US/docs/switches/datacenter/nexus3000/sw/unicast/503_u3_1/l3_object.html#wp1092386

Best regards,
Andras

On Mon, Jun 25, 2012 at 3:21 PM, Hiromasa Sekiguchi
 wrote:
> Hello,
>
> We would like to configure track option for static route.
> e.g. ip route 0.0.0.0/0 *.*.*.* track
>                                ^ here!
>
> However, there are no option...
>
> Does nexus 3k not support track option for static route?
> Are there any workaround?
>
> Regards,
> Hiromasa
> ___
> 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] Limiting upload speeds on 2960 switches

[Tóth András]

Hi Chiel,

The following might work for you. You can customize the policy-map or
create more if needed.

policy-map LIMIT-50M
 class class-default
  police 5000 64000 exceed-action drop

interface 
 service-policy input LIMIT-50M

Best regards,
Andras

On Fri, Jun 8, 2012 at 9:56 PM, chiel  wrote:
> Hello,
>
> Got a Cisco 3745 router with a couple of 2960 switches for access. We are
> selling a service based on 50Mbps download and 25Mbps upload on each port.
> With " srr-queue bandwidth limit 50" on each switchport I can limit the
> download to 50Mbps. I'm looking for something similar to manage the upload.
> Any toughts? I looked into microflow but that only seems to be available on
> 6500 and a like. Preferable I like to have a similar future as the download,
> but that doesn't seems to be available.
>
> best regards,
> Chiel
> ___
> 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] I can't seem to get this 3750 to properly filter IPv6 on a VLAN ACL.

[Tóth András]

Hi Paul,

It's also mentioned in the config guide.

The switch does not support VLAN ACLs (VLAN maps) for IPv6 traffic.

IPv6 ACL Limitations
This release supports only port ACLs and router ACLs for IPv6; it does
not support VLAN ACLs (VLAN maps).

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_52_se/configuration/guide/swv6acl.html


Best regards,
Andras

On Thu, Apr 26, 2012 at 6:35 PM, Paul Wozney  wrote:
> Thanks Klaus,
>
>> > mac access-list extended macl-ipv6
>> >  deny   any any 0x86DD 0x0
>> >  permit any any
>>
>> IRC MAC ACLs on CAT2K/3K (12.2SE) only match "non-IP" traffic.
>> IPv4 packets match only in the IP ACL,
>> IPv6 packets match only in the IPv6 ACL.
>>
>> So even with a "deny any any" in the MAC ACL IPv4 and IPv6 packets
>> won't be blocked. (IPv4 won't work because ARP will match under non-IP)
>
> That pretty much explains the mystery.  I was confused as to why I could
> match some ethertypes and not others, and even though the confusion is gone
> the frustration isn't.  Maybe there's an architectural reason that we can't
> do this but I don't know it.
>
> I guess I'm going to use the ipv6 template and filter on L3 like Nick
> Hilliard suggested.
>
> Paul
> ___
> 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] Is there sticky ARP functionality on Private VLAN in NX-OS

[Tóth András]

Hi Matt,

Sticky ARP is not available yet for Nexus series switches. There's an
internal enhancement request opened for supporting "ip sticky-arp" on
NX-OS but it's not yet implemented.

I've removed the incorrect note from the Cisco DocWiki, however note
that it's not the official Cisco Documentation.

Best regards,
Andras

On Thu, Mar 22, 2012 at 2:14 AM, Stoward, Matt
 wrote:
> Hi all,
>
> When configuring PVLANs in IOS, the L3 SVIs automatically get sticky ARP 
> turned on and to remove it is quite simple.
>
> In NX-OS things are a little uncertain. It is implied that the behavior is 
> the same but I don't think it actually is. On the Cisco site in 
> http://docwiki.cisco.com/wiki/Cisco_Nexus_7000_Series_NX-OS_Troubleshooting_Guide_--_Troubleshooting_VLANs
>  , and to quote: "Note:  We recommend that you enable sticky Address 
> Resolution Protocol (ARP) when you configure private VLANs. ARP entries 
> learned on Layer 3 private VLAN interfaces, or SVIs, are sticky ARP entries. 
> For security reasons, private VLAN port sticky ARP entries do not age out. "
>
> This is the only reference I can find to sticky ARP anywhere (except for a 
> couple of similar looking entries for this like the 1000V). Is this quite 
> possibly an error in documentation? Having sticky ARPs in a big virtualized 
> environment is going to break things for the sever guys and I want to ensure 
> I head this off before it becomes a problem.
>
> Regards,
> Matt
>
> ___
> 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 COPP ARP traffic?

[Tóth András]

Hi Jeffrey,

All ARP requests which are broadcasts arriving in a vlan where an SVI
is up would be punted to CPU and throttled by CoPP and HW
rate-limiters. If there are no L3 interfaces, packets should not go to
CPU.

Perhaps they came from the management port, where CoPP is not applied.
It's difficult to tell post-mortem, we'd need to see which process was
using the CPU and confirm the type and source of packets hitting the
CPU with an inband SPAN capture or an ethanalyzer capture.

Best regards,
Andras


On Mon, Mar 26, 2012 at 5:54 PM, Jeffrey G. Fitzwater
 wrote:
>
> I am trying to understand if ALL ARP (requests ) packets that a nexus 7K 
> sees, need to be punted to the CPU and therefor managed by COPP policies / 
> rate-limits?
>
> Over the weekend we had a data loop that cooked the CPU and we are trying to 
> understand what packets that were control plane processed, caused the CPU 
> load.
>
> We currently have a Nexus 7k running 5.2.1, that only has L2 interfaces, 
> other than the management VRF port.   I would think that the CPU would never 
> have to process any ARP requests for non-management traffic since it does not 
> have any L3 interfaces.
>
>
> My understanding is that other sites have had similar issues and changing the 
> COPP profile stopped  the CPU form being saturated during this kind of event.
>
> The COPP profile can be ( lenient, moderate, strict ).
>
>
> Thanks in advance for any info on this issue.
>
>
>
> Jeff Fitzwater
> OIT Netwrok Systems
> Princeton University
>
>
>
>
> ___
> 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 Sup2T CMP comands

[Tóth András]

Hi,

CMP implementation does not support features such as SNMP and Network
Time Protocol (NTP). However, the CMP gets regular clock updates from
Cisco IOS Software, which itself uses NTP.

The username cannot be changed, however you can modify the password by
using the 'password' command in CMP config mode.

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11-663635.html

Best regards,
Andras


On Fri, Mar 30, 2012 at 3:17 PM, selamat pagi  wrote:
> Looking for ways to customize the CMP
>
> 1)
> How can the clock be set or synchronised on the CMP ?
>
> Sup2T-cmp# sh clo
>  05:54:16 UTC Thu Mar 22 2012
>
> Sup2T# sh clo
> 15:10:37.407 UTC Fri Mar 30 2012
>
> 2)
> Can the username be changed from root to xy ?
>
> many thanks,
>  keti
> ___
> 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] N7k CoPP versus rate-limiters

[Tóth András]

Hi Phil,

Sorry, my previous email deserves some clarification as it was a bit
confusing after I read it again.

OSPF packets sent to 224.0.0/24, will go through L3-control RL and not
CoPP. However, OSPF packets sent unicast will go through CoPP and not
L3-control RL.

There are only a few packets, such as DHCP and ARP which go through
both CoPP and rate-limiter.

There are some packets which CoPP cannot catch, and those need to be
rate-limited, and that is why there are rate-limiters.

As mentioned, you can use the "show hardware internal forwarding
rate-limiter usage" command to check what is handled by CoPP and what
is handled by rate-limiter, and what by both.

Best regards,
Andras


On Wed, Mar 21, 2012 at 9:58 PM, Tóth András  wrote:
> Hi Phil,
>
> Thanks for clarifying what you meant. I understand the documentation
> might not be detailed enough. Let me give some further information.
>
> The feature "hardware rate-limiter" is independent from CoPP, but it
> complements CoPP in protecting the supervisor CPU from excessive
> inbound traffic. The traffic rate allowed by the hardware
> rate-limiters is configured globally and applied to each individual
> I/O module. The resulting allowed rate depends on the number of I/O
> modules in the system. CoPP provides more granular supervisor CPU
> protection by utilizing the modular quality-of-service CLI (MQC).
>
>
> CoPP is evaluated first, then the HW Rate-limiters afterwards. There
> are some rate-limiters which can be found both in CoPP and in HW RL.
> An example is OSPF control packets. The reason for this is multiple
> layers of security and some form of redundancy if CoPP is not enabled.
>
> ip access-list copp-system-p-acl-ospf
>    permit ospf any any
> class-map type control-plane match-any copp-system-p-class-critical
>    match access-group name copp-system-p-acl-ospf
>
> See the following documentation for a few more examples of HW RLs:
> http://docwiki.cisco.com/wiki/Cisco_Nexus_7000_Series_NX-OS_Troubleshooting_Guide_--_Troubleshooting_Packet_Flow_Issues
>
>
> You can also use the following command to see how the RLs are mapped.
> With that you can also see what is and what isn't mapped to CoPP. As
> it's an internal command, it comes without the need of its output
> being customer friendly.
>
> show hardware internal forwarding rate-limiter usage
>
>
> I hope this helps a bit.
>
> Best regards,
> Andras
>
>
> On Wed, Mar 21, 2012 at 1:13 PM, Phil Mayers  wrote:
>> On 20/03/12 20:53, Tóth András wrote:
>>>
>>> Hi Phil,
>>>
>>> There are certain exceptions for packets being forwarded which are not
>>> handled by CoPP, these are covered by the HW Rate Limiters.
>>
>>
>> Andras,
>>
>> Thanks for the response. Unfortunately it didn't tell me anything I didn't
>> already know ;o)
>>
>> In fact, it appears to be largely cut&paste from the NX-OS docs, which I
>> have read.
>>
>> Perhaps I wasn't specific enough in my original email.
>>
>> I'm looking for comprehensive documentation on what types of packets are
>> considered to match the HW rate limiters, what types of packets match CoPP,
>> and how the system acts when >1 match occurs.
>>
>>
>> This kind of behaviour is not well documented for Sup720, but if you dig
>> through the Cisco site and archives of the list, you can find your info.
>>
>> It is even LESS well documented for N7k as far as I can tell. The HW RL have
>> uninformative names like "layer-3 control" and there is little or no
>> documentation about how they interact, other than tantalising hints like:
>>
>> """
>> Layer 3 control, multicast direct-connect, and ARP request packets are
>> controlled by the Layer 2 copy rate limiter. The first two types of packets
>> are also controlled by Layer 3 rate limiters, and the last two types are
>> also subject to control plane policing
>> """
>>
>> For example: which HW rate-limiters does an OSPF packet match, if any? In
>> which order do these rate-limiters match, and is it before or after CoPP?
>>
>> Or, the "receive" HW RL versus CoPP.
>>
>> Or, the "layer-3 ttl" HW RL versus the "match exception ttl-failure", or
>> again for "mtu".
>>
>> Hope that explains things in more details.
>>
>> Cheers,
>> Phil

___
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] N7k CoPP versus rate-limiters

[Tóth András]

Hi Phil,

Thanks for clarifying what you meant. I understand the documentation
might not be detailed enough. Let me give some further information.

The feature "hardware rate-limiter" is independent from CoPP, but it
complements CoPP in protecting the supervisor CPU from excessive
inbound traffic. The traffic rate allowed by the hardware
rate-limiters is configured globally and applied to each individual
I/O module. The resulting allowed rate depends on the number of I/O
modules in the system. CoPP provides more granular supervisor CPU
protection by utilizing the modular quality-of-service CLI (MQC).


CoPP is evaluated first, then the HW Rate-limiters afterwards. There
are some rate-limiters which can be found both in CoPP and in HW RL.
An example is OSPF control packets. The reason for this is multiple
layers of security and some form of redundancy if CoPP is not enabled.

ip access-list copp-system-p-acl-ospf
permit ospf any any
class-map type control-plane match-any copp-system-p-class-critical
match access-group name copp-system-p-acl-ospf

See the following documentation for a few more examples of HW RLs:
http://docwiki.cisco.com/wiki/Cisco_Nexus_7000_Series_NX-OS_Troubleshooting_Guide_--_Troubleshooting_Packet_Flow_Issues


You can also use the following command to see how the RLs are mapped.
With that you can also see what is and what isn't mapped to CoPP. As
it's an internal command, it comes without the need of its output
being customer friendly.

show hardware internal forwarding rate-limiter usage


I hope this helps a bit.

Best regards,
Andras


On Wed, Mar 21, 2012 at 1:13 PM, Phil Mayers  wrote:
> On 20/03/12 20:53, Tóth András wrote:
>>
>> Hi Phil,
>>
>> There are certain exceptions for packets being forwarded which are not
>> handled by CoPP, these are covered by the HW Rate Limiters.
>
>
> Andras,
>
> Thanks for the response. Unfortunately it didn't tell me anything I didn't
> already know ;o)
>
> In fact, it appears to be largely cut&paste from the NX-OS docs, which I
> have read.
>
> Perhaps I wasn't specific enough in my original email.
>
> I'm looking for comprehensive documentation on what types of packets are
> considered to match the HW rate limiters, what types of packets match CoPP,
> and how the system acts when >1 match occurs.
>
>
> This kind of behaviour is not well documented for Sup720, but if you dig
> through the Cisco site and archives of the list, you can find your info.
>
> It is even LESS well documented for N7k as far as I can tell. The HW RL have
> uninformative names like "layer-3 control" and there is little or no
> documentation about how they interact, other than tantalising hints like:
>
> """
> Layer 3 control, multicast direct-connect, and ARP request packets are
> controlled by the Layer 2 copy rate limiter. The first two types of packets
> are also controlled by Layer 3 rate limiters, and the last two types are
> also subject to control plane policing
> """
>
> For example: which HW rate-limiters does an OSPF packet match, if any? In
> which order do these rate-limiters match, and is it before or after CoPP?
>
> Or, the "receive" HW RL versus CoPP.
>
> Or, the "layer-3 ttl" HW RL versus the "match exception ttl-failure", or
> again for "mtu".
>
> Hope that explains things in more details.
>
> Cheers,
> Phil

___
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] N7k CoPP versus rate-limiters

[Tóth András]

Hi Phil,

There are certain exceptions for packets being forwarded which are not
handled by CoPP, these are covered by the HW Rate Limiters.

Hardware rate-limiters protect the supervisor CPU from excessive
inbound traffic. The traffic rate allowed by the hardware
rate-limiters is configured globally and applied to each individual
I/O module. The resulting allowed rate depends on the number of I/O
modules in the system. CoPP provides more granular supervisor CPU
protection by utilizing the modular quality-of-service CLI (MQC).

Note that CoPP is applied per-linecard, so each module is allowed to
transmit the configured rate. There are 3 templates you can use for
CoPP, lenient, moderate and strict. The documentation describes them
and their values in detail. You can apply one or the other with the
'copp profile' command.


You can read more in detail about Configuring Rate Limits on the following link:
http://www.cisco.com/en/US/docs/switches/datacenter/sw/6_x/nx-os/security/configuration/guide/b_Cisco_Nexus_7000_NX-OS_Security_Configuration_Guide__Release_6.x_chapter_011010.html

Below you can find the documentation for CoPP:
http://www.cisco.com/en/US/docs/switches/datacenter/sw/6_x/nx-os/security/configuration/guide/b_Cisco_Nexus_7000_NX-OS_Security_Configuration_Guide__Release_6.x_chapter_011001.html


Best regards,
Andras


On Wed, Mar 14, 2012 at 12:41 PM, Phil Mayers  wrote:
> All,
>
> We've just taken delivery of our first pair of N7k (and so far I'm
> impressed).
>
> I'm playing with porting our standard 6500 config to an equivalent N7k
> config, and I'm a bit puzzled by the interaction of CoPP and the hardware
> rate-limiters.
>
> On 6500/Sup720 these two features have well documented limitations and
> interaction - specifically HW rate-limiters pre-empt CoPP. I can't seem to
> find detailed information on how that works in the N7k.
>
> In general, what should I be using, for what?
>
> This is NX-OS 6, with M1 series linecards doing routing (MPLS).
> ___
> 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_PLATFORM-2-PEER_RESET: RP is being reset by the SP

[Tóth András]

Hi Drew,

First of all, the first line of the 'show version' is required to decode this.

Additionally, as the message says "RP is being reset by the SP", the
routing processor is reset by the switching processor, so you need to
get the crashinfo (mainly the traceback) from the SP, which is
sup-bootflash.

If you send them I can take a look at it.

Best regards,
Andras


On Mon, Feb 20, 2012 at 8:35 PM, Drew Weaver  wrote:
> Howdy,
>
> I had a software forced reload on a switch (on this particular switch it was 
> the first time.)
>
> It left a crashinfo, which is unusual in my experience so it may actually be 
> a software issue.
>
> The switch is running SXI3 and this is the beginning of the crash dump, I 
> tried to use the bugchecker on cisco.com to figure out if maybe this is just 
> a bug in SXI3 but wondered if anyone is good at decoding these messes?
>
> Feb 20 12:48:06 EST: %C6K_PLATFORM-2-PEER_RESET: RP is being reset by the SP
> %Software-forced reload
> 12:48:06 EST Mon Feb 20 2012: Breakpoint exception, CPU signal 23, PC = 
> 0x424A5D18
>
> 
>   Possible software fault. Upon reccurence, please collect
>   crashinfo, "show tech" and contact Cisco Technical Support.
> 
>
> -Traceback= 424A5D18 424A386C 41D08558 41D09BDC 42089F9C 4208A0F4 42498EFC
> $0 : , AT : 43C0, v0 : 4548, v1 : 
> a0 : 46F3CE28, a1 : 8100, a2 : , a3 : 
> t0 : 42498FE8, t1 : 34008101, t2 : 42499010, t3 : 00FF
> t4 : 42498FE8, t5 : 500122E8, t6 : , t7 : 5C651E4D
> s0 : , s1 : 43B1, s2 : , s3 : 43A8
> s4 : 43A8, s5 : 43A8, s6 : 4336, s7 : 0001
> t8 : 5001234C, t9 : , k0 : , k1 : 
> gp : 43C050B4, sp : 50012418, s8 : 4335, ra : 424A386C
> EPC  : 424A5D18, ErrorEPC : BFC0, SREG     : 34008103
> MDLO : , MDHI     : , BadVaddr : 
> DATA_START : 0x436B77F0
> Cause 0C24 (Code 0x9): Breakpoint exception
>
> Anyway, good old 375 seconds of pain =)
>
> Anyone have any thoughts?
>
> Thanks,
> -Drew
>
> ___
> 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] vss and mlq qos 10g-only command

[Tóth András]

Hi Arne,

When you enter the mls qos 10g-only command, a supervisor engine with
both 1-Gigabit and 10-Gigabit Ethernet uplink ports reallocates the
interface queue capacity to improve the performance of its 10-Gigabit
Ethernet ports. The reallocation is possible only in 10g-only mode, in
which the supervisor engine's 1-Gigabit Ethernet ports are not used.
In the normal mode, when all supervisor engine ports are active, the
queue structure is 2q4t on receive and 1p3q4t on transmit. In 10g-only
mode, the queue structure is 8q4t on receive and 1p7q4t on transmit.

http://www.cisco.com/en/US/docs/ios/qos/command/reference/qos_m2.html#wp1041041

Andras


On Sat, Nov 26, 2011 at 5:30 PM, Arne Larsen  / Region Nordjylland
 wrote:
> Hi all
>
>
> Can someone explain exactly what the vss command mls qos 10g-only does.
> I know it changes queuing and buffer mechanism, but I'm a bit astonished by 
> the impact.
> We had a problem on a datacenter where we uses a VSS144 setup.
> We have both vss links on the supervisior modules.
> The problem was between Xen provisionings servers and Xen client hosts. The 
> Xen client OS that is streamed to the client, had retransmissions.
> After enabling the command all works fine.
> We are talking max 3Gb certain rate. Can this really overrun the vss-links ??
>
> /Arne
>
> ___
> 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 6500 [SUP720-3B]: %QM-4-AGG_POL_EXCEEDED: QoS Hardware Resources Exceeded : Out of Aggregate policers

[Tóth András]

Hi Chris,

This is indeed an expected behavior. There are 2 workarounds.
- Use vlan-based qos instead of port-based qos. [1]
- Disable qos marking statistics with the 'no mls qos marking
statistics' global configuration command.


If you have marking statistics enabled, the statements matched by the
class-maps will be installed into hardware  x 
number of times in order to provide granular statistics for each 'set
dscp' statement on every interface where the policy-map is applied.

The downside of this is that the QoS marking statistics will not be
seen from the CLI. You can check the markings in a sniffer capture if
required.


You can use the 'show platform hardware capacity qos' command to
verify the number of aggregate policers used before and after
disabling marking statistics.

[1]: 
http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00801b42bf.shtml#qm_agg

Best regards,
Andras


On Fri, Oct 7, 2011 at 4:13 PM, Chris Mason  wrote:
> Hi All,
>
> I am running 12.2(18)SXF12a on a Cisco 6500 and I am getting the
> following error message when applying a service policy to an
> interface:
>
> %QM-4-AGG_POL_EXCEEDED: QoS Hardware Resources Exceeded : Out of
> Aggregate policers
>
> I understand the EARL7 SUP720 has a limit of 1023 aggregate policers,
> but I have not configured any policers (aggregate or flow based).
> My service policy is very simple and it is setting dscp based on ACL matches:
>
> policy-map X
>  class AAA
>  set dscp cs6
>  class BBB
>  set dscp af32
>  class CCC
>  set dscp cs3
>
> From what I can see, I am using an aggregate entry for each class
> attached to an interface:
>
> Switch# show mls qos ip GigabitEthernet 2/7
>      Int Mod Dir  Class-map DSCP  Agg  Trust Fl   AgForward-By   AgPoliced-By
>                                   Id         Id
> ---
>     Gi2/7  5  In AAA   48  193     No  0              0              0
>     Gi2/7  5  In BBB   26  194     No  0              0              0
>     Gi2/7  5  In CCC   24  195     No  0              0              0
>     Gi2/7  5  In DDD   18  196     No  0        6338085              0
>
> Is it just a case that the error message is misleading and I can only
> use 1023 classes across the box or is this not expected?
> I know my solution is vlan based and I am going to need to move to
> that, but just checking this is expected and this limit isn't just
> policers.
>
> Thanks,
> Chris
>
> ___
> 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] policing by mac address

[Tóth András]

Hi Nikolay,

I could not find a documentation to confirm but I'd not be surprised
if having MAC ACL in a policy-map would not be supported. Might depend
on the platform and IOS though. For instance, MAC ACL in CoPP is not
supported on 6500 switches.

I think that could be the reason of having a separate "match
source-address mac" and "match destination-address mac" command as
well apart from the "match access-group" command.

http://www.cisco.com/en/US/docs/ios/qos/command/reference/qos_m1.html#wp1038658
http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfmcli2.html

Best regards,
Andras

On Fri, Oct 7, 2011 at 2:20 PM, Nikolay Shopik  wrote:
> Hey,
>
> I'm trying to configure basic stuff, like policing by mac address on router
> and it doesn't match any packets.
>
> class-map match-any shopik
>  match access-group 700
> policy-map ultraspeed
>  class shopik
>    police 8000 2000
> interface FastEthernet1/1
>  service-policy input ultraspeed
> access-list 700 permit 4487.fc8d.a826 ..
>
> This configuration never work for me, it just doesn't match packets
> according show policy-map int fa1/1. If I add additional match like "match
> source-address mac 4487.FC8D.A826", this start working. And here is output
> from show policy-map int fa1/1.
>
>  FastEthernet1/1
>
>  Service-policy input: ultraspeed
>
>    Class-map: shopik (match-any)
>      125 packets, 17888 bytes
>      5 minute offered rate 2000 bps, drop rate 2000 bps
>      Match: access-group 700
>        125 packets, 17888 bytes
>        5 minute rate 2000 bps
>      Match: source-address mac 4487.FC8D.A826
>        0 packets, 0 bytes
>        5 minute rate 0 bps
>      police:
>          cir 8000 bps, bc 2000 bytes
>        conformed 101 packets, 11808 bytes; actions:
>          transmit
>        exceeded 24 packets, 6080 bytes; actions:
>          drop
>        conformed 2000 bps, exceed 2000 bps
>
> This looks odd to me, because it appears to be start matching packets by mac
> access-list, while it's not entirely true.
>
> So my question is am I doing this wrong? Why mac access-list doesn't work?
> Match source-address, seems doing job but it less scale, especially when I
> need masks.
> ___
> 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] Per VLAN Bandwidth Shaping on Cisco 2960

[Tóth András]

Hi Righa,

Vlan-based QoS is not supported on Catalyst 2960 switches.

Best regards,
Andras


On Fri, Oct 7, 2011 at 7:08 PM, Righa Shake  wrote:
> Hi,
>
> Am looking at bandwidth shaping per VLAN on a 2960 Cisco Switch as opposed
> to doing it per port.
>
> Regards,
> Righa Shake
> ___
> 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] Max IPv6 route entries for Cisco 4948E

[Tóth András]

Hi Jose,

The 57000 is shared between IPv4 and IPv6.

Best regards,
Andras

On Fri, Sep 30, 2011 at 4:39 PM, Lobo  wrote:
> Hey everyone.  We're looking at the 4948E as a possible replacement for our
> aging 3550-12Ts and we were wondering if anyone has any information with
> regards to the maximum number of ipv6 routes that it will be able to hold.
>  The only information I've found is that the device has 57,000 routes
> maximum but it doesn't say if that number also applies for ipv6.  Based on
> other platforms, I'm thinking that maybe it will be half of that?
>
> Thanks for any info you guys can provide.
>
> Jose
> ___
> 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] 65K/S720/SXI - CoPP and RP SPAN order of operations?

[Tóth András]

Hi Jeremy,

By doing a "debug snmp packets", do you see the SNMP requests from the
non-allowed host? If CoPP is working correctly, you should not see
them as they are dropped in HW.

Best regards,
Andras


On Thu, Sep 22, 2011 at 7:28 PM, Jeremy Reid  wrote:
> Hey 65K CoPP/SPAN gurus,
>
> Does anyone know the definitive order of operations (for a 65K/s720 running 
> 12.2(33)SXI5) between CoPP and an rp-inband CPU SPAN session? In other words, 
> if I have a CoPP service policy applied to the control plane (input) that 
> drops all traffic matching a specific class, should I expect to continue to 
> see such traffic appear in the output of a SPAN session of the RP CPU even 
> though its ultimately being dropped by CoPP?
>
> I've long assumed that a SPAN session of the RP CPU would operate on the 
> 'back-end' of CoPP, and that I should not see traffic show up in a RP CPU 
> SPAN that is dropped by CoPP, but recently have been working to tune our CoPP 
> policies and have noted seeing traffic in an RP SPAN that is configured to be 
> dropped by CoPP. Is this an indication of something wrong with my policy, or 
> would it be expected that I should indeed continue to see the traffic in the 
> RP SPAN because the RP SPAN is capturing traffic destined for the RP CPU 
> *prior* to the application of the CoPP policy?
>
> For example given the following CoPP configuration:
>
> class-map match-all CoPP-Important
> match access-group name CoPP-Important
> class-map match-any CoPP-Undesirable
> match access-group name CoPP-Undesirable
> class-map match-all CoPP-Default
> match access-group 2
>
> policy-map CoPP
> class CoPP-Important
> police cir 100 bc 5 be 5 conform-action transmit exceed-action 
> drop violate-action drop
> class CoPP-Undesirable
> police cir 32000 bc 6000 be 12000 conform-action drop exceed-action drop 
> violate-action drop
> class CoPP-Default
> police cir 32000 bc 6000 be 12000 conform-action transmit exceed-action drop 
> violate-action drop
>
> ip access-list extended CoPP-Important
> remark Important traffic destined for RP (Rate-Limited)
> permit udp host x.x.x.x any eq snmp
> permit udp host y.y.y.y any eq snmp
>
> ip access-list extended CoPP-Undesirable
> remark Undesirable traffic destined for RP (Post-Dropped)
> permit udp any any eq snmp
>
> control-plane
> service-policy input CoPP
>
> Should I be seeing traffic showing up in a SPAN session of the RP CPU that 
> shows SNMP traffic destined for the RP that is NOT sourced specifically from 
> host x.x.x.x or y.y.y.y, like this? (source IPs changed to protect the 
> innocent):
>
> 13:09:30.096405 IP (tos 0x0, ttl 128, id 1816, offset 0, flags [none], proto 
> UDP (17), length 107)
> 1.2.3.4.28316 > 192.168.0.51.161: { SNMPv1 { GetRequest(64) R=132061 
> .1.3.6.1.2.1.25.3.2.1.5.1 .1.3.6.1.2.1[|snmp] } }
> 13:09:30.096407 IP (tos 0x0, ttl 128, id 1817, offset 0, flags [none], proto 
> UDP (17), length 107)
> 192.168.100.10.150.28316 > 192.168.1.184.161: { SNMPv1 { GetRequest(64) 
> R=132062 .1.3.6.1.2.1.25.3.2.1.5.1 .1.3.6.1.2.1[|snmp] }
> 13:09:30.096411 IP (tos 0x0, ttl 128, id 1818, offset 0, flags [none], proto 
> UDP (17), length 107)
> 10.10.2.5.28316 > 192.168.1.184.161: { SNMPv1 { GetRequest(64) R=132063 
> .1.3.6.1.2.1.25.3.2.1.5.1 .1.3.6.1.2.1[|snmp] }
>
> Note: RP Span configured as follows:
>
> monitor session 1 type local
> source cpu rp
> destination interface Te3/3
>
> Looking at the policy-map counters, CoPP does appear to be properly dropping 
> (at least some) traffic for the CoPP-Undesirable class:
>
> core1#show policy-map control-plane input class CoPP-Undesirable
>
> Control Plane Interface
>
> Service-policy input: CoPP
>
> Hardware Counters:
>
> class-map: CoPP-Undesirable (match-any)
> Match: access-group name CoPP-Undesirable
> police :
> 32000 bps 6000 limit 12000 extended limit
> Earl in slot 1 :
> 9612708 bytes
> 5 minute offered rate 21960 bps
> aggregate-forwarded 0 bytes action: drop
> exceeded 9612708 bytes action: drop
> aggregate-forward 0 bps exceed 21368 bps
> Earl in slot 3 :
> 0 bytes
> 5 minute offered rate 0 bps
> aggregate-forwarded 0 bytes action: drop
> exceeded 0 bytes action: drop
> aggregate-forward 0 bps exceed 0 bps
> Earl in slot 4 :
> 35380464 bytes
> 5 minute offered rate 80784 bps
> aggregate-forwarded 0 bytes action: drop
> exceeded 35380464 bytes action: drop
> aggregate-forward 0 bps exceed 79224 bps
> Earl in slot 5 :
> 0 bytes
> 5 minute offered rate 0 bps
> aggregate-forwarded 0 bytes action: drop
> exceeded 0 bytes action: drop
> aggregate-forward 0 bps exceed 0 bps
> Earl in slot 7 :
> 1640 bytes
> 5 minute offered rate 0 bps
> aggregate-forwarded 0 bytes action: drop
> exceeded 1640 bytes action: drop
> aggregate-forward 0 bps exceed 0 bps
> Earl in slot 8 :
> 0 bytes
> 5 minute offered rate 0 bps
> aggregate-forwarded 0 bytes action: drop
> exceeded 0 bytes action: drop
> aggregate-forward 0 bps exceed 0 bps
> Earl in slot 9 :
> 1312 bytes
> 5 minute offered rate 0

Re: [c-nsp] Cat 4500 series High CPU

[Tóth András]

Hi Terry,

Did you have a chance to review the following documentations?

High CPU Utilization on Cisco IOS Software-Based Catalyst 4500 Switches
http://www.cisco.com/en/US/products/hw/switches/ps663/products_tech_note09186a00804cef15.shtml

Troubleshooting High CPU on the Catalyst 4500-E Series Switch
http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/troubleshooting/cpu_util.html

Mgmt LoPri process is not only responsible for MAC learning, it could
be a couple more things. If you have narrowed down the issue to be
frequent MAC learning, try looking for L2 loops where MAC addresses
might flap between 2 ports and check which addresses are continuously
learnt. Additionally, look for frequent STP TCNs with 'sh span detail'
command and look for topology changes which can cause MAC table
flushing.

If you still need help, I would recommend opening a TAC case.

Best regards,
Andras


On Wed, Aug 31, 2011 at 11:53 PM, Terry Rupeni  wrote:
> Hi All,
>
>
>
> We have a Cat4506 facing high CPU. Investigating further we have narrowed it
> down to the following on the Cisco Bug Report:
>
>
>
> High CPU due to Mgmt LoPri process, MAC addresses being added/deleted
> Symptom:
> A Catalyst 4500 switch might experience high CPU utilization due to the
> Cat4k Mgmt LoPri process and the K2CpuMan and K2L2 Address Table reviews
> (show platform health. High CPU utilization does not impact the traffic
> switched in hardware.
>
>
>
> Conditions:
> The problem is seen when a large MAC address table exists and when the
> switch is frequently relearning MAC addresses on multiple VLANs. Enabling
> service internal followed by debug platform log feature k2l2addresstable
> will show output similar to the following. Do not enable these commands on a
> production switch unless instructed by Cisco TAC.
>
>
>
> However no solution is recommended by Cisco. As this is a production switch
> don't really want to do a debug right now.
>
>
>
> Has anyone faced a similar issue?
>
>
>
> Thks
>
> Terry
>
> ___
> 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] Q and Q De-encapsulation

[Tóth András]

An egress tunnel port strips the 2-byte Ethertype field (0x8100) and
the 2-byte length field and transmits the traffic with the 802.1Q tag
still intact to an 802.1Q trunk port on a customer device. The 802.1Q
trunk port on the customer device strips the 802.1Q tag and puts the
traffic into the appropriate customer VLAN.

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/dot1qtnl.html

Andras


On Wed, Aug 24, 2011 at 2:37 PM, Keegan Holley
 wrote:
>
>
> On Aug 24, 2011, at 5:12 AM, "Arie Vayner (avayner)"  
> wrote:
>
>> Do you want to strip only the outer tag? If yes, then it should be
>> easy... Just configure the port as a trunk, and the egress port as an
>> access port of the VLAN you want to send there (it would work for 1 out
>> tag VLAN at a time)
>
> I was wondering about this.  You'd essentially be egressing tagged frames
> from an access port. (that's just weird)  Also doesn't q-in-q have a 
> different tpid than regular vlan tags?  How does the box know what to do with 
> the frames if the ingress port is just a normal trunk?
>
>>
>> If you want more flexible QinQ support, you most likely need to look at
>> ES+ modules.
>>
>> Arie
>>
>> -Original Message-
>> From: cisco-nsp-boun...@puck.nether.net
>> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mike Aumand
>> Sent: Wednesday, August 24, 2011 00:07
>> To: cisco-nsp@puck.nether.net
>> Subject: [c-nsp] Q and Q De-encapsulation
>>
>>
>>   I was wondering if anyone knew if it was possible to have a single
>> gigabitethernet port on a 7609 running Version 12.2(33)SRB5 take in
>> 802.1Q tagged traffic and strip off the outer tag all on the single
>> ingress port?
>>
>> Thanks in advance,
>>                                   Mike
>>
>>
>>
>> Mike Aumand
>> Network Engineer
>> Cornerstone Telephone Company, LLC.
>> Richmond Telephone Company ~ Richmond Networx
>> 2 Third Street, Suite 303
>> Troy, NY, 12180
>> 518-328-0353 (w)
>> 518-577-8705 (c)
>> 518-860-1860 (f)
>>
>> This message may contain information that is privileged or confidential.
>> If you are not the intended recipient, you are hereby notified that any
>> disclosure, copying, distribution, or use of the information contained
>> herein is STRICTLY PROHIBITED. If you received this transmission in
>> error, please immediately contact the sender and destroy the material in
>> its entirety, whether in electronic or hard copy format.
>>
>> ___
>> 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/
>

___
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] reliability of ping to router physical-, sub- or loopback interface

[Tóth András]

In addition to that a lot of platforms, such as Catalyst switches
perform packet forwarding in hardware by ASICs and linecards can make
forwarding decisions, so pinging the switch/router/MLS might not be
accurate at all due to special configs on the ingress/egress
interface. Also, the CPU in the switch might not be as powerful as one
in a server therefore it will exhibit more latency.

Also, to discuss something about the initial question, on Nexus 7000
switches, CoPP can be enabled in the initial setup and it's commonly
used. However, one might forget about it and ping the N7k switch from
another smaller switch with a high packet rate and find packet loss,
although it is expected due to CoPP.

Best regards,
Andras


On Wed, Aug 24, 2011 at 2:02 PM, Arie Vayner (avayner)
 wrote:
> Actually, if you are a customer, and want to measure your upstream
> quality, pinging the router is not the right thing to do anyway... It
> tests nothing except the direct next hop.
>
> You should most likely have an integrated monitoring scheme:
> - Ping the upstream router
> - Ping some other devices which are upstream
> - Run a DNS probe to 2-3 DNS servers
> - Run an HTTP probe to 10-15 common web services
>
> Then you can use the different metrics to see if something has changed
> compared to the established baseline.
> Without having a baseline, the absolute numbers mean nothing...
>
> Arie
>
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Saku Ytti
> Sent: Wednesday, August 24, 2011 14:31
> To: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] reliability of ping to router physical-, sub- or
> loopback interface
>
> On (2011-08-24 12:03 +0200), Benny Amorsen wrote:
>
>> So please, router vendors, make ICMP ECHO fast and reliable.
>
> I guess it could be nifty to offload this to NPU, and probably most
> modern NPU like EZchip and trio could do it.
>
> However it is unclear to me what are the benefits, ICMP does not provide
> one-way delay measurements, for this you'd need to have IP SLA and
> timestamping in hardware, this is seems much more useful goal to me.
>
> If for NMS purpose you wish to measure customer experienced quality and
> you don't care about one-way delay/jitter, you can already today 'loop'
> packets in hardware via given destination router, by jumping between
> VRF/VRF or VRF/global table. So NMS would send ping packet out, and
> would receive it on another VLAN, router would hardware switch it
> delivering realistic delay/jitter measurements.
>
> --
>  ++ytti
> ___
> 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] 7206VXR NPE-G1 Upgrade from 12.4 to 15.0 High CPU

[Tóth András]

Hi Chris,

You might have reviewed the following doc already, but it might help
to get a few ideas.

Troubleshooting High CPU Utilization in IP Input Process
http://www.cisco.com/en/US/products/hw/routers/ps359/products_tech_note09186a00801c2af3.shtml

Best regards,
Andras

On Mon, Aug 22, 2011 at 10:41 PM, Chris Gotstein  wrote:
> I even disabled the ACLs on the interfaces to see if that was the issue.
>  Didn't help.
>
> On 8/22/2011 3:36 PM, Edward Salonia wrote:
>>
>> Did you double check your config to dee if anything changed or got removed
>> and subsequently saved after your attempt to upgrade to 15M? Sometimes
>> commands/santax changes slightly between versions and a part of your config
>> may not have been carried over.
>>
>> I have also seen situations where one makes changes to a config and
>> forgets to save it. Then a few days/weeks/months down the road, they reboot
>> for one reason or another (sw upgrade for example) and suddenly the change
>> they made previously is gone and no one notices because it was made so long
>> ago and forgotten.
>>
>> Just a thought. Double check you config.
>>
>> I see you made sure CEF was enabled.
>>
>> Another thought, do you have 'log' attached to the end of any ACL's?
>>
>> - Ed
>> -Original Message-
>> From: Chris Gotstein
>> Sender: cisco-nsp-boun...@puck.nether.net
>> Date: Mon, 22 Aug 2011 15:08:23
>> To:
>> Subject: Re: [c-nsp] 7206VXR NPE-G1 Upgrade from 12.4 to 15.0 High CPU
>>
>> Backed down to SRE, but still seeing high utilization on the IP Input
>> process.  Have no idea why this is happening now, thought it was due to
>> the upgrade to 15.0.  But seeing same issue back on SRE.  Anything i can
>> do to troubleshoot?  Running out of ideas.
>>
>> On 8/22/2011 12:21 PM, Chris Gotstein wrote:
>>>
>>> Was looking for the additional IPv6 support in the 15.x train. Can't
>>> find any solution to the problem, so i'll probably just move back down
>>> to SRE4.
>>>
>>> On 8/22/2011 8:09 AM, Mark Tinka wrote:

 On Monday, August 22, 2011 05:18:10 PM Chris Gotstein wrote:

> Any ideas of what could be going on? I haven't
> downgraded the IOS just yet, hoping to see if i might
> have missed something easy. Thanks,

 Don't know anything about how 15.x works on the NPE-G1/G2,
 but we're staying away from it as it doesn't have any
 features we need. SRE4 is nice and happy.

 Mark.
>>>
>>
>
> --
>    
> Chris Gotstein, Network Engineer, U.P. Logon/Computer Connection U.P.
> http://uplogon.com | +1 906 774 4847 | ch...@uplogon.com
> ___
> 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] 24 to 48 port switch supporting HSRPv2 and HSRPv6?

[Tóth András]

Hi Lee,

3750E and 3560E and their X version supports both HSRPv2 and HSRP for
IPv6. Please refer to the Release notes for confirmation on the
following link:
http://www.cisco.com/en/US/docs/switches/lan/catalyst3750x_3560x/software/release/12.2_58_se/release/notes/OL24338.html

IPv6 features supported in the IP services and IP base software
images: ACLs; DHCPv6 for the DCHP server, client, and relay device;
EIGRPv6; HSRPv6; OSPFv3; RIP; Static routes 12.2(50)SE
HSRP Version 2 (HSRPv2) 12.2(46)SE
HSRP for IPv6 (requires the IP services image) 12.2(46)SE

The 4948E switch also supports HSRP v2 and IPv6.
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps6021/ps10947/data_sheet_c78-598933.html


For futher IPv6 features on additional platforms, please visit the
following link:
http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-roadmap.html

Best regards,
Andras


On Wed, Aug 17, 2011 at 11:06 PM, Lee Starnes  wrote:
> Hello,
>
> Can anyone suggest a Cisco 24 or 48 port switch that is 10/100/1000 with
> 1G/10G uplinks and supports HSRPv2 and HSRPv6? Am having some difficulty
> locating switch models with these features using Cisco's site. It looked
> like the 3750E and the 3560E possibly would work, but was not able to
> completely verify this.
>
> 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/
>

___
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 5K optimisation for iSCSI traffic

[Tóth András]

Let me add that my point is more about the rare situation when a
downstream port on the blade switch gets connected (looped) with one
of the upstream FEX switches, then you might face a loop.

FlexLink is indeed better when you have 2 uplinks and you don't want
them both to be active at the same time, I tried to emphasize that
precautions should be taken with FL as well because the active link in
FL is not running STP.

Andras


2011/8/12 Tóth András :
> Hi Brad,
>
> I am not sure that FlexLink is safer than BPDU filter in any way. As
> the Configuration Guide points out, FlexLink will disable STP on the
> interface and it's required to ensure a loop-free topology.
> A port with BPDU filter is behaving in the same way as one with
> FlexLink because neither of them is sending or processing BPDU
> packets, therefore a loop might form. In other words, by connecting 2
> interfaces with FlexLink on them will sustain a loop in the same way
> as 2 interfaces with BPDU filter.
>
> STP is disabled on Flex Link ports. A Flex Link port does not
> participate in STP, even if the VLANs present on the port are
> configured for STP. When STP is not enabled, be sure that there are no
> loops in the configured topology.
> http://www.cisco.com/en/US/docs/switches/blades/3020/software/release/12.2_55_se/configuration/guide/swflink.html#wp1088284
>
> FlexLink can be used with the backup interface being down, it should work 
> fine.
>
> Best regards,
> Andras
>
>
> On Mon, Aug 8, 2011 at 12:41 AM, Brad Hedlund (brhedlun)
>  wrote:
>> Geert,
>>
>>
>>
>> Allow me clarify #2 below, as the way I wrote that was a bit misleading.
>> Thanks for having me look at this again.
>>
>>
>>
>> When you enable BPDU filter on an interface, that interface will not
>> receive or send BPDUs.  It's the equivalent of disabling STP on that
>> interface.
>>
>> This, as you can imagine, may lead to spanning-tree loops between your
>> blade switch and upstream switch(es).  Because, unlike with FlexLinks,
>> additional uplinks added with STP disabled have no state relationship
>> with the other links.
>>
>> At least STP is still protecting the server facing links, so the _risky_
>> rating still remains, as opposed to _dangerous_ in option #3.
>>
>>
>>
>> I'm not sure if you can successfully configure Flex Links with no
>> available backup interface.
>>
>> Perhaps you can define an empty port as the backup?  I don't know.
>>
>>
>>
>> Maybe someone can try it in a lab and let us know?
>>
>>
>>
>> Cheers,
>>
>> Brad
>>
>> http://bradhedlund.com
>>
>>
>>
>>
>>
>>
>>
>> From: Geert Nijs [mailto:geert.n...@gmail.com]
>> Sent: Sunday, August 07, 2011 2:00 PM
>> To: Brad Hedlund (brhedlun)
>> Cc: Matthew Melbourne; cisco-nsp@puck.nether.net
>> Subject: Re: [c-nsp] Nexus 5K optimisation for iSCSI traffic
>>
>>
>>
>> Thanks Brad for this tip.
>> I was experiencing a similar problem where a downstream cisco
>> bladeswitch was preventing ISSU on my N5K (it was not considered an STP
>> edge port).
>> I myself came up with the outbound BPDUfilter solution on the blade
>> switch, but flexlinks might be a safer solution.
>> 1) Could you explain why flexlink is safer than bpdufilter for example ?
>> 2) Can i use flexlinks if my blade switch only has one uplink (ie. there
>> is no backup port) (there is of course another blade switch in the
>> chassis that has an uplink to the alternative switch and blade switches
>> are running
>> link state tracking, i am sure you are familiar with this setup)
>>
>>
>> regards,
>> Geert
>>
>> 2011/8/5 Brad Hedlund (brhedlun) 
>>
>> No. The FEX has BPDU Guard logic running in hardware. The moment a BPDU
>> is received on the port it will be disabled.
>>
>> On the blade switches you can implement:
>> 1) Flex Links (safe)
>> 2) Egress BPDU filter (risky)
>> 3) Disable STP (dangerous)
>>
>> For #2 and #3, a misconfigured or missing LACP config can cause a loop.
>> For #3, a misconfigured server NIC teaming can cause a loop.
>>
>> Cheers,
>> Brad
>> http://bradhedlund.com
>>
>> Sent from my iPad
>> (please excuse brevity, typos)
>>
>> On Aug 5, 2011, at 9:49 AM, "Matthew Melbourne" 
>> wrote:
>>
>>> Can P prevent a FEX port being disabled by implementing bpdufilter, or
>>> do we need to ensure that BPDUs aren't receiving on FEX ports?
>>>
&

Re: [c-nsp] DOM support on catalyst 4948 10GE

[Tóth András]

Hi Ruslan,

Try upgrading the ROMMON to at least 12.2(31r)SGA4 or if possible to
12.2(44r)SG5.

Best regards,
Andras


On Thu, Aug 11, 2011 at 4:18 PM, Ruslan Pustovoitov
 wrote:
> Hi all
>
> I need for digital diagnostic monitoring 10GE ports on Catalyst 4948
> 10GE switch.
> I check cisco web site -
> http://www.cisco.com/en/US/docs/interfaces_modules/transceiver_modules/compatibility/matrix/OL_6974.html
>
> and see that recommended ios is 12.2.54SG.
> Current rommon version.is 12.2(31r)SGA1. It is compatible with ios
> 12.2.54SG.
> When I try to upgrade ios from 12.2.46SG to 12.2.54SG, switch is stayed
> in rommon with error "Unexpected error in rommon" on console.
>
> Where I did the error ?
>
>
> ___
> 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] DOM support on catalyst 4948 10GE

[Tóth András]

Hi Ruslan,

Try upgrading the ROMMON to at least 12.2(31r)SGA4 or if possible to
12.2(44r)SG5.

Best regards,
Andras


On Thu, Aug 11, 2011 at 12:14 PM, Ruslan Pustovoytov  wrote:
> Hi all
>
> I need for digital diagnostic monitoring 10GE ports on Catalyst 4948 10GE
> switch.
> I check cisco web site -
> http://www.cisco.com/en/US/docs/interfaces_modules/transceiver_modules/compatibility/matrix/OL_6974.html
> and see that recommended ios is 12.2.54SG.
> Current rommon version.is 12.2(31r)SGA1. It is compatible with ios
> 12.2.54SG.
> When I try to upgrade ios from 12.2.46SG to 12.2.54SG, switch is stayed in
> rommon with error "Unexpected error in rommon" on console.
>
> Where I did the error ?
>
>
>
> ___
> 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 5K optimisation for iSCSI traffic

[Tóth András]

Hi Brad,

I am not sure that FlexLink is safer than BPDU filter in any way. As
the Configuration Guide points out, FlexLink will disable STP on the
interface and it's required to ensure a loop-free topology.
A port with BPDU filter is behaving in the same way as one with
FlexLink because neither of them is sending or processing BPDU
packets, therefore a loop might form. In other words, by connecting 2
interfaces with FlexLink on them will sustain a loop in the same way
as 2 interfaces with BPDU filter.

STP is disabled on Flex Link ports. A Flex Link port does not
participate in STP, even if the VLANs present on the port are
configured for STP. When STP is not enabled, be sure that there are no
loops in the configured topology.
http://www.cisco.com/en/US/docs/switches/blades/3020/software/release/12.2_55_se/configuration/guide/swflink.html#wp1088284

FlexLink can be used with the backup interface being down, it should work fine.

Best regards,
Andras


On Mon, Aug 8, 2011 at 12:41 AM, Brad Hedlund (brhedlun)
 wrote:
> Geert,
>
>
>
> Allow me clarify #2 below, as the way I wrote that was a bit misleading.
> Thanks for having me look at this again.
>
>
>
> When you enable BPDU filter on an interface, that interface will not
> receive or send BPDUs.  It's the equivalent of disabling STP on that
> interface.
>
> This, as you can imagine, may lead to spanning-tree loops between your
> blade switch and upstream switch(es).  Because, unlike with FlexLinks,
> additional uplinks added with STP disabled have no state relationship
> with the other links.
>
> At least STP is still protecting the server facing links, so the _risky_
> rating still remains, as opposed to _dangerous_ in option #3.
>
>
>
> I'm not sure if you can successfully configure Flex Links with no
> available backup interface.
>
> Perhaps you can define an empty port as the backup?  I don't know.
>
>
>
> Maybe someone can try it in a lab and let us know?
>
>
>
> Cheers,
>
> Brad
>
> http://bradhedlund.com
>
>
>
>
>
>
>
> From: Geert Nijs [mailto:geert.n...@gmail.com]
> Sent: Sunday, August 07, 2011 2:00 PM
> To: Brad Hedlund (brhedlun)
> Cc: Matthew Melbourne; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Nexus 5K optimisation for iSCSI traffic
>
>
>
> Thanks Brad for this tip.
> I was experiencing a similar problem where a downstream cisco
> bladeswitch was preventing ISSU on my N5K (it was not considered an STP
> edge port).
> I myself came up with the outbound BPDUfilter solution on the blade
> switch, but flexlinks might be a safer solution.
> 1) Could you explain why flexlink is safer than bpdufilter for example ?
> 2) Can i use flexlinks if my blade switch only has one uplink (ie. there
> is no backup port) (there is of course another blade switch in the
> chassis that has an uplink to the alternative switch and blade switches
> are running
> link state tracking, i am sure you are familiar with this setup)
>
>
> regards,
> Geert
>
> 2011/8/5 Brad Hedlund (brhedlun) 
>
> No. The FEX has BPDU Guard logic running in hardware. The moment a BPDU
> is received on the port it will be disabled.
>
> On the blade switches you can implement:
> 1) Flex Links (safe)
> 2) Egress BPDU filter (risky)
> 3) Disable STP (dangerous)
>
> For #2 and #3, a misconfigured or missing LACP config can cause a loop.
> For #3, a misconfigured server NIC teaming can cause a loop.
>
> Cheers,
> Brad
> http://bradhedlund.com
>
> Sent from my iPad
> (please excuse brevity, typos)
>
> On Aug 5, 2011, at 9:49 AM, "Matthew Melbourne" 
> wrote:
>
>> Can P prevent a FEX port being disabled by implementing bpdufilter, or
>> do we need to ensure that BPDUs aren't receiving on FEX ports?
>>
>> We were hoping to use LACP between the downstream switch and the FEXes
>> as a poor-man's loop prevention mechanism.
>>
>> Cheers,
>>
>> Matt
>>
>> On 5 August 2011 15:17, John Gill  wrote:
>>> It would be filter toward the FEX ports on your blade switches, but
> not on
>>> the FEX ports themselves. Whether you turn STP off or not on the
> blades, the
>>> FEX doesn't know. Just remembering if you create a loop, you no
> longer have
>>> the protection of STP; you are intentionally tricking the FEX into
> not
>>> knowing there is a switch downstream.
>>>
>>> Regards,
>>> John Gill
>>> cisco
>>>
>>> On 8/5/11 9:59 AM, Matthew Melbourne wrote:

 Thanks for that - that's another issue we've encountered. I am
> hoping
 we can implement bpdufilter on the FEX ports (as well as disabling
> STP
 on downstream switches).

 On 5 August 2011 14:12, Brad Hedlund (brhedlun)
  wrote:
>
> Note that the FEX will disable any port that receives a BPDU, by
> design
> in hardware.  You will need to disable STP on the
> blade-switch-to-FEX links
> for this to work. If it's Cisco blade switches you can use Flex
> Links.
>
> Cheers,
> Brad
> http://bradhedlund.com
>
> Sent from my iPad
> (please excuse brevity, typos)
>
> On Aug 5, 2011, 

Re: [c-nsp] Host xxxx.xxxx.xxxx in vlan x is flapping between port Po1 and port Gi0/1

[Tóth András]

Hi,

The switch found the traffic from the specified host flapping between
the specified ports. [enet] is the host MAC address, [chars] [dec] is
the switch ID, the first and second [chars] are the ports between
which the host traffic is flapping.

Recommended Action: Check the network switches for misconfigurations
that might cause a data-forwarding loop.

http://www.cisco.com/cgi-bin/Support/Errordecoder/index.cgi?action=search&index=all&locale=en&query=SW_MATM-4-MACFLAP_NOTIF&counter=0&paging=5&links=reference&sa=Submit

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080136673.shtml

Best regards,
Andras


On Sun, Aug 7, 2011 at 7:14 PM, Farooq Razzaque  wrote:
>
>
> Hi All
>
> I noticed the following messages with different timestamp on IPT SW01 
> (connected to IPT servers - C2960G-24TC-L)
>
>
>
> %SW_MATM-4-MACFLAP_NOTIF: Host 001c.f6e5.17b0 in vlan 119 is flapping between 
> port Po1 and port Gi0/1
>
> Here :
>
> 1) Gi0/1 is connected to Voice Gateway router
>
> interface GigabitEthernet0/0 (Connected to IPT SW02 - Gi0/1)
>  no ip address
>  duplex auto
>  speed auto
>  media-type rj45
>  bridge-group 1
> !
> interface GigabitEthernet0/1  (Connected to IPT SW01 - Gi0/1)
>  no ip address
>  duplex auto
>  speed auto
>  media-type rj45
>  bridge-group 1
>
> interface BVI1
>  ip address x
>  ntp broadcast client
>  ntp broadcast
>  h323-gateway voip interface
>  h323-gateway voip bind srcaddr x
>
> 2) Mac-address 001c.f6e5.17b0 is the address of interface Gi0/0 of Voice 
> Gateway Router and same address for BVI1
>
> GigabitEthernet0/0 is up, line protocol is up
>  Hardware is BCM1125 Internal MAC, address is 001c.f6e5.17b0 (bia 
> 001c.f6e5.17b0)
>
> GigabitEthernet0/1 is up, line protocol is up
>  Hardware is BCM1125 Internal MAC, address is 001c.f6e5.17b1 (bia 
> 001c.f6e5.17b1)
>
> BVI1 is up, line protocol is up
>  Hardware is BVI, address is 001c.f6e5.17b0 (bia 001c.f6e5.17b0)
>
> 3) Po1 is the port channel on IPT SW01 (Gi0/22 and Gi0/23) and Core switch 
> (VSS)
>
>
> interface GigabitEthernet0/22
> description  L2 Trunk to Coreswitch 
>  switchport trunk native vlan 999
>  switchport trunk allowed vlan 119
>  switchport mode trunk
>  logging event trunk-status
>  logging event bundle-status
>  channel-protocol lacp
>  channel-group 1 mode active
> !
> interface GigabitEthernet0/23
> description  L2 Trunk to Coreswitch 
>  switchport trunk native vlan 999
>  switchport trunk allowed vlan 119
>  switchport mode trunk
>  logging event trunk-status
>  logging event bundle-status
>  channel-protocol lacp
>  channel-group 1 mode active
>
> Appreciate your help
>
> ___
> 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] This week in cisco site

[Tóth András]

Hi,

Additionally, the following documentations have been added on the
Cisco.com website for the Nexus 7000 Switches.

LISP Configuration Guide
http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/lisp/configuration/guide/b_NX-OS_LISP_Configuration_Guide.html

FCoE Configuration Guide
http://www.cisco.com/en/US/docs/switches/datacenter/sw/nx-os/fcoe/configuration_guide/b_Cisco_NX-OS_FCoE_Configuration_Guide.html

SAN Switching Configuration Guide
http://www.cisco.com/en/US/docs/switches/datacenter/sw/nx-os/san_switching/configuration/guide/b_Cisco_Nexus_7000_NX-OS_SAN_Switching_Configuration_Guide.html

And the rest of the configuration guide updates are at the following link:
http://www.cisco.com/en/US/products/ps9402/products_installation_and_configuration_guides_list.html

Best regards,
Andras


On Sun, Jul 31, 2011 at 7:52 PM, Nitzan Tzelniker
 wrote:
> This week Cisco release 3 major versions for ASR1K ME3800 and Nexus 7000.
> but they think we can configure these features without
> any configuration guide
>
> 1. For the Nexus there is no configuration guide for the
> new features (mpls/fcoe ...)
> 2. For the ME3800 the release notes send you to the overview in the not
> yet released configuration guide to see the new features (I think its
> the first time I don't see it in the release notes).
>
> "This release is the second software release for the Cisco ME 3800X and ME
> 3600X switch. For a detailed list of key features for this software release,
> refer to the "Overview" chapter of the software configuration guide for this
> release."
>
> 3. in the ASR1K 3.4 release notes there are so many broken links for
> example
>
> http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_pi/xe-3s/loop-free-alternate-fast-reroute.html
> http://www.cisco.com/en/US/docs/ios-xml/ios/ipaddr_nat/configuration/xe-3s/Stateful_Network_Address_Translation_64.html
>
> Nitzan
> ___
> 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] This week in cisco site

[Tóth András]

Hi,

ere are links to the Nexus 7000 MPLS configuration guide and command
reference on Cisco.com:

http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/mpls/configuration/guide/mpls_cg.html

http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/mpls/command/reference/mpls_cr.html

Best regards,
Andras


On Sun, Jul 31, 2011 at 7:52 PM, Nitzan Tzelniker
 wrote:
> This week Cisco release 3 major versions for ASR1K ME3800 and Nexus 7000.
> but they think we can configure these features without
> any configuration guide
>
> 1. For the Nexus there is no configuration guide for the
> new features (mpls/fcoe ...)
> 2. For the ME3800 the release notes send you to the overview in the not
> yet released configuration guide to see the new features (I think its
> the first time I don't see it in the release notes).
>
> "This release is the second software release for the Cisco ME 3800X and ME
> 3600X switch. For a detailed list of key features for this software release,
> refer to the "Overview" chapter of the software configuration guide for this
> release."
>
> 3. in the ASR1K 3.4 release notes there are so many broken links for
> example
>
> http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_pi/xe-3s/loop-free-alternate-fast-reroute.html
> http://www.cisco.com/en/US/docs/ios-xml/ios/ipaddr_nat/configuration/xe-3s/Stateful_Network_Address_Translation_64.html
>
> Nitzan
> ___
> 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] This week in cisco site

[Tóth András]

Hi,

I was told that the documentations for Nexus 7000 should be available
by Monday morning (US time).

Andras


On Sun, Jul 31, 2011 at 7:52 PM, Nitzan Tzelniker
 wrote:
> This week Cisco release 3 major versions for ASR1K ME3800 and Nexus 7000.
> but they think we can configure these features without
> any configuration guide
>
> 1. For the Nexus there is no configuration guide for the
> new features (mpls/fcoe ...)
> 2. For the ME3800 the release notes send you to the overview in the not
> yet released configuration guide to see the new features (I think its
> the first time I don't see it in the release notes).
>
> "This release is the second software release for the Cisco ME 3800X and ME
> 3600X switch. For a detailed list of key features for this software release,
> refer to the "Overview" chapter of the software configuration guide for this
> release."
>
> 3. in the ASR1K 3.4 release notes there are so many broken links for
> example
>
> http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_pi/xe-3s/loop-free-alternate-fast-reroute.html
> http://www.cisco.com/en/US/docs/ios-xml/ios/ipaddr_nat/configuration/xe-3s/Stateful_Network_Address_Translation_64.html
>
> Nitzan
> ___
> 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] how do keepalive frames work

[Tóth András]

Hi Martin,

I cannot comment on the 2900 switches, as it's very old and not
supported anyway by Cisco. On the 2950 switches, when keepalives are
enabled and looping condition is detected, the interface will be
err-disabled, this is an expected behavior. For more information,
please visit the below documentations.

Refer to the "Loopback error" section on the following link:
http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00806cd87b.shtml

Refer to the "%ETHCNTR-3-LOOP_BACK_DETECTED : Keepalive packet
loop-back detected on [chars]" section here:
http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00801b42bf.shtml#prob1b

I guess you can read more about Type 2 cabling on the following link.
http://www.cisco.com/en/US/products/hw/gatecont/ps2250/products_tech_note09186a008009452e.shtml#ii

Best regards,
Andras


2011/7/31 Martin T :
> András,
> under IOS one can configure "keepalive" settings of Fa/Gi/Te
> interfaces of Cisco 4500 and Fa ports of Cisco 2900 series as well,
> but as much as I tested with 2900 series, while keepalive frames are
> actually sent, in case of loop(I made a RJ45 hardware loop), the port
> is not shut down.
>
> On the other hand, in case of Cisco 2950, the keepalive frame indeed
> forced port to "err-disabled" state when I plugged my RJ45
> hardware-loop into the port:
>
> 00:06:53: %SYS-5-CONFIG_I: Configured from console by console
> 00:06:55: %ETHCNTR-3-LOOP_BACK_DETECTED: Keepalive packet loop-back
> detected on FastEthernet0/2.
> 00:06:55: %PM-4-ERR_DISABLE: loopback error detected on Fa0/2, putting
> Fa0/2 in err-disable state
> 00:06:56: %LINEPROTO-5-UPDOWN: Line protocol on Interface
> FastEthernet0/2, changed state to down
> 00:06:57: %LINK-3-UPDOWN: Interface FastEthernet0/2, changed state to down
>
> When I set "no keepalive" to this very same switch port under C2950
> and connect the same RJ45 hardware loop, the port stayed up.
>
> By "Type 2" cabling you mean so-called "Cat2"(Two shielded twisted
> pairs + four voice grade twisted pairs) cabling? And the idea is that
> in case there is a loop on physical layer, the switch port receives a
> keepalive frame with it's own MAC address as a destination and source
> address and shuts down the port?
> In the light of modern cabling standards, the "keepalive" feature
> isn't very useful, is it?
>
> regards,
> martin
>
> 2011/7/31 Tóth András :
>> Hi Martin,
>>
>> Keepalives are sent on the Catalyst 2940, 2950, 2950-LRE, 2955, 2970,
>> 3550, 3560 or 3750 switch to prevent loops in the network. The primary
>> reason for the keepalives is to prevent loops as a result of Type 2
>> cabling which does cause a loop in some situations. A loop is detected
>> when the switch receives back it's own keepalive pakcet.
>>
>> Keepalives are sent on ALL interfaces by default in 12.1EA based
>> software. Starting in 12.2SE based releases, keepalives are NO longer
>> sent by default on fiber and uplink interfaces.
>>
>> Best regards,
>> Andras
>>
>>
>> On Sun, Jul 31, 2011 at 3:51 AM, Martin T  wrote:
>>> I have a following connection:
>>>
>>> T60[eth0] <-> [Fa0/2]WS-C2950C-24
>>>
>>> ..and port Fa0/2 in the switch in configured like this:
>>>
>>> WS-C2950C-24#sh run int Fa0/2
>>> Building configuration...
>>>
>>> Current configuration : 149 bytes
>>> !
>>> interface FastEthernet0/2
>>>  description -> T60
>>>  switchport mode access
>>>  switchport nonegotiate
>>>  no cdp enable
>>>  spanning-tree bpdufilter enable
>>> end
>>>
>>> WS-C2950C-24#
>>>
>>> ..and "keepalive" signals are sent after every 10s:
>>>
>>> WS-C2950C-24#sh int Fa0/2 | i Keepalive
>>>  Keepalive set (10 sec)
>>> WS-C2950C-24#
>>>
>>> Now if I tcpdump those frames, they look like this:
>>>
>>> root@martin-ThinkPad-T60:~# tcpdump -i eth0 -e -XX -c 4
>>> tcpdump: WARNING: eth0: no IPv4 address assigned
>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>>> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
>>> 03:26:35.984629 00:12:7f:13:8f:c2 (oui Unknown) > 00:12:7f:13:8f:c2
>>> (oui Unknown), ethertype Loopback (0x9000), length 60:
>>>        0x:  0012 7f13 8fc2 0012 7f13 8fc2 9000   
>>>        0x0010:  0100         
>>>        0x0020:   

Re: [c-nsp] how do keepalive frames work

[Tóth András]

Hi Martin,

Keepalives are sent on the Catalyst 2940, 2950, 2950-LRE, 2955, 2970,
3550, 3560 or 3750 switch to prevent loops in the network. The primary
reason for the keepalives is to prevent loops as a result of Type 2
cabling which does cause a loop in some situations. A loop is detected
when the switch receives back it's own keepalive pakcet.

Keepalives are sent on ALL interfaces by default in 12.1EA based
software. Starting in 12.2SE based releases, keepalives are NO longer
sent by default on fiber and uplink interfaces.

Best regards,
Andras


On Sun, Jul 31, 2011 at 3:51 AM, Martin T  wrote:
> I have a following connection:
>
> T60[eth0] <-> [Fa0/2]WS-C2950C-24
>
> ..and port Fa0/2 in the switch in configured like this:
>
> WS-C2950C-24#sh run int Fa0/2
> Building configuration...
>
> Current configuration : 149 bytes
> !
> interface FastEthernet0/2
>  description -> T60
>  switchport mode access
>  switchport nonegotiate
>  no cdp enable
>  spanning-tree bpdufilter enable
> end
>
> WS-C2950C-24#
>
> ..and "keepalive" signals are sent after every 10s:
>
> WS-C2950C-24#sh int Fa0/2 | i Keepalive
>  Keepalive set (10 sec)
> WS-C2950C-24#
>
> Now if I tcpdump those frames, they look like this:
>
> root@martin-ThinkPad-T60:~# tcpdump -i eth0 -e -XX -c 4
> tcpdump: WARNING: eth0: no IPv4 address assigned
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
> 03:26:35.984629 00:12:7f:13:8f:c2 (oui Unknown) > 00:12:7f:13:8f:c2
> (oui Unknown), ethertype Loopback (0x9000), length 60:
>        0x:  0012 7f13 8fc2 0012 7f13 8fc2 9000   
>        0x0010:  0100         
>        0x0020:           
>        0x0030:                   
> 03:26:45.984971 00:12:7f:13:8f:c2 (oui Unknown) > 00:12:7f:13:8f:c2
> (oui Unknown), ethertype Loopback (0x9000), length 60:
>        0x:  0012 7f13 8fc2 0012 7f13 8fc2 9000   
>        0x0010:  0100         
>        0x0020:           
>        0x0030:                   
> 03:26:55.984277 00:12:7f:13:8f:c2 (oui Unknown) > 00:12:7f:13:8f:c2
> (oui Unknown), ethertype Loopback (0x9000), length 60:
>        0x:  0012 7f13 8fc2 0012 7f13 8fc2 9000   
>        0x0010:  0100         
>        0x0020:           
>        0x0030:                   
> 03:27:05.984651 00:12:7f:13:8f:c2 (oui Unknown) > 00:12:7f:13:8f:c2
> (oui Unknown), ethertype Loopback (0x9000), length 60:
>        0x:  0012 7f13 8fc2 0012 7f13 8fc2 9000   
>        0x0010:  0100         
>        0x0020:           
>        0x0030:                   
> 4 packets captured
> 4 packets received by filter
> 0 packets dropped by kernel
> root@martin-ThinkPad-T60:~#
>
> As you can see, they are sent by switch port after every 10s. The
> source and destination MAC address are the same and ethertype is
> 0x9000 and it looks like the frame is just padded with zeros. I can
> change the keepalive messages interval between 1s and 32767s or
> disable keepalive frames by "no keepalive" or "keepalive 0".
> What are those "keepalive" frames used for? Some historical
> configuration setting? What should my T60 NIC do with those frames as
> at the moment it responds nothing?
>
>
> 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/

Re: [c-nsp] Load balancing on Portchan.

[Tóth András]

Hi,

The input and output rate being 0 on port-channel is caused by
software defect CSCsz18634 and it's fixed in 12.2(53)SE and later.


I would recommend to review the following documentations for more
details and examples about etherchannel load balancing.

Understanding EtherChannel Load Balancing and Redundancy on Catalyst Switches
http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186a0080094714.shtml

Load Balancing and Forwarding Methods
http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_55_se/configuration/guide/swethchl.html#wp1275731

Best regards,
Andras


On Fri, Jul 29, 2011 at 6:32 AM,   wrote:
> Hi,
>
> Have 2 100Mb eth ports in portchan, and 1 port seems to be doing all the
> receiving:
>
> sh interfaces fastEthernet 0/1
> FastEthernet0/1 is up, line protocol is up (connected)  Hardware is Fast
> Ethernet, address is f4ac.c17d.af83 (bia f4ac.c17d.af83)
>  Description: FEC_TO_ESW01_P20
>  MTU 1998 bytes, BW 10 Kbit, DLY 100 usec,     reliability 255/255,
> txload 165/255, rxload 217/255
> ...  5 minute input rate 85322000 bits/sec, 13875 packets/sec
>  5 minute output rate 65048000 bits/sec, 12044 packets/sec
>
> FastEthernet0/2 is up, line protocol is up (connected)  Hardware is Fast
> Ethernet, address is f4ac.c17d.af84 (bia f4ac.c17d.af84)
>  Description: FEC_TO_ESW01_P21
>  MTU 1998 bytes, BW 10 Kbit, DLY 100 usec,     reliability 255/255,
> txload 52/255, rxload 2/255
> ...
>  5 minute input rate 871000 bits/sec, 229 packets/sec
>  5 minute output rate 20396000 bits/sec, 3718 packets/sec
>
>
> The portchan doesnt report any usage(reports packets/bytes etc just not data
> rate or tx/rx)) for some reason on the 3560(the 2950 does though)
>
> #sh int port-channel 2
> Port-channel2 is up, line protocol is up (connected)  Hardware is
> EtherChannel, address is f4ac.c17d.af84 (bia f4ac.c17d.af84)
>  Description: FEC_TO_ESW01_BNE
>  MTU 1998 bytes, BW 20 Kbit, DLY 100 usec,     reliability 255/255,
> txload 1/255, rxload 0/255
>  Encapsulation ARPA, loopback not set
>  Keepalive set (10 sec)
>  Full-duplex, 100Mb/s, link type is auto, media type is unknown
>  input flow-control is off, output flow-control is unsupported  Members in
> this channel: Fa0/1 Fa0/2  ARP type: ARPA, ARP Timeout 04:00:00
>  Last input 16:49:20, output 00:00:00, output hang never
>  Last clearing of "show interface" counters 16:31:53
>  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 670097
>  Queueing strategy: fifo
>  Output queue: 0/40 (size/max)
>  5 minute input rate 0 bits/sec, 0 packets/sec
>  5 minute output rate 0 bits/sec, 0 packets/sec
>    654778461 packets input, 542298725539 bytes, 0 no buffer
>    Received 576270 broadcasts (124103 multicasts)
>    0 runts, 0 giants, 0 throttles
>    0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
>    0 watchdog, 124103 multicast, 0 pause input
>    0 input packets with dribble condition detected
>    1141651151 packets output, 665041631494 bytes, 0 underruns
>    0 output errors, 0 collisions, 0 interface resets
>    0 babbles, 0 late collision, 0 deferred
>    0 lost carrier, 0 no carrier, 0 PAUSE output
>    0 output buffer failures, 0 output buffers swapped out
>
> ...
>
> Any suggestions on how to balance the traffic better?
>
> switches are 3560+2950
>
> Thanks in advance.
>
> -
> This e-mail was sent via GCOMM WebMail http://www.gcomm.com.au/
>
>
> ___
> 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] changing buffer size on 4900M - discards

[Tóth András]

Hi Holemans,

The Catalyst 4900M Series can be deployed for 10/100/1000 server
access with 1:1 uplink to downlink oversubscription, mix of
10/100/1000 and 10 GbE
servers or all 10GbE servers in the same rack. The output drops are
caused by the egress buffers filling before the interface is able to
forward the traffic which could be caused by bursty traffic, although
the average rate is lower than 2 Gbps.

I would recommend to investigate if there are short bursts coming from
the 10G link which can cause the drops.
Also, check if you have flow-control coming from the 2G channel, which
can also cause output drops. Try disabling ingress flow-control on the
2G channel members and see if that resolves the issue.


Additionally, if the above does not help, I would suggest to check the
Queue-limiting and Queue Memory sections in the QoS guide:
http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/54sg/configuration/guide/qos.html#wp1437305
http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/54sg/configuration/guide/qos.html#wp1522202

Increase the queue limit gradually with the 'queue-limit'
configuration command under the policy-map class section. You might
try changing it straight to 512. If no policy-maps are configured yet,
create a new one and use queue-limit in class-default, then apply the
policy-map to the egress interface.

Best regards,
Andras


On Wed, Jul 27, 2011 at 1:35 PM, Holemans Wim  wrote:
> We are seeing discards on a newly installed 4900M, probably coming from the 
> fact that most input to the C4900M is coming from routers connected to it on 
> 10G lines and is going out on a 2G etherchannel, although the total load on 
> the 2G channel is just about 250-300 Mb/s. The 2G connection goes to an IPS 
> that will be replaced before the end of the year but until then I have to 
> find a way around the discards.
> Based on the fact that the 4900M is normally mentioned as a switch with a 
> good buffer capacity (compared to 37xx switches, see also threads of begin 
> this week), I wonder if  there is a way to change buffer size on the gigabit 
> interfaces so that there will be less discards ? Anyone has a reference to a 
> good document on buffer tuning (on 4900M) ? I know the 'buffers' command 
> exists but for the moment I'm still trying to find out what buffers I should 
> change (and into which values) to get rid of these discards.
>
> Greetings,
>
> Wim Holemans
> Netwerkdienst Universiteit Antwerpen
> Network Services University of Antwerp
>
> ___
> 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] memory leaking in IOS 12.2(58)SE1 on 2960's

[Tóth András]

Hi Jiri,

When you mention logs are useless, do you mean you did not find
anything in the logs after logging on to the switch which freed up
some memory?

Any chance to collect the following command from the switch which
freed up some memory during the night?
sh mem allocating-process totals

This might sound stupid but can you confirm by looking at the uptime
that the switch did not crash? If it did, please collect the crashinfo
files and send them so I can take a look.

While monitoring the memory usage, if you see regular increase,
collect the following commands several times so you can compare them
later to see which process allocates most memory.
sh proc mem sorted
sh mem allocating-process totals


Best regards,
Andras


On Wed, Jul 20, 2011 at 1:22 PM, Jiri Prochazka
 wrote:
> Hi Andras,
>
> All I was able to get from the switch was '%% Low on memory; try again
> later', so I had no chance to get any usefull info.
>
> None of them really crashed, even now (a few days after the issue raised)
> all are forwarding everything without any interruption. The only (doh)
> problem is that they are refusing any remote/local management.
>
> We have aproximately 40 2960's in our network, all were upgraded to
> 12.2(58)SE1 at the same night 42 days ago. Till this day four of them have
> shown this error (first one a week ago, the rest during the last 7 days).
>
> I will definitely implement graphing of memory usage and monitor this. Logs
> are useless, as there is absolutely none info regarding to this behaviour.
>
>
> update: Wow, one of 'crashed' switches surprisingly managed to free some
> memory over the night and there is no problem with remote login now!
>
> DC.Cisco.138#show mem
>                Head    Total(b)     Used(b)     Free(b)   Lowest(b)
> Largest(b)
> Processor    27A819C    21585348    19502124     2083224     1330816
>  1396804
>      I/O    2C0     4194304     2385892     1808412     1647292
> 1803000
> Driver te    1A0     1048576          44     1048532     1048532
>  1048532
>
>
>
> DC.Cisco.138#show proc mem sorted
> Processor Pool Total:   21585348 Used:   19506548 Free:    2078800
>      I/O Pool Total:    4194304 Used:    2385788 Free:    1808516
> Driver te Pool Total:    1048576 Used:         40 Free:    1048536
>
>  PID TTY  Allocated      Freed    Holding    Getbufs    Retbufs Process
>   0   0   20966064    3684020   13930872          0          0 *Init*
>   0   0  349880992  303545656    1758488    4520010     421352 *Dead*
>   0   0          0          0     722384          0          0 *MallocLite*
>  67   0     531728      17248     463548          0          0 Stack Mgr
> Notifi
>  81   0     488448        232     332392          0          0 HLFM address
> lea
>  104   0    6002260    6886956     234548          0          0 HACL Acl
> Manager
>  151   0    1161020     437668     214108          0          0 DTP Protocol
>  59   0     198956   34501644     208516          0          0 EEM ED ND
>  163   0     196740          0     203900          0          0 VMATM
> Callback
>  219   0     775680   39872788     186548          0          0 MLDSN L2MCM
>  16   0     312148     762860     145736          0     104780 Entity MIB
> API
>
>
>
> Thank you,
>
>
> Jiri
>
>
>
> Dne 20.7.2011 0:08, Tóth András napsal(a):
>>
>> Hi Jiri,
>>
>> Did you have a chance to collect the output of 'sh log' after logging
>> in via console? If yes, please send it over.
>> Did you observe a crash of the switch or only the error message?
>> How many times did you see this so far? How often is it happening?
>> How many 2960 switches running 12.2(58)SE1 do you have in total and on
>> how many did you see this?
>>
>> If the switch is working fine now, I would recommend monitoring the
>> memory usage and the rate of increase. Check the logs around that time
>> to see if you find anything related, such as dot1x errors, etc.
>>
>> Also, consider collecting the following commands when the error
>> message is seen again and open a Cisco TAC case if possible.
>> sh log
>> sh proc mem sorted
>> sh mem summary
>> sh mem allocating-process totals
>> sh tech
>>
>> Best regards,
>> Andras
>>
>>
>> On Tue, Jul 19, 2011 at 4:34 PM, Jiri Prochazka
>>   wrote:
>>>
>>> Hi,
>>>
>>> a month ago I have upgraded a few dozens of our access layer 2960's to
>>> the
>>> latest version of IOS (12.2(58)SE1) and during the last few days three of
>>> these upgraded switches suddently have stopped responding to SSH&  telnet
>>> access. Tra

Re: [c-nsp] memory leaking in IOS 12.2(58)SE1 on 2960's

[Tóth András]

Hi Jiri,

Did you have a chance to collect the output of 'sh log' after logging
in via console? If yes, please send it over.
Did you observe a crash of the switch or only the error message?
How many times did you see this so far? How often is it happening?
How many 2960 switches running 12.2(58)SE1 do you have in total and on
how many did you see this?

If the switch is working fine now, I would recommend monitoring the
memory usage and the rate of increase. Check the logs around that time
to see if you find anything related, such as dot1x errors, etc.

Also, consider collecting the following commands when the error
message is seen again and open a Cisco TAC case if possible.
sh log
sh proc mem sorted
sh mem summary
sh mem allocating-process totals
sh tech

Best regards,
Andras


On Tue, Jul 19, 2011 at 4:34 PM, Jiri Prochazka
 wrote:
> Hi,
>
> a month ago I have upgraded a few dozens of our access layer 2960's to the
> latest version of IOS (12.2(58)SE1) and during the last few days three of
> these upgraded switches suddently have stopped responding to SSH & telnet
> access. Traffic coming from/to ports is still regulary forwarded.
>
> Connecting over the serial port gives me '%% Low on memory; try again later'
> into the log. The only solution I came to is to reload the switch.
>
>
> Does anybody else have similar problem with this version of IOS?
>
>
> As far as I know, we don't use any special configuration. One feature is
> nearly hitting the limit (127 STP instances), but we didn't have any
> problems with this so far.
>
>
>
> Thank you for your thoughts.
>
>
>
> --
> ---
>
> Kind regards,
>
>
> Jiri Prochazka
>
> ___
> 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/