Unicast OTV deployment experience

e-chuah · ‎11-17-2011

Hi, Just to check if there are many Unicast OTV deployments around the world. My client has intention to deploy, but is concerned about the stability of the code. We have deployed Unicast OTV (NX-OS 5.21) for another client and hit the bug CSCtt62040 which resulted in a crash. Workaround has been implemented, but it is not a pleasant experience though. We also hit another internal bug which result in an error message generated in the logfile every minute (this bug does not impact functionality). Both of the bugs will be resolved in 5.2(3), scheduled to be out end of the month. But not sure what other things can pop up... Would be good if anyone can share some deployment experience. Rgds Eng Wee

alanjbrown · ‎02-13-2012

Eng Wee,

It's been 4months since your last post and no one has responded. We are considering Unicast OTV.

What has been your experience since November ? Did you up grade to 5.2.3a? Any more bugs?

thks,

Al

Krzysztof Zaleski · ‎02-13-2012

Hello,

We have some experience now. OTV (unicast) has been running for about 2 months, and it seems to be OK, Actualy, until few days ago. Suddently all interfaces on OTV VDC started flapping (physical interfaces go down for unknown reason - maybe anyone faced this before?) almost on daily basis. We are still investigating this issue, but it might be some non-OTV related issue (although it happens ONLY in OTV VDC). Except that there are no other issues so far. We have confirmation that all applications, including vmotion work great. There is also some "cosmetic" bug which show that ISIS IDs are duplicated, but from the deep analysis it looks like it's just a dummy log entry with no real impact.

Best regards,

Krzysztof

e-chuah · ‎02-14-2012

Hi Al, Other than the bugs i mentioned above, we also hist memory leak issues with 5.2.1. So i would suggest you to use 5.2.3a for now. We have upgraded to 5.2.3a for one pair of the nexus and will be upgrading another pair next week. Other than bug related issue, you also need to consider: (1) jumbo frame as OTV set the DF bit. (2) silent host issue. Especially you have scenario where the gateway of the vlan that you extended across using OTV is pointing to a FW or any other appliance. Hope this helps Eng Wee

Krzysztof Zaleski · ‎02-14-2012

Hello,

Due to our recent issues, we also plan an upgrade to 5.2.3a. Regarding silent hosts, the only serious issue known is Microsoft Loand Balancing, which is based on unknown unicast flooding, which is not supported by OTV for obvious reasons. However, you can always configure static MAC-IP mapping on OTV pod, as a workaround. Another issue we observed is not serious and it's temporary. If you have some network devices on one side, which are quiet (do not generate any traps or syslog), they mey become inaccessible for some time if you clear mac table on OTV. The solution is to wait until ARP times out or clear it manualy. But it's just a minor issue.

Cheers,

Krzysztof

alanjbrown · ‎02-16-2012

Thank you for your comments, it helps with building confidence. Can I ask a couple more questions?

Are your networks test or production environments?

Have you configured single or dual homed OTV?

Have you tried or are using HSRP filtering? Have you experienced any Asymmetric routing issues?

thks,

Al

Krzysztof Zaleski · ‎02-16-2012

It's a production environment, two site, dual homed, with HSRP filtering for optimal egress routing. Asymetric routing is possible and inevitable, unles you implement LISP :-)