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
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.
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
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.
Moquery is the command line cousin of Vizore, it's very helpful and efficient sometimes during the troubleshooting. This article aims to provide moquery cheat sheet to the users for some most common seen scenarios.
Here is the checklist before customers/partners contact Cisco TAC:
Firmware Version of APIC and Switch
Download Switch and APIC techsupport logs
Problem description (Symptoms with details)
Business impact (eg, what kind of services...
moquery usageAPIC moquerySwitchmoquery
This document discuss a common issue observed during the VMM integration & VM workload migration to ACI fabric.
VMware Virtual machines are hosted in Cisco UCS-B seri...