[c-nsp] Nexus 7018 spanning tree and unicast flooding

[Quinn Snyder]

am i to assume that your prior statement is incorrect then, wherein you
stated that all ports on the core switch are set to type network?
 regardless of whether they are up, down, or lateral -- if the far end
device doesn't support 'bridge-assurance', then the port should be of
'normal' type.

additionally, are you running any vpc services on the n7k?  have you ensured
that by bringing up the new interface you're not causing the spf
recalculation by some spanning-tree vlan priority command misconfig?  i can
safely say that i've done exactly what you are doing on n7018 running vpc
(nx-os 5.0(2a) and 5.1(3)), with no packet loss or spf reconvergence. this
was run in a vdc environment with that particular vdc running eigrp, hsrpv2,
vpc, lacp, udld, and rpvst+.

configs and nx-os versions would be helpful here.

regards,
q.

-= sent via ipad. please excuse brevity, spelling, and grammar =-

On Jun 27, 2011, at 12:12, Prashanth kumar <smarni7468 at gmail.com> wrote:

Quimm,

Spanning tree type is normal for all the ports connected to downstream
switched.

spanning-tree port type normal

-Thanks
Prashanth

On Mon, Jun 27, 2011 at 11:28 AM, Quinn Snyder <snyderq at gmail.com> wrote:

> prashanth --
>
> i see that you have all ports as 'network' ports. i assume this is
> done by invoking
>
> spanning-trew port type network
>
> under the interface configuration stanza or so. in n7k land, this
> invokes a feature called 'bridge-assurance' and it must be explicitly
> enabled on the other end. it is a feature that can only be enabled
> globally on n7k and is enabled by default if you run any vpc services
> on n7k.
>
> that being said -- your issue may be caused by this configuration
> statement. bridge-assurance is only supported on certain versions of
> c6k, so i'd say that you have to change this. [0]
>
> please set all ports that dont have bridge-assurance on both ends to
> the following
>
> spanning-tree port type normal
>
> and see if this solves your problem.
>
> regards,
> q.
>
> [0] https://supportforums.cisco.com/thread/2000819
>
> -= sent via ipad. please excuse brevity, spelling, and grammar =-
>
> On Jun 27, 2011, at 11:05, Prashanth kumar <smarni7468 at gmail.com> wrote:
>
> > I am trying to troubleshoot a issue with  spanning tree topology change
> and
> > unicast flooding during the topology change which I have not seen in
> 6500.
> > I am new to nexus series.
> >
> > +----------+                            +-------------+
> > |              |                             |                |
> > | Root     |                             | Secondry |
> > | SW1     |------------------------| Root        |
> > |              |------------------------| SW2       |
> > +----------+                            +------------+
> >     |                                      /
> >     |                                 /
> >     |                             /
> >     |                 span blocked
> > +-------------------/---+
> > |  Access Switch   |
> > |                            |
> > +----------------------+
> >
> > We have a simple topology of two Nexus 7018  aggregation routers in DC
> and
> > access-switches connected to two of them as shown above. There are
> multiple
> > VLAN's trunked to the access  switches.  All vlans are trunked between
> Nexus
> > switch as well.  The Access swtich connection to
> > second 7018 is blocked.  We run PRSTP+ and all ports on core switch are
> type
> > network.  The issue we have is when ever we bring up a new port  or port
> > state changes on 7018 there is TCN generated and both the switch flush
> the
> > cam table and it takes about 15 to 30 second to re-learn the new mac.
> during
> > this time we see lot of unicast flooding on all the switches/load
> balancer
> > which are connected. Is this a limitation on Nexus 7000 or is this normal
> > behavior. I have not seen this on 6500.
> >
> > Thanks you in advance
> >
> >
> > PK
> > _______________________________________________
> > 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/
>