[c-nsp] VSS 1440 issues

[Matthew Huff]

I would suspect it's a timeout issue caused by it aging out of the arp cache
and not the tcam table. 

Try adding "mac-address-table aging-time 14400" to the config. This usually
happens when running HSPR/GLBP or other first-hop redudancy (VSS) where the
return path may be asymmetrical.



----
Matthew Huff       | One Manhattanville Rd
OTA Management LLC | Purchase, NY 10577
http://www.ox.com  | Phone: 914-460-4039
aim: matthewbhuff  | Fax:   914-460-4139


> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of C and C Dominte
> Sent: Wednesday, August 05, 2009 7:30 AM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] VSS 1440 issues
> 
> 
> 
> 
> 
> Hi,
> 
> 
> 
> I recently clustered 2 Catalysts 6509's into a VSS 1440
> Virtual switch.
> 
> 
> 
> Details about the cluster:
> 
> 
> 
> - Software version:
> s72033_rp Software (s72033_rp-IPSERVICESK9_WAN-M), Version
> 12.2(33)SXI1,
> RELEASE SOFTWARE (fc3)
> 
> 
> 
> - Supervisor:
> VS-S720-10G  with one 10G port
> used as VSL link
> 
> - Linecards Active chassis:
> 
>                 1 x
> WS-X6708-10GE with one 10G used for the VSL link for redundancy
> 
>                 4 x
> WS-X6748-GE-TX
> 
> 
> 
> - Linecards Standby chassis
> 
>                 1 x
> WS-X6708-10GE with one 10G used for the VSL link for redundancy
> 
>                 2 x
> WS-X6748-GE-TX
> 
> 
> 
> The 6748 line cards are used and
> configured for MEC Etherchannels.
> 
> 
> 
> At the other end of the MEC
> channels there are non-Cisco edge switches. The multi chassis Ether
> Channels
> are configured as 2 x 1G links, and single switchport trunks are
> configured as
> 1 x 1G links. All vlans are allowed on the single switchport trunks and
> port
> channels from VSS Cluster to the edge switches.
> 
> 
> 
> The issue is that unicast
> traffic is flooded by the VSS Cluster across all trunks. The flooded
> traffic
> generated by the VSS cluster is between 600mbps and 1gbps, and almost
> all of
> the flooded traffic is unicast and has the source MAC address of the
> VSS
> Cluster. However, if the trunk is a MEC, the unicast traffic is flooded
> only on
> one switchport. All of the flooded ports in MECs are on switch 2 in the
> VSS
> cluster. The only ports flooded in switch 1 are the ones that have a
> single
> trunk instead of MEC.
> 
> 
> 
> We tried to investigate this on
> a low importance link. The VSS cluster learned only 10 MAC addresses on
> one
> edge trunk configured as 1 x 1G link. This edge trunk received the
> flood of
> unicast traffic from the VSS cluster as well. During testing, this
> trunk was
> modified manually on the VSS Cluster, to allow only 4 VLANS instead of
> all.
> Allowing only 4 vlans on this trunk stopped the flood on the edge trunk
> and
> stopped the flood on all other trunks as well.
> 
> 
> 
> Does anyone have any idea about
> what can cause this?
> 
> 
> 
> Thanks
> 
> 
> 
> Catalin
> 
> 
> 
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4229 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090805/f149ec7e/attachment.bin>