[c-nsp] VSS 1440 issues
C and C Dominte
domintefamily at yahoo.co.uk
Thu Aug 6 11:59:47 EDT 2009
Hi,
Thank you for your advice, however, increasing the timers
did not work.
I powered down the active linecards from switch 2
yesterday to see if it stopped the unicast flood, which it did.
Today I increased the mac address syncronisation activity
time to 640 and the mac address aging time to 1920 (3x640) as below:
-----------------------------------------------------------
Module Status:
Statistics collected from Switch/Module :
1/1
Number of L2 asics in this module : 1
Global Status:
Status of feature enabled on the switch :
on
Default activity time : 160
Configured current activity time : 640
------------------------------------------------------------
Module Status:
Statistics collected from Switch/Module :
2/1
Number of L2 asics in this module : 1
Global Status:
Status of feature enabled on the switch :
on
Default activity time : 160
Configured current activity time : 640
------------------------------------------------------------
#sh mac-addr aging-time
Vlan Aging Time
---- ----------
Global 1920
no vlan age other than global age configured
------------------------------------------------------------
Once this was done, I re-enabled one of the linecards on
switch 2, and the same thing happens. The network is flooded with loads of
unicast traffic, on all the trunk ports on switch 2.
Is there any other reason that this unicast flood is
being caused?
Catalin
--- On Wed, 5/8/09, Eric Cables <ecables at gmail.com> wrote:
From: Eric Cables <ecables at gmail.com>
Subject: Re: [c-nsp] VSS 1440 issues
To: "Matthew Huff" <mhuff at ox.com>
Cc: "C and C Dominte" <domintefamily at yahoo.co.uk>, "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
Date: Wednesday, 5 August, 2009, 9:06 PM
Take a look at this..
http://www.cisco.com/en/US/products/ps9336/products_tech_note09186a0080a7c837.shtml#oob_mac
Cisco also recommends that once you enable OOB Synchronization, that the MAC aging timer be set to at least 3x the synchronization timer of 160:
"Configure the MAC aging timer to three times the MAC synchronization timer value.
The default MAC synchronization and MAC aging timers can cause unknown unicast flooding. VSS can cause traffic to flow asymmetrically such that the source MAC address is only learned on one chassis. The MAC aging timer of 300 seconds and MAC synchronization timer of 160 seconds allows for up to 20 seconds of unknown unicast flooding for any given MAC address in a 320 second interval. In order to resolve this, change the timers such that the aging timer is three times as long as synchronization timer, for example, mac-address-table aging-time 480 ."
-- Eric Cables
On Wed, Aug 5, 2009 at 6:32 AM, Matthew Huff <mhuff at ox.com> wrote:
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/
_______________________________________________
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/
More information about the cisco-nsp
mailing list