Site AEDs adjacency on overlay interface

[NaelShahid_2]

I understand the site vlan is used to establish L2 adjacency between AEDs within the same site. I also understand that these same site AEDs establish a L3 adjacency across the join / overlay interface.

Does this 2^nd (L3) adj require the two join interfaces to be on the same L3 network or do they just need to route to one another?

If they need to route to one another, is a L3 link between the 2 x N7Ks (IP VDC) sufficient for this… Assuming each 7K had a point 2 point link each to the 2^nd data centre….?

[Steve Fuller · Accepted solution]

Hi,

The adjacency established via the Overlay does not need to be on the same IP network as the second Edge Device within a site. The adjacency establishment is the same process as that used to establish adjacencies to the ED in the other data centre i.e., through the join interface, so as long as you have resilient routed connectivity between the OTV ED then you're OK.

Regards

[NaelShahid_2]

Thanks Steve.

So when querying the adjacency server the ED then knows which other ED is within the same site?

Each ED will have a point-2-point routed link to the corresponding ED within the 2^nd DC.. Both site local EDs having a routed link between them (over the peer link using SVI)… A routed square if you like… Would this be sufficient?

[Amit Singh · Accepted solution]

"So when querying the adjacency server the ED then knows which other ED is within the same site?"

Yes for the first part of the question, using the site Vlan unique to each site.

Why do you need a routed link between ED's at local site? You dont need to connect those back-back over L3. Moreover if you want to use it for L3 ADJ over peer-link, you need to make sure that VLAN that you are using is not allowed on the VPC member ports, just on the peer-link, else VPC loop alrorithm will break your traffic.

Are you planning to use multicast or a Unicast deployment? I remember I tried testing the topology in a POC for one of my customer, things did not work as expected in multicast deployment mode and worked fine in Unicast Adjacency server mode. I need to go back and check my notes on this.

I would rather have the join-interface go back to a routed core at site rather than back-back connecivity as it opens up the tested Multicast deployment mode.

Cheers,

-amit singh

[NaelShahid_2]

This is based on unicast mode.

The design is based on FlexPod with N7k and NetApp Metro Cluster. In this design the resilient L3 links between DCs terminate within the IP VDC on the N7Ks. As these are  point 2 point I am guessing a L3 link between the 2 x IP VDCs in the N7ks will require a routed link between them so all EDs can see one another over L3. I get what your saying about going north to L3 but we are following the stated flexpod CVD.

We could just as easily create routed ports on the IP VDC and not go over the peer link at all.

What are your thoughts ??? 

[Amit Singh]

Yes, I agree with you. Its always advised to have a dedicated L3 routed ports between the IP VDC for L3 peering. I have the same deployment with OTV working for my customers in almost 6-8 DC's.

Just had a look at the CVD and these are L2 PO for VPC peer-link between the N7K chassis, Figure 16 clarifies the doubts. OTV VDC is being used as an appliance here sticking right next to IP VDC, with L2 internal interface on some of the ports and L3 Join interface back to the IP VDC. The links between the 2xN7004 uses the L2 PO for VPC PL posibily carrying the site VLAN over it if OTV VDC's are cross connected internally.

Another idea in this set-up would be use BFD per-link for faster forwarding path failure detection.

Cheers,

-amit singh

[NaelShahid_2]

What is interesting is within the CVD it does not seem to have L3 adjacency between the IP VDCs, even across the PL….. This would surely break OTV as local site EDs can’t establish adjacency on the overlay interface, only L2 via site vlan…. Did you come across this when looking at the CVD?