cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3103
Views
5
Helpful
5
Replies

DCI and OTV

dani_bosch
Level 1
Level 1

Hello,

Last week, speaking with a Cisco engineer about a scenario connecting two Data Centers with 1 KM distance from each other at layer 2 (extending VLANs), he told me there was no need to apply any advanced DCI technology at all...the scenario didn't have any loop, thus, spanning tree protocol was inactive. Furthermore there was dak fiber in place, connecting the two. He advise me to simply connect the two through plain Ethernet.

My question is: what's the trigger for any advanced DCI technology (like OTV for instance) to be applied in such a scenario?

Maybe the fact that STP should be present (that is, in case the scenario did have loops)? Or rather the distance (maybe more distance should trigger the need for this DCI technology)?? Or rather the fact of NOT having dark fiber?

Any inputs please?

Thanks a lot,

1 Accepted Solution

Accepted Solutions

Hi,

Essentially with OTV ethernet frames are encapsulated over IP, so the reference to geographically or dispersed DCs is typically where the transport will be over a WAN, which is where the bandwidth constraints come into it. OTV provides the ability to extend your LAN, however you would not want to comprises the stability of each DC in the process, thus OTV restricts BPDUs in order creat separate STP domains. So your spanning tree priorities should be localised to your DC, the same is said for localised FHRP.

You do not necessarily want your traffic transiting the OTV transport over the WAN due to next hop routing, so you would create the same HSRP virtual IP for at each DC and restricted HSRP advertisements to the well-known addresses. This ensures that a host in one DC will use the local FHRP instance for its next hop.

Take a moment to review the OTV white paper link I have provided, it mentions the concepts that I have referred to above, which I hope helps in some way. In your case although there is no requirement for OTV, if you intend to extend VLANs you still need to observe best practices for restricting the STP domain and localising FHRP at each DC.

http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/DCI/whitepaper/DCI_1.html#wp1185920

Sent from Cisco Technical Support iPad App

Sent from Cisco Technical Support iPad App

View solution in original post

5 Replies 5

dani_bosch
Level 1
Level 1

No inputs on this?

Hi,

As the Cisco Engineer mentioned in your scenario introducing OTV would certainly be over engineering your specific DC requirements, especially as your only extending the VLANs across 1km Dark Fibre, and bandwidth is not a constraint. OTV is really suited to DCs that are geographically widespread or dispersed over longer distances where bandwidth is at a premium and have a need to extend VLANs to those DCs.

The constraints are still the same in the sense that you still need restrict or filter BPDUs and your FHRP such as HSRP, effectively creating islands for your L2 traffic with local next hop routing. The question is what is specifically behind your requirement for extending the VLANs across the DCs, an example is if you wanted to vmotion host to another DC with same IP address/mask and default gateway.

Regards
Allan

Sent from Cisco Technical Support iPad App

You say long distance and BW constraints....but what is "long distance" in OTV terms? 10 KM? 100 KM? 1,000 KM?

And what is BW constraints? Less than 100Mbps? What about latency? Does it play a role in deciding whether to go to an OTV solution?

Regarding the L2 extension, the customer doesn't want to vMotion between DCs, but he does want to have DR of some services, like the Oracle DBs. In case we had STP in the scenario (just for the purpose of understanding), what should we have to do in such a scenario? You speak about "restricting BPDUs"...is it 100% necessary? How to do it?

Thanks a lot!

Hi,

Essentially with OTV ethernet frames are encapsulated over IP, so the reference to geographically or dispersed DCs is typically where the transport will be over a WAN, which is where the bandwidth constraints come into it. OTV provides the ability to extend your LAN, however you would not want to comprises the stability of each DC in the process, thus OTV restricts BPDUs in order creat separate STP domains. So your spanning tree priorities should be localised to your DC, the same is said for localised FHRP.

You do not necessarily want your traffic transiting the OTV transport over the WAN due to next hop routing, so you would create the same HSRP virtual IP for at each DC and restricted HSRP advertisements to the well-known addresses. This ensures that a host in one DC will use the local FHRP instance for its next hop.

Take a moment to review the OTV white paper link I have provided, it mentions the concepts that I have referred to above, which I hope helps in some way. In your case although there is no requirement for OTV, if you intend to extend VLANs you still need to observe best practices for restricting the STP domain and localising FHRP at each DC.

http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/DCI/whitepaper/DCI_1.html#wp1185920

Sent from Cisco Technical Support iPad App

Sent from Cisco Technical Support iPad App

On old post but relevant to me, I am struggling to get a decent answer from my SE so would be good know if you got an authoritative reply from Cisco?

Review Cisco Networking for a $25 gift card