OTV redundancy with ASR’s

I deployed OTV at a customer site using Nexus 7K’s in one datacenter and ASR routers in the secondary datacenter. I got it all working and then started working on redundancy on the ASR. The downstream switches from the ASR’s are a couple of Nexus 5K’s. I created a port channel on the ASR’s and the 5K’s along with a VPC. I tested communication and all was working well. However when I tried moving the service instance from the physical interface (gi1/1/1) to the port channel the command was invalid.

ASR1000-01(config)# int po2
ASR1000-01(config-if)#
ASR1000-01(config-if)# service instance 10 ethernet
                               ^
% Invalid input detected at ‘^’ marker.
ASR1000-01(config-if)# service?      
service-policy 
ASR1000-01(config-if)#

This stumped me and I couldn’t much info in Cisco’s design guides, the support forum or just searching CCO and the web. I ended up opening a TAC case and was told that was by design. For redundancy I was told to buy a second ASR (which we did from the get go) and create a single leg from ASR-1 to N5K-1 and another from ASR-2 to N5k-2. I don’t like this since Cisco’s datacenter vision is layer 2 and VPC’s.

2 Comments on “OTV redundancy with ASR’s”

  1. Aaron Cottew says:

    Hi Colin,

    I was just trying to lab this today using ASR1k port-channels and came across the same issue. We have 2 ASR1ks in our design but I was attempting to add additional resiliency.

    I am still faced with a black hole scenario during failure testing which Im interested to know if you experienced similar behavior.

    When I loose the OTV Inside leg link between ASR-1 and Nexus5k-1 all L2 OTV traffic migrates to the Nexus5k-2 to ASR-2 OTV-Inisde link due to AED failover.

    However when the failed link is restored the Nexus5k’s continue to bind the destination MAC address to the Nexus5k-2 link and traffic black holes. They do not learn the destination MAC from the correct link until the MAC hold timer expires.

    Any ideas?

    Happy to publish configs if this helps.

    Thanks
    Aaron

  2. Collin Clark says:

    Aaron-

    Check this link. I have not had to do this, but I may test it again in a couple of weeks when I have to bring the ASR’s down and move them to a new core.

    http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/DCI/whitepaper/DCI3_OTV_Intro_WP.pdf

    Because of this ARP caching behavior, you should consider the interactions between ARP and CAM table aging timers, since incorrect settings may lead to black-holing traffic. This is also a consequence of the OTV characteristic of dropping unknown unicast frames.

    Let me know how it goes.

Leave a Reply

Your email address will not be published.

Time limit is exhausted. Please reload CAPTCHA.