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

Thu Jun 30 10:26:53 EDT 2011

Prashanth,
Bridge-assurance blocking and then a subsequent transition back to 
forwarding would cause a TCN, but the same would happen if you had a 
type normal port go down and then back up.  Are you having any issues 
with BA Inconsistent messages?  If not, then maybe you have a different 
issue.

To answer your question about unicast flooding - this is absolutely by 
design and expected.  Flooding occurs because the cam table is fast 
aged, and that is done so a new forwarding path can follow the 
potentially new topology.  Most networks strive to avoid a topology 
change notification unless the event truly a change in topology in the 
network.

You stated you see a topology change whenever you bring an new port 
online, or a port on the 7018 comes up.  I would say if the ports coming 
up on the 7018 are connected to other switch ports, then this is 
expected and you should not do anything about this - besides look into 
why you have ports coming up so often.

If the ports you are referring to are servers and they are being 
provisioned or rebooted, you should look into setting them as 
spanning-tree port type edge or edge trunk.  It is also recommended to 
use bpduguard whenever you use edge ports (also referred to as portfast 
ports): "spanning-tree port type edge bpduguard default"

Regards,
John Gill
cisco

On 6/27/11 3:39 PM, Prashanth kumar wrote:
> What I meant is spanning tree topology is configurated with network-type
> default in global config unless specifically configured as access.
> (spanning-tree port type network default ). And on each  of the port it set
> as normal explicity.
>
> We dont run any VPC and ver is 4.2(6). We rely on spanning tree to block the
> port.
>
>
>
> -thanks
> Prashanth
>
>
> On Mon, Jun 27, 2011 at 12:24 PM, Quinn Snyder<snyderq at gmail.com>  wrote:
>
>> 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>
>> 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>
>>> 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>
>>> 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>
>>> cisco-nsp at puck.nether.net
>>>> <https://puck.nether.net/mailman/listinfo/cisco-nsp>
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>> archive at<http://puck.nether.net/pipermail/cisco-nsp/>
>>> 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/
>