[c-nsp] VSS 1440 issues

[Eric Cables]

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