[c-nsp] Using DFC cards on a L2 6500/7600 system

[Ian Cox]

At 09:09 PM 6/15/2007 +0300, Tassos Chatzithomaoglou wrote:
>Sorry Tim, but more questions came up now...
>
>
>7600-ES20 datasheets say something about 80.000 mac addresses per ES card.

The ES20 uses a DFC3C/DFC3CXL which has a 96k table, and utilizes an 
improved hash algorithm over the one on the Sup270 so 80k entries 
will fit into the table. The Sup uses PFC3A, 3b, 3bXL and that only 
has a 64k table.


>What is the catch here? How can the SUP720 know n * 80k addresses 
>when it only supports 64k?

The Sup can not know 80k addresses, it only knows at max 64k entries.

>Does it refer to mac addresses belonging to per card locally 
>configured vlans only?
>
>
>Also, on a system with DFC modules "sh mac-address-table count" 
>shows only the macs "known" by the SUP720.
>
>
>7609#sh mac-address-table count
>MAC Entries  for all vlans :
>Dynamic Address Count:                71
>Static Address (User-defined) Count:  113
>Total MAC Addresses In Use:           184
>Total MAC Addresses Available:        65536
>
>DFC module
>----------
>7609#sh mac-address-table count mod 1
>MAC Entries for module 1 :
>Dynamic Address Count:                2031
>Static Address (User-defined) Count:  113
>Total MAC Addresses In Use:           2144
>Total MAC Addresses Available:        65536
>
>DFC module
>----------
>7609#sh mac-address-table count mod 2
>MAC Entries for module 2 :
>Dynamic Address Count:                1697
>Static Address (User-defined) Count:  113
>Total MAC Addresses In Use:           1810
>Total MAC Addresses Available:        65536
>
>SUP720 (same as the 1st one)
>---------------------------
>7609#sh mac-address-table count mod 6
>MAC Entries for module 6 :
>Dynamic Address Count:                71
>Static Address (User-defined) Count:  113
>Total MAC Addresses In Use:           184
>Total MAC Addresses Available:        65536
>
>
>I guess that's because mac sync between DFC & PFC is disabled by 
>default (SXF8). Any reason to keep it disabled?
>http://www.ciscotaccc.com/kaidara-advisor/lanswitching/showcase?case=K63315572 
>says it's better to enable it, but why isn't is so
>by default (besides X6708-10GE)?

I believe by default it is auto, and is not needed unless you are 
running etherchannel across modules.

>Also "mac-address-table synchronize" doesn't seem to provide any 
>option for (dis)activation per DFC module.
>So if i have a vlan used only locally in a DFC module, can i keep 
>the sync disabled in that module in order to save some mac space?

If you want to fully control what every DFC module learns per vlan 
there are the "mac-address-table learning vlan X module Y" commands. 
These command allow one to disable learning for particular vlans on 
particular DFCs which results in them never learning MAC addresses 
for those vlans.


Ian


>Regards,
>Tassos
>
> >>
> >> You said that each DFC equipped module has its own mac address table.
> >> So i can have 9 x 65536 (or 64000) macs per 6509?
> >
> > No, sorry to mislead you. While you could actually have as many as 17
> > unique L2 engines in the system (DFC3B/BXL has 2 L2 engines, one for
> > each 1/2 of the card), each w/their own copy of the MAC table, there are
> > actually hw mechanisms (and sw mechanisms w/the sync command I
> > mentioned) in place to try to keep them in sync, and as such you can't
> > scale n * 64K MAC entries, we still advertise 64K for the system.
> >
> > Reason being, a FE on one card needs to know about all the other MACs in
> > the system in case it gets a frame destined to one of those MACs; else,
> > you'll get flooding. Yes there are certain cases where in theory you
> > could scale the MACs (vlan only on one FE, etc) but these have never
> > been developed.
> >
> > So for now, for all practical purposes, the MAC table is synched on all
> > cards.
> >
>
> >
> >
> > Tim Stevenson, tstevens at cisco.com
> > Routing & Switching CCIE #5561
> > Technical Marketing Engineer, Data Center BU
> > Cisco Systems, 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 at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/