[c-nsp] C7600/ES+ double tagged termination issue

[Walter Keen]

Having some problems with TAC troubleshooting this one.

Wondering if anyone has run into this before

It's a 7606 with an RSP720-3cxl and ES+20g card terminating double tagged 
traffic as well as pppoe users.  double tagged traffic is terminated using 
'access' subinterfaces referencing a unnumbered loopback setup with helper 
addresses pointing to an external dhcp cluster.  

I keep having issues with the double tagged connections, almost like it stops 
receiving the data, however pppoe users haven't noted any impact yet.

once this message appears in the logs, it appears to start working again.
TAC seems to be having trouble finding what this message might indicate


Log Buffer (8192 bytes):
FCC8, name: AVLDup list), having 1 elements -Process= "SSM connection manager", 
ipl= 0, pid= 190
-Traceback= 817B420 832CD28 9718290 9264350 92657F8 9265CE4 9265DFC 96BAE20 
8A6AD4C 9725880 972592C 8A6B8C4 8A6BAA8 8A5B694 8A5B7DC 9725880
*Sep 20 12:01:10.191: %SYS-DFC2-3-BADLIST_DESTROY: Removed a non-empty 
list(19A4FB60, name: AVLDup list), having 1 elements -Process= "SSM connection 
manager", ipl= 0, pid= 190
-Traceback= 817B420 832CD28 9718290 9264350 92657F8 9265CE4 9265DFC 96BAE20 
8A6AD4C 9725880 972592C 8A6B8C4 8A6BAA8 8A5B694 8A5B7DC 9725880
*Sep 20 12:01:10.771: %SYS-DFC2-3-BADLIST_DESTROY: Removed a non-empty 
list(2D487D60, name: AVLDup list), having 1 elements -Process= "SSM connection 
manager", ipl= 0, pid= 190




Walter Keen
Network Engineer
Rainier Connect

___
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] mitigate output drops on Cisco 2960G platform

[Blake Dunlap]

Making the linux box slower in the ways described (other than packet
pacing) would just increase the cpu load. If those are feeder servers,
you're much better off dropping the link speed to 100m or configuring TC
outbound than turning off a lot of the cpu offloading.

Or alternately, not trying to connect 10 servers at 1g to a budget access
layer switch with a single 1g uplink. If you don't want oversubscription,
don't oversubscribe

-Blake


On Fri, Sep 20, 2013 at 4:29 PM, Joerg Mayer  wrote:

> On Fri, Sep 20, 2013 at 07:23:17PM +0100, Phil Mayers wrote:
> > (However: I wonder if the various techniques being discussed
> > elsewhere - like the new Linux kernel packet pacing, disabling TCP
> > segmentation offload and reducing nic ring, kernel and app buffers -
> > might alleviate the generation of microbursts?)
>
> As long as your problems are TCP related yes, things should be getting
> less bad. If you have UDP traffic (think videostreaming, I-frames), you
> don't get that help.
>
> Ciao
>J\303\266rg
>
> --
> Joerg Mayer   
> We are stuck with technology when what we really want is just stuff that
> ___
> 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] mitigate output drops on Cisco 2960G platform

[Joerg Mayer]

On Fri, Sep 20, 2013 at 07:23:17PM +0100, Phil Mayers wrote:
> (However: I wonder if the various techniques being discussed
> elsewhere - like the new Linux kernel packet pacing, disabling TCP
> segmentation offload and reducing nic ring, kernel and app buffers -
> might alleviate the generation of microbursts?)

As long as your problems are TCP related yes, things should be getting
less bad. If you have UDP traffic (think videostreaming, I-frames), you
don't get that help.

Ciao
   J\303\266rg

--
Joerg Mayer   
We are stuck with technology when what we really want is just stuff that
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] pseudo rfc 3069 setup

[Joe Pruett]

the basic concept of 3069 is to allow you to assign ip addresses one at
a time to systems in a data center, but still keep them in separate
broadcast domains and avoid ip "stealing". i have been doing this for
quite some time (before i had ever seen the rfc) by using 1 vlan per
customer and a subinterface per vlan. this allows me to use ip
unnumbered on the subinterface and rely on proxy arp if for some reason
customers need to talk to each other. install /32 routes pointing to the
appropriate subint and turn on unicast source reachable and presto! this
lets us keep ip waste to almost 0. also allows for shaping per customer.

anyway, i am now looking at pushing some of this down into the 6509 i'm
playing with and there are 3 ways to get to the same place.

1. put port g#/# in switchport mode, then using vlan# interface with ip
unnumbered. route to vlan#
2. create subint on port g#/# with dot1q native vlan and ip unnumber it.
route to g#/#.#
3. assign fake ip (like 10.#.#.1/30) to base port. route to g#/#

pro/cons:

1 probably give me the most flexibility, i can provide multiple ports to
a single customer by putting them all in same vlan. but i wonder if
processing will be heavier that way having to go through the vlan pseudo
interface.
2. pretty close to what i do now. but can't have multiple ports per
customer. since from what i can tell those vlans are just for
in/outbound tagging and don't interact with switching fabric.
3. feels like might have the least overhead, but traceroute exposes fake ip.

and i haven't determined if any of these would have problems with
shaping. they all seem like full interfaces, so i would expect to be
able to shape on any of them.

no one may be as crazy as i am and doing anything like this, so feedback
may be sparse. but, i'm curious if anyone has feelings about which of
1-3 would have the least overhead. i don't have enough time available to
set up a good test between them. they all seem to work, but that's as
far as i've gotten.

as a small isp, we don't have huge amounts of traffic, so it may all be
moot. i just want to keep the customer isolation without burning up ips.
we have lots of single ip customers.

and yes, i have v6 available, but only have 2 customers that have even
started using it. all of these options work great for v6 since i can
just give a /64 to each customer interface.
___
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] FabricPath & PIM-SM Interoperation

[Tim Stevenson]

At 08:43 AM 9/17/2013  Tuesday, Yuri Bank noted:

Hi Tim,

Thanks for your response.

I should have phrased my question differently. I'm not suggesting 
that FP IS-IS actually interacts with PIM-SM directly.


My question is:  Will the FP device, which is running PIM-SM on some 
SVI, send PIM Register/Join messages for learned multicast 
sources/receivers in the FP domain?


Yes, absolutely.




Imagine the following scenario.

You have DeviceA and DeviceB.

DeviceA is a FP switch, with an entire FP domain behind it.
DeviceB is a legacy multilayer switch, or router, with many other L3 
devices behind it.


DeviceA has an FP-VLAN with a PIM-SM enabled SVI in it.
DeviceB simply has a layer3 interface (in the above vlan) with PIM-SM enabled.

Now the RP, sits somewhere behind DeviceB. Obviously, if there is a 
host somewhere in the FP network that starts sending multicast 
traffic, DeviceA will have to send out a PIM-Register message in 
order for the RP to learn of the source(otherwise, only hosts in the 
FP network would be able to listen to that traffic).



Yes, the FP switch with the SVI will attract the multicast traffic 
(learned as an mrouter) and once that traffic hits the SVI all the 
usual first hop router mechanisms for L3 multicast kick in.



Likewise, if there is a multicast receiver in FP network, a PIM-Join 
message would need to make its way to the RP.



IGMP snooping intercepts the join at the edge switch to track state 
on the edge port. That join will be flooded on the mrouter ports (and 
also handed over to FP ISIS to advertise the edge switch's interest 
in that group in FP via GM-LSPs.) Once the join hits the SVI all the 
usual last hop router mechansims kick in.


Tim



Does this make sense? Again, I greatly appreciate your response.

-Yuri Bank



On Tue, Sep 17, 2013 at 9:46 AM, Tim Stevenson 
<tstev...@cisco.com> wrote:

Hi Yuri, please see inline below:

At 03:27 AM 9/17/2013  Tuesday, Yuri Bank clamored:

Hello fellow networking enthusiasts,

I have a few specific questions concerning this:

1. *Will a N7k/N5k translate GM-LSPs into PIM-Join messages, on a boundary
link that has a remote peer running PIM-SM?



No. FP ISIS GM-LSPs are an L2 concept here, they basically track 
group membership state at L2 inside the FP core. FP ISIS would not 
"peer" with a router running PIM-SM; you would typically have an SVI 
enabled for the FP VLAN, and that would have PIM enabled to integrate to L3.




2. *Same question as it relates to sources learned, that are within the
FabricPath domain. Will PIM Register messages be generated, and sent to the
RP in the PIM-SM domain?



Not without an SVI/router interface running PIM connected into the FP domain.




3. *Any general information regarding this topic would be greatly
appreciated, as I could find very little documentation about this.



Think of FP GM-LSPs as an extension of IGMP snooping. All the L3 
integration is basically the same in FP and classical Ethernet.



Hope that helps,
Tim





Regards,

YuriB
___
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/






Tim Stevenson, tstev...@cisco.com
Routing & Switching CCIE #5561
Distinguished Technical Marketing Engineer, Cisco Nexus 7000
Cisco - http://www.cisco.com
IP Phone: 408-526-6759

The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.






Tim Stevenson, tstev...@cisco.com
Routing & Switching CCIE #5561
Distinguished Technical Marketing Engineer, Cisco Nexus 7000
Cisco - http://www.cisco.com
IP Phone: 408-526-6759

The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.
___
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] mitigate output drops on Cisco 2960G platform

[Gert Doering]

Hi,

On Fri, Sep 20, 2013 at 07:23:17PM +0100, Phil Mayers wrote:
> (However: I wonder if the various techniques being discussed elsewhere - 
> like the new Linux kernel packet pacing, disabling TCP segmentation 
> offload and reducing nic ring, kernel and app buffers - might alleviate 
> the generation of microbursts?)

That actually sounds *very* interesting.  Especially TCP segmentation
has bit me elsewhere as well, on 1G->100M speed translations, with an
AIX machine firing out something like a 15-packet-burst back-to-back
(due to "one big TCP segment being stuffed into the card") and that
overflowing a stupid switch on the path...

(That particular problem was "solvable" by moving the AIX box to a 100Mbit
port, which immediately made all users behind WAN links much more happy,
as they did not have packet loss at noticeable RTTs anymore...)

Getting off-topic, but the whole idea of people actually working on this
is something I find exciting :-)

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-35655025g...@net.informatik.tu-muenchen.de


pgpp1uKDAm6J7.pgp
Description: PGP signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ASA 5585-X upgrade error

[Justin M. Streiner]

On Fri, 20 Sep 2013, Antonio Soares wrote:


I was preparing a few 5585-X upgrades to 8.4.6.5 and I got this:
...
Destination filename [asa846-5-smp-k8.bin]?
...
No Cfg structure found in downloaded image file


Perhaps your ASA image is corrupted?  Did you compare the MD5 signature of 
the file you have on your FTP server to the signature that's published by 
Cisco?


jms
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ASA 5585-X upgrade error

[Karl Putland]

You have to got 9.1.2 first, then upgrade to 9.1.3

I just hit this today too.

--Karl

Karl Putland
Senior Engineer
*SimpleSignal*
Anywhere: 303-242-8608



On Fri, Sep 20, 2013 at 12:08 PM, Antonio Soares wrote:

> Hello guys,
>
>
>
> I was preparing a few 5585-X upgrades to 8.4.6.5 and I got this:
>
>
>
> +
>
> FW# copy ftp: disk0:
>
>
>
> Address or name of remote host [x.x.x.x]?
>
>
>
> Source filename [asa846-5-smp-k8.bin]?
>
>
>
> Destination filename [asa846-5-smp-k8.bin]?
>
>
>
> Accessing
> ftp://x.x.x.x/asa846-5-smp-k8.bin...!!
> !!
>
> 
> !
>
>
>
> (...)
>
>
>
>
> 
> !!
>
> No Cfg structure found in downloaded image file
>
>
>
> FW#
>
> +
>
>
>
> The file is not copied to the disk. With ASDM I get a strange HTTP error.
>
>
>
> Anyone has seen something like this ?
>
>
>
>
>
> Thanks.
>
>
>
> 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/

[c-nsp] ASA 5585-X upgrade error

[Antonio Soares]

Hello guys,

 

I was preparing a few 5585-X upgrades to 8.4.6.5 and I got this:

 

+

FW# copy ftp: disk0:

 

Address or name of remote host [x.x.x.x]? 

 

Source filename [asa846-5-smp-k8.bin]? 

 

Destination filename [asa846-5-smp-k8.bin]? 

 

Accessing
ftp://x.x.x.x/asa846-5-smp-k8.bin...

!

 

(...)

 


!!

No Cfg structure found in downloaded image file

 

FW#

+

 

The file is not copied to the disk. With ASDM I get a strange HTTP error.

 

Anyone has seen something like this ?

 

 

Thanks.

 

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/

[c-nsp] ME3400 high cpu

[CWO Network Operations]

Hello,

We just started using the ME3400's (ME-3400G-12CS-A, 12.2(58)SE2, 
ME340x-METROIPACCESSK9-M ) in our network and are noticing a fairly high CPU 
load compared what we were used to on the older 3550's.
The config is pretty much the same on the new M#3400's then what we had on the 
3550's. The 3550's never really ran higher than 3%/0% CPU load.
So, I'm not sure why the ME3400's are running so much higher in CPU... 

Here are some outputs:

switch # sho proc cpu sorted 5sec
PU utilization for five seconds: 30%/20%; one minute: 34%; five minutes: 32%
 PID Runtime(ms) Invoked  uSecs   5Sec   1Min   5Min TTY Process 
  85  186523   11652  16007  0.79%  0.15%  0.12%   0 HULC Tcam 
Memory 
  12  402028 1335248301  0.63%  0.55%  0.57%   0 ARP Input  
  
  96   91391 1707572 53  0.47%  0.13%  0.11%   0 hpm main 
process 
  62   638152667  23927  0.47%  0.05%  0.00%   0 Per-minute 
Jobs  
 200   59364  425347139  0.31%  0.07%  0.05%   0 Spanning Tree  
  
  68  100263 6213238 16  0.31%  0.15%  0.10%   0 Fifo Error 
Detec 
 192  139880  328694425  0.31%  0.20%  0.16%   0 IP Input   
  
 133   92952  206477450  0.31%  0.19%  0.15%   0 HL3U bkgrd 
proce 
 316   61245  174270351  0.15%  0.04%  0.05%   0 IP SNMP
  
 1136308  579307 10  0.15%  0.01%  0.00%   0 Hulc Storm 
Contr 
  83   17874 3460721  5  0.15%  0.05%  0.01%   0 HLFM address 
ret 
 142   22760   46634488  0.15%  0.03%  0.00%   0 HRPC qos 
request 
 198  110177  29450  0.15%  0.19%  0.16%   0 ADJ resolve 
proc 
 318  103809   87120   1191  0.15%  0.10%  0.09%   0 SNMP ENGINE
  
  14   0   1  0  0.00%  0.00%  0.00%   0 CEF MIB API
  
  13   17713  121776145  0.00%  0.03%  0.00%   0 ARP Background 
  
   5  82 106773  0.00%  0.00%  0.00%   0 Pool Manager   
  
 [...]

It looks like we are punting packets like crazy...


switch# show platform port-asic stats drop
Port-asic Port Drop Statistics - Summary

  RxQueue 0 Drop Stats: 0
  RxQueue 1 Drop Stats: 0
  RxQueue 2 Drop Stats: 0
  RxQueue 3 Drop Stats: 0

  Port  0 TxQueue Drop Stats: 0
  Port  1 TxQueue Drop Stats: 0
  Port  2 TxQueue Drop Stats: 0
  Port  3 TxQueue Drop Stats: 0

  Supervisor TxQueue Drop Statistics
Queue  0: 0
Queue  1: 0
Queue  2: 0
Queue  3: 0
Queue  4: 0
Queue  5: 0
Queue  6: 17931
Queue  7: 0
Queue  8: 82
Queue  9: 0
Queue 10: 0
Queue 11: 46734696
Queue 12: 0
Queue 13: 0
Queue 14: 0
Queue 15: 0

Port-asic Port Drop Statistics - Details

  RxQueue Drop Statistics
Queue 0
Weight 0 Frames: 0
Weight 1 Frames: 0
Weight 2 Frames: 0
Queue 1
Weight 0 Frames: 0
Weight 1 Frames: 0
Weight 2 Frames: 0
Queue 2
Weight 0 Frames: 0
Weight 1 Frames: 0
Weight 2 Frames: 0
Queue 3
Weight 0 Frames: 0
Weight 1 Frames: 0
Weight 2 Frames: 0

  Port 0 TxQueue Drop Statistics
Queue 0
  Weight 0 Frames 0
  Weight 1 Frames 0
  Weight 2 Frames 0
Queue 1
  Weight 0 Frames 0
  Weight 1 Frames 0
  Weight 2 Frames 0
Queue 2
  Weight 0 Frames 0
  Weight 1 Frames 0
  Weight 2 Frames 0
Queue 3
  Weight 0 Frames 0
  Weight 1 Frames 0
  Weight 2 Frames 0

  Port 1 TxQueue Drop Statistics
Queue 0
  Weight 0 Frames 0
  Weight 1 Frames 0
  Weight 2 Frames 0
Queue 1
  Weight 0 Frames 0
  Weight 1 Frames 0
  Weight 2 Frames 0
Queue 2
  Weight 0 Frames 0
  Weight 1 Frames 0
  Weight 2 Frames 0
Queue 3
  Weight 0 Frames 0
  Weight 1 Frames 0
  Weight 2 Frames 0

  Port 2 TxQueue Drop Statistics
Queue 0
  Weight 0 Frames 0
  Weight 1 Frames 0
  Weight 2 Frames 0
Queue 1
  Weight 0 Frames 0
  Weight 1 Frames 0
  Weight 2 Frames 0
Queue 2
  Weight 0 Frames 0
  Weight 1 Frames 0
  Weight 2 Frames 0
Queue 3
  Weight 0 Frames 0
  Weight 1 Frames 0
  Weight 2 Frames 0

  Port 3 TxQueue Drop Statistics
Queue 0
  Weight 0 Frames 0
  Weight 1 Frames 0
  Weight 2 Frames 0
Queue 1
  Weight 0 Frames 0
  Weight 1 Frames 0
  Weight 2 Frames 0
Queue 2
  Weight 0 Frames 0
  Weight 1 Frames 0
  Weight 2 Frames 0
Queue 3
  Weight 0 Frames 0
  Weight 1 Frames 0
  Weight 2 Frames 0
  Supervisor TxQueue Drop Statistics
Queue  0: 0
Queue  1: 0
Queue  2: 0
Queue  3: 0
Queue  4: 0
Queue  5: 0
Queue  6: 17931
Queue  7: 0
Queue  8: 82
Queue  9: 0
Queue 10: 0
Queue 11: 46734702
Queue 12: 0
Queue 13: 0
Queue 14: 0
Queue

Re: [c-nsp] mitigate output drops on Cisco 2960G platform

[Blake Dunlap]

Basically, you're using the wrong switch if you say the word "server". That
being said, you can search the archives for the proper configuration to
oversubscribe the shared buffers.

-Blake


On Fri, Sep 20, 2013 at 1:11 PM, Gert Doering  wrote:

> Hi,
>
> On Fri, Sep 20, 2013 at 07:56:26PM +0300, Martin T wrote:
> > I have three WS-C2960G-24TC-L switches which all have about ten
> [..]
> > Any suggestions other than reduce the traffic on switch uplink ports?
>
> "Get some real switches"...
>
> Not exactly constructive, sorry.  Been there, felt the pain, ranted on
> cisco-nsp on 2960 and their lack of buffers, and worse, their lack of
> documentation on their lack of buffers.  There's *lots* of it in the
> archives...
>
> If you don't need QoS, turning it *off* with "no mls qos" will help
> somewhat (as then all buffers are available for your packets, not only
> 1/4 which is allocated to that particular queue).  What we had to
> resort to is to make the uplink ports 2xGE or even 4xGE channels to
> exceeding avoid a load of ~25-30 percent per link - we had fairly
> bursty ingress traffic, which (for microseconds a time) overfilled
> the buffers, while the average traffic across all ingress ports was
> WAY below the rate the egress could handle.   Microbursts, too little
> buffering, switches not suited for that traffic.
>
> 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] mitigate output drops on Cisco 2960G platform

[Gert Doering]

Hi,

On Fri, Sep 20, 2013 at 07:56:26PM +0300, Martin T wrote:
> I have three WS-C2960G-24TC-L switches which all have about ten
[..]
> Any suggestions other than reduce the traffic on switch uplink ports?

"Get some real switches"...

Not exactly constructive, sorry.  Been there, felt the pain, ranted on
cisco-nsp on 2960 and their lack of buffers, and worse, their lack of
documentation on their lack of buffers.  There's *lots* of it in the 
archives...

If you don't need QoS, turning it *off* with "no mls qos" will help
somewhat (as then all buffers are available for your packets, not only
1/4 which is allocated to that particular queue).  What we had to 
resort to is to make the uplink ports 2xGE or even 4xGE channels to
exceeding avoid a load of ~25-30 percent per link - we had fairly
bursty ingress traffic, which (for microseconds a time) overfilled
the buffers, while the average traffic across all ingress ports was
WAY below the rate the egress could handle.   Microbursts, too little
buffering, switches not suited for that traffic.

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-35655025g...@net.informatik.tu-muenchen.de


pgpZZoWDEaRHZ.pgp
Description: PGP signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ASA 5585-X upgrade error

[Antonio Soares]

Thanks for the feedback. Just found the bug a few minutes ago:

 

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fet
chBugDetails
 &bugId=CSCuh25271

 

In my case I have 8.4.3.9 and I want to go to 8.4.6.5. I would love to know
if the intermediate upgrade to 8.4.6 will be enough.

 

I didn’t see the problem on the 5520s, only on the 5585-X. The bug doesn’t
mention anything about that…

 

 

 

Regards,

 

Antonio Soares, CCIE #18473 (R&S/SP)
  amsoa...@netcabo.pt

  http://www.ccie18473.net

 

 

From: Karl Putland [mailto:k...@simplesignal.com] 
Sent: sexta-feira, 20 de Setembro de 2013 19:14
To: Antonio Soares
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ASA 5585-X upgrade error

 

You have to got 9.1.2 first, then upgrade to 9.1.3

 

I just hit this today too.

 

--Karl





Karl Putland
Senior Engineer
SimpleSignal
Anywhere: 303-242-8608

  
   

 

On Fri, Sep 20, 2013 at 12:08 PM, Antonio Soares 
wrote:

Hello guys,



I was preparing a few 5585-X upgrades to 8.4.6.5 and I got this:



+

FW# copy ftp: disk0:



Address or name of remote host [x.x.x.x]?



Source filename [asa846-5-smp-k8.bin]?



Destination filename [asa846-5-smp-k8.bin]?



Accessing
ftp://x.x.x.x/asa846-5-smp-k8.bin...

!



(...)




!!

No Cfg structure found in downloaded image file



FW#

+



The file is not copied to the disk. With ASDM I get a strange HTTP error.



Anyone has seen something like this ?





Thanks.



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] mitigate output drops on Cisco 2960G platform

[Phil Mayers]

On 20/09/2013 17:56, Martin T wrote:

Hi,

I have three WS-C2960G-24TC-L switches which all have about ten
servers connected. Each switch has a single 1GigE uplink. Those 1GigE
uplink ports on all switches experience occasional OutDiscards.


As per Gert's reply - this is a platform "feature". Even small 
microbursts can overload these devices.


Unless you can shape the link-layer egress behaviour of your hosts, you 
will have to live with this, provision more uplink bandwidth or change 
device. See the archives for upgrade suggestions, but be aware that Cat 
3560/3750 have the same issue; you need to go to 4500/6500 or 
Nexus/DC-grade switches before it improves.


(However: I wonder if the various techniques being discussed elsewhere - 
like the new Linux kernel packet pacing, disabling TCP segmentation 
offload and reducing nic ring, kernel and app buffers - might alleviate 
the generation of microbursts?)

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] mitigate output drops on Cisco 2960G platform

[Martin T]

Hi,

I have three WS-C2960G-24TC-L switches which all have about ten
servers connected. Each switch has a single 1GigE uplink. Those 1GigE
uplink ports on all switches experience occasional OutDiscards. I
would like to increase the outgoing buffer on uplink ports in order to
mitigate the egress memory buffer overflow.

Increasing the output hold-queue(for example "hold-queue 4096 out")
does not help as this affects only traffic from switch CPU(probably
SNMP, syslog etc traffic). According to documentation, "hold-queue"
should allocate system memory for interface I/O buffers, but I wasn't
able to confirm this with "sh memory" after configuring "hold-queue
4096 out" on all the interfaces in the switch..

Looks like the only way to modify port ASIC egress buffers on 2960G
are with MLS(Multi-Layer Switching) QOS. 2960G family seems to have
four output queues:


2960G#sh mls qos queue-set
Queueset: 1
Queue :   1   2   3   4
--
buffers   :  25  25  25  25
threshold1: 100 200 100 100
threshold2: 100 200 100 100
reserved  :  50  50  50  50
maximum   : 400 400 400 400
Queueset: 2
Queue :   1   2   3   4
--
buffers   :  25  25  25  25
threshold1: 100 200 100 100
threshold2: 100 200 100 100
reserved  :  50  50  50  50
maximum   : 400 400 400 400
2960G#

..but as I have QoS disabled(according to "sh mls qos"), then all
those queues should be aggregated into one large queue. There probably
is a point to configure QoS if there are output drops on some ports
facing the servers. I mean one could group certain ports facing the
servers and allocate more egress buffer for those while at the same
time decrease egress buffer for some other ports facing the servers
which have very little traffic. In case of uplink port experiences
output buffer drops, the single large queue is probably the best
option?

All the servers and uplink ports are on the same linerate. 5min
average egress traffic on those uplink ports is <100Mbps.

Any suggestions other than reduce the traffic on switch uplink ports?


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/

Re: [c-nsp] WiSM: base-ap-count licence installation problems

[Daniel Husand]

On 20.09.2013 10:42, Matti Saarinen wrote:

I wrote:


We bought a licence pack allowing 100 additinal APs to join  Now,
the licence refuses to install


It turned out to be a wrong type of licence. Finally TAC believed that
and issued a new one. The next step is to find out how to avoid this
issue when bying the next set of licences.



Make sure you buy one of the following; LIC-WISM2-100A or 
LIC-WISM2-200A. Notice the A at the end making them adder licenses.


--
Daniel
___
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] A9K 40G & 100G

[Mohacsi Janos]

On Thu, 19 Sep 2013, Phil Bedard wrote:


The 9010 with the non-RSP440 is about 184G/slot using both fabrics.. I
am not entirely sure the 100G cards work without the 440...


It does, however in single RSP-4G  you are limited 93-95Gbps. No problem 
with redundant RSP-4G.

Regards,
Janos Mohacsi



Phil From: Jason Lixfeld
Sent: 9/19/2013 23:15
To: cisco-nsp NSP
Subject: [c-nsp] A9K 40G & 100G
I'm wondering if anyone knows off the top of their head what the
limitations are in terms of 40/100G LC support with RSP4.

I seem to remember reading something at some point saying if with an
RSP4/8, two are required and both are required to run active/active.

Whereas with an RSP440, which has more fabric capacity, wouldn't
require a second fabric active at the same time.

Thanks!

Sent from my iPhone
___
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] A9K 40G & 100G

[Mohacsi Janos]

On Thu, 19 Sep 2013, Jason Lixfeld wrote:


I'm wondering if anyone knows off the top of their head what the limitations 
are in terms of 40/100G LC support with RSP4.



1xRSP-4G -> 93-95 Gbps/slot FDX
2xRSP-4G -> 186-190 Gbps/slot FDX




I seem to remember reading something at some point saying if with an RSP4/8, 
two are required and both are required to run active/active.



The ASR9K platform in case of redundant RSP, it is always runnning in 
active/active.




Whereas with an RSP440, which has more fabric capacity, wouldn't require a 
second fabric active at the same time.

Thanks!

Sent from my iPhone
___
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/

[c-nsp] Working off-the-shelf Nagios plugin for Nexus devices?

[Alan Hall]

Hi,

Based on experience, can anybody recommend a Nagios plugin to monitor
interface state, bandwidth utilisation and error reporting for nexus
devices? I've stumbled across a couple of examples, but I would definitely
appreciate community input.

Thanks in advance!
___
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] Access to CCO - "sso.cisco.com" over IPv6

[Andrew Yourtchenko]

Guys, could you send me more specifics unicast ?

(Highly desirably with some PCAPs off your client segment that would 
capture the entirety of the session with the problem).


I'll take a look, once we root-cause it I'll follow-up with our IT folks 
and get back.


--a




On Fri, 20 Sep 2013, Phil Mayers wrote:


On 20/09/13 11:34, Reuben Farrelly wrote:

Hi

I've been having intermittent problems logging into CCO in the last few
weeks - and the troubleshooting I've done so far seems to indicate the
problem only occurs when I'm connecting to it over IPv6.  It seems the
actual authentication to www.cisco.com is handled by a site with
hostname sso.cisco.com.


Yeah, we've seen problems with the IPv6-enabled Cisco stuff recently. Errors 
suggesting SQL fields sized for IPv4 but not IPv6 addresses, and so on.

___
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] Access to CCO - "sso.cisco.com" over IPv6

[Phil Mayers]

On 20/09/13 11:34, Reuben Farrelly wrote:

Hi

I've been having intermittent problems logging into CCO in the last few
weeks - and the troubleshooting I've done so far seems to indicate the
problem only occurs when I'm connecting to it over IPv6.  It seems the
actual authentication to www.cisco.com is handled by a site with
hostname sso.cisco.com.


Yeah, we've seen problems with the IPv6-enabled Cisco stuff recently. 
Errors suggesting SQL fields sized for IPv4 but not IPv6 addresses, and 
so on.

___
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] WiSM: base-ap-count licence installation problems

[scott owens]

I know we are not alone -
We have wisms, 5508s, and 5760s.

I have had to buy a license to be able to use the newer products 3 times
for 1130s and 1140s.
I have had to buy a license to be able to use the 1200s and 3500s 2 times
and I suspect when Cisco rolls out a new controller product ( the 5508 will
go EOS ) I will have to buy more licenses )







>8. Re: WiSM: base-ap-count licence installation problems
>   (Gert Doering)
>
>
> Message: 8
> Date: Fri, 20 Sep 2013 11:23:55 +0200
> From: Gert Doering 
> To: Matti Saarinen 
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] WiSM: base-ap-count licence installation problems
> Message-ID: <20130920092355.gb...@greenie.muc.de>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> On Fri, Sep 20, 2013 at 11:42:18AM +0300, Matti Saarinen wrote:
> > It turned out to be a wrong type of licence. Finally TAC believed that
> > and issued a new one. The next step is to find out how to avoid this
> > issue when bying the next set of licences.
>
> "Not buy from vendors that force that sort of bullshit onto their
> customers"
> (and let your AM know in no uncertain terms how much time and money that
> bullshit cost you this time).
>
> At least in the managed WiFi space, there should be competition...
>
> 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
> -- next part --
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 305 bytes
> Desc: not available
> URL: <
> https://puck.nether.net/pipermail/cisco-nsp/attachments/20130920/f875fe4a/attachment-0001.sig
> >
>
>
___
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] A9K 40G & 100G

[Phil Bedard]

  Typhoon are the newer cards.  They probably work but never tried since
its kind of a waste.
 --
From: Dmitry Kiselev 
Sent: 9/20/2013 3:45
To: Phil Bedard ; Jason Lixfeld ;
cisco-nsp
NSP 
Subject: RE: [c-nsp] A9K 40G & 100G

 As far as I hear from my CSE, tornado cards will work with older RSPs, but
will have performance limitations due low speed fabric connections. Unable
to check on my boxes - already upgraded

-- 
Dmitry Kiselev

> From: phil...@gmail.com
> Date: Thu, 19 Sep 2013 21:05:28 -0700
> To: ja...@lixfeld.ca; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] A9K 40G & 100G
>
> The 9010 with the non-RSP440 is about 184G/slot using both fabrics.. I
> am not entirely sure the 100G cards work without the 440...
>
> Phil From: Jason Lixfeld
> Sent: 9/19/2013 23:15
> To: cisco-nsp NSP
> Subject: [c-nsp] A9K 40G & 100G
> I'm wondering if anyone knows off the top of their head what the
> limitations are in terms of 40/100G LC support with RSP4.
>
> I seem to remember reading something at some point saying if with an
> RSP4/8, two are required and both are required to run active/active.
>
> Whereas with an RSP440, which has more fabric capacity, wouldn't
> require a second fabric active at the same time.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] Access to CCO - "sso.cisco.com" over IPv6

[Reuben Farrelly]

Hi

I've been having intermittent problems logging into CCO in the last few 
weeks - and the troubleshooting I've done so far seems to indicate the 
problem only occurs when I'm connecting to it over IPv6.  It seems the 
actual authentication to www.cisco.com is handled by a site with 
hostname sso.cisco.com.


There are both A and  records for it in DNS, and it resolves 
consistently across multiple locations.  It looks like this isn't one of 
the CDN delivered components of the site.


The end accepts the IPv6 connection and refuses to send data, eventually 
closing the connection and timing out.   The IPv4 connection works fine. 
 Tested with port 80.


Emails to TAC so far have solicited responses along the lines of 
restarting the PC/clearing browser caches/clearing cookies/changing 
browsers etc trying to push it back on me despite it happening on at 
least two different machines across a period of time including a newly 
installed VM and appearing broken even with a telnet client manual test.


Is anyone else who has IPv6 access and who is accessing cisco.com over 
IPv6 had issues to this site in the past 2-3 weeks?  I get the feeling 
that IPv6 access to parts of CCO systems isn't well monitored, 
blogs.cisco.com was completely broken over IPv6 some weeks back for a 
while, but it came good after I posted a comment on there stating it was 
broken (from IPv4 only work).


Maybe one of those dodgy Cisco load balancers is upset again and needs a 
restart ;)


Or is there someone on here from Cisco who knows who/how to poke to get 
this looked at?


Thanks,
Reuben
___
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] WiSM: base-ap-count licence installation problems

[Gert Doering]

Hi,

On Fri, Sep 20, 2013 at 11:42:18AM +0300, Matti Saarinen wrote:
> It turned out to be a wrong type of licence. Finally TAC believed that
> and issued a new one. The next step is to find out how to avoid this
> issue when bying the next set of licences.

"Not buy from vendors that force that sort of bullshit onto their customers"
(and let your AM know in no uncertain terms how much time and money that
bullshit cost you this time).

At least in the managed WiFi space, there should be competition...

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-35655025g...@net.informatik.tu-muenchen.de


pgpx6QpRLM5Ml.pgp
Description: PGP signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] WiSM: base-ap-count licence installation problems

[Matti Saarinen]

I wrote:

> We bought a licence pack allowing 100 additinal APs to join  Now,
> the licence refuses to install 

It turned out to be a wrong type of licence. Finally TAC believed that
and issued a new one. The next step is to find out how to avoid this
issue when bying the next set of licences.

-- 
- Matti -
___
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 BGP Dual Homed dual site

[Terebizh, Evgeny]

Hi Scott 
My 2 cents. 
I guess you could advertise two /44s through eBGP sessions (one per each
site). In case one uplink goes down, you would advertise locally generated
/44 and /44 route learned through iBGP from another site. Basically,
router may advertise /44 from the neighboring site as soon as upstream ISP
withdraws this route (we can't advertise iBGP learned route to ISP cause
we have a best route through it).
You could configure a higher LOCAL_PREF for eBGP sessions to make sure
that inter site traffic is not going through the backdoor link in normal
scenario. 
I assume that return traffic won't go through the backdoor connection as
well, unless one of your uplink goes down.
Also I would use SoO community to prevent possible routing loops.
One more thing. I heard that there're some issues related to IPv6
multihoming. I guess you might check out existing RFCs for more details.

/ET



On 9/19/13 11:13 PM, "Scott Voll"  wrote:

>I'm trying to wrap my head around the best way to setup BGP with IPv6
>
>We currently have two different ISP's connected to two different sites.
> then we run iBGP between the sites.
>
>so in an IPv4 world have a class C at each location.  then at each
>location
>my Firewalls NAT to the correct Class C as they exit my network.
>
>This way if the link between sites go down I'm not black holing the other
>sites because each site has it's own Class C it's announcing.
>
>Now if I have a single /40 and I'm subnetting it per location(eg /44), but
>all the other sites behind these sites are within that /40 how do I make
>sure I don't end up blackholing the other site(s)?  Does that make sense?
> Do I need to announce a /44 from each site?  if so, that will kill my
>meshed network(internal) if one site(external) goes down, or the WAN links
>go down.
>
>Thanks for any ideas.  Is there a best practice for this kind of setup?
>
>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] A9K 40G & 100G

[Dmitry Kiselev]

As far as I hear from my CSE, tornado cards will work with older RSPs, but will 
have performance limitations due low speed fabric connections. Unable to check 
on my boxes - already upgraded

-- 
Dmitry Kiselev

> From: phil...@gmail.com
> Date: Thu, 19 Sep 2013 21:05:28 -0700
> To: ja...@lixfeld.ca; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] A9K 40G & 100G
> 
> The 9010 with the non-RSP440 is about 184G/slot using both fabrics.. I
> am not entirely sure the 100G cards work without the 440...
> 
> Phil From: Jason Lixfeld
> Sent: 9/19/2013 23:15
> To: cisco-nsp NSP
> Subject: [c-nsp] A9K 40G & 100G
> I'm wondering if anyone knows off the top of their head what the
> limitations are in terms of 40/100G LC support with RSP4.
> 
> I seem to remember reading something at some point saying if with an
> RSP4/8, two are required and both are required to run active/active.
> 
> Whereas with an RSP440, which has more fabric capacity, wouldn't
> require a second fabric active at the same time.
 

  
___
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/