Inline OTV with multiple DCIs - DCI failure question.

[D R]

Hello.

Assuming the topology in the attachment (inline OTV with unicast mode), an extended VLAN is currently flowing via DCI circuit 1.Assume the DCI circuits are not dark fibre but are an ISP provided layer 2 circuit so in theory there could be a circuit failure that causes traffic interruption but the join interfaces remain up/up.

What happens with OTV in this scenario? I'm assuming the overlay will eventually timeout. Will the secondary ASRs connected to DCI circuit 2 become the AEDs for the VLAN that was flowing over the failed circuit automatically? What happens when DCI circuit 1 recovers?

Is an OTV on a stick deployment generally recommended over OTV linline simply to reduce failover time? Where the DC core terminates the two DCIs and provides routing for the OTV join (e.g. EIGRP with BFD).

Kind regards.

[Madhukrishnan Gopinathan Nair · Accepted solution]

HI D R,

My understanding is that as soon the Overlay goes down (in this case it will time out eventually) it looses its AED  capability. So eventually, I assume the the redundant edge device will become AED for all vlans. I am expecting the below output under OTV when your adjacency goes down.

sh otv

<SNIP>

AED-Capable         : No (No Overlay Remote Adjacency up)

Hope this helps,

Madhu.

[Madhukrishnan Gopinathan Nair · Accepted solution]

Also when your circuit recovers, again it will take over the AED role for the vlans it was handling before.

Is an OTV on a stick deployment generally recommended over OTV linline simply to reduce failover time?

From an OTV perspective there is no difference between the two models.

The main advantage of the Appliance on a Stick model is that no changes to the design or to the physical connections would be required once the dependency from the OTV VDC is removed. The only migration steps at that point would be to move the OTV configuration from the OTV VDC to the Routing VDC and deactivate the OTV VDC. This would be transparent to the rest of the data center network.

Reference : 

http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Data_Center/DCI/whitepaper/DCI3_OTV_Intro/DCI_1.html

http://www.cisco.com/c/dam/en/us/products/collateral/switches/nexus-7000-series-switches/guide_c07-728315.pdf

[Madhukrishnan Gopinathan Nair]

Apart from the above, please keep in mind there is no AED - reelection if your internal interface goes down, unlike your join interface going down or OTV VDC going offline.

So ensure you have redundancy in place for the internal interfaces too via port-channel or VPC(if two DC cores are used).

Hope this helps and kindly remember to rate the posts if you find them useful.

Regards,

Madhu.

[Madhukrishnan Gopinathan Nair]

Pleas also note all the above were interms of Nexus OTV. I have not worked on OTV with ASRs however I assume the fundamental concepts to be the same. You could cross check it with ASR OTV white papers and best practices for verification.

Regards,

Madhu.

[D R]

Hi Madhu.

Thank you for taking the time to reply. Great information and insight.

As per your comments, I will modify the design and include redundant connectivity for the OTV internal interface via port-channel. The ASRs are connected to 6500 chassis utilising VSS.

I agree that Appliance on a Stick configuration has advantages in terms of being able to easily change the topology with minimal disruption. I see that one disadvantage of an OTV inline topology is that each DCI is isolated, whereas Appliance on a Stick with routing via a core brings the advantage of using an IGP to reach a remote ED and convergence time should be good if implementing something like BFD and ECMP with the IGP.

Of course the overlay cannot take advantage of ECMP since the source and destination IP addresses are always the same. But I'm looking in to tunnel depolarization (secondary IP address on join interfaces), but I'm unsure if IOS-XE supports this (I've raised a separate question on this).

Thank you once again.

[Madhukrishnan Gopinathan Nair]

Thanks D R and happy to hear my comments were helpful to you.

Regarding the other post, at the moment I am unsure about too. I will post it back if I find that information.

Regards,

Madhu.