OTV cross-connected even and odd VLANs

[Kevin Dorrell]

I seem to have fallen into a trap, and I wonder if anyone else has fallen into the same trap, or knows how to get out of it. It concerns the OTV architecture, and sepcifically the allocation of VLANs to AEDs.

I have two data centres, let us call them "A" and "B".  Each site has two Nexus 7700 switches, let us call them "A0", "A1", B0", and "B1".  I have two carrier links, A0--B0 and A1--B1.  I am extending data centre VLANs between the two sites using OTV.

Now, I read that the allocation of VLANs to AEDs depends on the system-id of each switch.  The lower system-id extends the even numbered VLANs and the higher system-id handles the odd numbered VLANs.  Unfortunately, A1 has a lower system-id than A0, but B0 has a lower system-id than B1.  The result is that the VLANs take asymmetric paths.  Even numbered VLANs take A1-->B1 in one direction and B0-->A0 in the other direction.  Odd numbered VLANs take A0-->B0 in one direction and B1-->A1 in the other direction.

OK, I know it will work, but I have an aversion to asymmetric paths.  It also means that if I lose one of the links, I will effectively lose the interconnect for all of the VLANs for the time of the reconvergence instead of only half of them. This might upset my dual-heartbeat clusters, which have one heartbeat on VLAN 21, one on VLAN 22.

Fortunately I am still in the lab, not in production.  What is the best way to fix it?  I propose this:

1. Upload the configs of A0 and A1 to TFTP.
2. Copy the A0 running config to the A1 startup config
3. Copy the A1 running config to the A0 startup config
4. Switch off both A0 and A1
5. Swap over the supervisor cards of A0 and A1
6. Power them on again

Any comments?  I think that will fix the problem ... unless I ever have to replace a supervisor, in which case I will have a 50% probability of ending up with the cross-connected VLANs again.

Experts .... any thoughts on this?

Kevin Dorrell
Luxembourg

[Kevin Dorrell]

Well, that didn't work.  It seems the system-id is tied to the chassis and not to the supervisor card.  My only option was to reverse all the cabling and swap over the configuration files.  Even that did not work quite as I expected: the only configuration file that worked was the admin VDC.  For the other VDCs, they seemed to ignore the startup file I had uploaded.  In the end I had to cut and paste the configs from the files on the TFTP server.

No answers .... am I talking to myself here?

Kevin Dorrell
Luxembourg

[Bilal Nawaz · Accepted solution]

Hello Kevin, I also came across this problem few times, I ended up swapping chassis around. Based on the AED election, the following definition on how it works.

The AED is elected for each VLAN based on a VLAN ID based hash computation. The VLAN hash algorithm assigns ordinal numbers from zero to maximum to each edge device in the local site, based on the system ID (based on the system MAC address, by default). The hash algorithm uses the following equation:

f (VLAN ID) = (VLAN ID) % edges

where the edges indicates the number of OTV edge devices in the local site. If "f (VLAN ID)" equals the ordinal number for the local edge device, the edge device is authoritative for that VLAN ID. In a site with two edge devices, the VLANs are split as odd and even VLAN ID's on each edge device.

As you note, the system-id is tied to chassis, what I did was set aside the highest ID's out of the 4 N7Ks, and let them do the even vlans, this is our A0 and B0.

The ones with the lowest, connect them up so A1 and B1, so they can handle the odd vlans.

Yes it requires a little re-config and headache of moving chassis around, but if that is the desired end result, thats the only way to get I think.

Bilal

[Kevin Dorrell]

Thank you Bilal, that ties in well with what I have observed.  At least I can say now that I can replace a superisor card without the AEDs unexpectedly swapping over, which is a relief.

I shall know in future when deploying that architecture to take account of the relative system-ids of the chassis before I start cabling.  I'm surprised they don't give you any way of setting the ordinal edge device number so that the allocation of VLAN to AED is a bit more deterministic.  I have heard that in some future release you will be able to configure the allocation manually in a similar way to allocating VLANs to MST instances, which kind of makes sense given their recommendations about co-locating the HSRP active, the STP root, and the OTV AED.

Thanks again for coming back to my posting.

Kevin