[c-nsp] Nexus OTV Question

[Martin Clifton]

Thanks Lincoln,

The problem isn't associated with a single mac-address moving between
ports - at least I don't think so. Everything seems to be behaving as
expected - except for the "sh otv route" table.

For clarity, I configured only a couple of vlans over OTV.  The otv route
table quickly stabilises and can be reconciled against the originating
device.   Then, a new mac-address appears or disappears.  What then
happens is that the uptime for all pre-existing mac-addresses resets to
zero.  This is not what I would expect - I would have expected the uptimes
for the pre-existing mac-addresses to continue to increment.

Then, as I add vlans (100 or so), the number of mac-addresses increases
dramatically, and of course the probability of a change to the table
increases.  Consequently the frequency at which all of the uptimes reset
to zero increases.  This then gives the impression that the system is
quite unstable - which I don't believe it is.

Regards, Martin

---------------------------------
Martin Clifton
ITS - Networks and Computing
Victoria University
Melbourne, Australia

Phone: 03 9919 4579
---------------------------------




On 28/02/11 5:31 PM, "Lincoln Dale" <ltd at cisco.com> wrote:

>hi Martin,
>
>On 28/02/2011, at 10:16 AM, Martin Clifton wrote:
>> I have a concern about the table that is displayed when you enter the
>>command "sh otv route".   This table shows entries for "site" (ie local)
>>and "overlay" (ie other DC)  mac addresses.    The issue is with the
>>"Uptime" data.  For the overlay addresses this will randomly reset to
>>zero and all addresses will reset to zero at the one time.   The
>>frequency of this reset seems to be a function of the number of vlans ie
>>the more vlans I add to the overlay, the more often the value resets.
>>With 100 or more vlans the value may build up to a minute or two but
>>will often only get to a few seconds before resetting.
>
>i would not expect the "uptime" in "show otv route" to be resetting.
>that, to me, indicates that the MAC address(es) are moving/oscillating
>between ports on the originating device.
>with OTV we still do hardware-based MAC learning for L2 switching but
>whenever a MAC address is learnt or moves that is picked up by
>control-plane and advertised accordingly.
>
>for one of those mac addresses, suggest you look into whether it is in
>fact moving - and more importantly - why.  it could be a misconfiguration
>(like Port Channel "mode on" on one device and no Port Channel defined on
>the other end.
>it could be misconfigured hosts - set up with NIC teaming or Link
>Aggregation incorrectly.
>it could be unstable L2 at one side.
>t could be a loop.  (but i'd expect that to be having more noticable
>impacts on the network :) ).
>
>pick one of the N7Ks where you see the change originating from and do a
>few "show hardware mac address-table <slot-number> | grep <macaddr>" and
>see if its moving.  that shows the h/w mac table.  you may also see the
>same moving of mac addresses in "show mac address-table" but the h/w one
>will show updates sooner.
>
>
>cheers,
>
>lincoln.

This email, including any attachment, is intended solely for the use of the intended recipient. It is confidential and may contain personal information or be subject to legal professional privilege. If you are not the intended recipient any use, disclosure, reproduction or storage of it is unauthorised. If you have received this email in error, please advise the sender via return email and delete it from your system immediately. Victoria University does not warrant that this email is free from viruses or defects and accepts no liability for any damage caused by such viruses or defects.