OTV architecture

[Kevin Dorrell]

I am deploying a Data Centre Interconnect using OTV on Nexus 7700.  All the "best practice" documents I have seen on this use two VDCs, one for the aggragate and core of each data centre, and one for the OTV encapsulation engine.  I wonder whether to separate the aggregation layer from the core, that is, have three VDCs: aggregation, OTV, and core.  Does anyone have any thoughts on that?  This is how I see it:

For separate core and aggregation VDCs:

• The architecture is easier to understand, as the OTV is effctively between the aggregation layer and the core for extended VLANs.
• The routing on the core is kept separate from the routing in the aggregation layer (although could I achieve that with VRF?)
• The day I introduce a VDC for the DMZ, it can extend across the core without going anywhere near my production aggregation layer.

Against:

• Traffic that is routed between the two data centres (as opposed to extended) will have to go through one extra hop on each site
• I will lose one VDC from my count of 4 plus 1
• I will lose some ports for the connection between aggregate VDC and core VDC

Any thoughts/experience on that choice?

Kevin Dorrell
Luxembourg

[Kevin Dorrell]

Bump.  Is there anybody out there?

[twgraham]

Can you run your DMZ VLAN(s) through a separate Overlay interface and maintain separation that way?

Each OTV overlay interface name defines a separate VPN to OTV.

[patrick.demuynck]

> *  The routing on the core is kept separate from the routing in the
>    aggregation layer (although could I achieve that with VRF?)

I have seen bridging loops only on Cat6k so I don't know how Nexus
would survive.  I would use separate VDC with routed links in between,
so that the core remains stable even while a briding loop is
amusing the aggregation layer.

> *  The day I introduce a VDC for the DMZ, it can extend across the
>    core without going anywhere near my production aggregation layer.

Beware, if you connect both the aggregation layer and the DMZ to
a common OTV VDC, then you are actually merging two Layer 2
domains.  This is because the OTV VDC behaves as a bridge
on the internal interfaces.  If you have common Vlans then
you are actually merging these so you're mixing traffic and
you will get an 'unexpected' blocking link somewhere.  Furthemore
the use of MST as an STP protocol is excluded (even without
common Vlans), because it will split Vlans in two.  Per Vlan RSTP would
probably be OK.
 
So there's a good chance that you will need yet another VDC
if you want to offer DCI to the DMZ VDC.

You may think of Q-in-Q for Vlan collision avoidance but that's
not working in combination with OTV, regular port based Vlan
translation may be OK.  Check out the Data Center Virtualization Fundamentls
book on page 379.

Patrick

Athens / Greece

[patrick.demuynck]

Forgot to mention : yes I mostly agree with you.

I also wanted to mention that that maybe you want to ask
Cisco about the long promised OTV Loopback Join-Interface
(check out Cisco Live).  For what it's worth, I believe that
it would make it possible to colocate OTV and core in the
same VDC.

[Kevin Dorrell]

Thank you for your contribution Patrick - it gives me some useful pointers.

I may get away with the DMZ issue because my DMZ uses a set of VLANs that is mutually exclusive with my internal production VLANs.  In fact, that is the way the DMZ is kept separate at the moment, by using a separate set of VLANs routed by the firewall, instead of by the aggregation switch.  I am wondering if I can extend the DMZ VLAN(s) through a second overlay interface in the OTV VDC, using a separate multicast group on the core to link them up. I have to think this through and try it in the lab.

Thanks also for the reference to the book.  I wasn't aware of the book, but it looks very useful and I shall order it immediately.

Thanks again.

Kevin

[patrick.demuynck]

I see no fundamental reason why this shouldn't work.  Good luck and don't forget
to post the lab outcome.

Regards,

Patrick