OTV carriage - IP Multicast WAN vs Point to Point WDM links

[edchow1980]

I understand OTV is best supported by a multicast capable IP WAN.

I want to understand how OTV works when point to point links are used instead of a multicast capable IP WAN.

Is it possible to do, what are the limitations?

For example, if I have a pair of Nexus 7Ks configured in the production DC acting as vPC gateways and another pair of Nexus 7Ks in a remote DR site acting as DR vPC gateways can I connect them together with just two point to point 10GbE WAN links and run OTV over the top?

In other words, the WAN will not provide multicast support, just point to point ethernet pipes.  Can OTV work in this scenario?  or is a meshed multicast IP WAN required between the 7K pairs?

Also, in terms of MTU, given the encapsultation used by OTV, what are the caveats and best practices?  What is the minimum MTU that the carriage should allow for to pass standard 1500B Ethernet payload?

[Jerry Ye]

You don't need to have multicast enabled WAN to set up OTV in the latest code. Starting NXOS 5.2.1, it allows unicast OTV configuration (feature is called adjancy server).

http://www.cisco.com/en/US/docs/switches/datacenter/sw/nx-os/OTV/config_guide/Cisco_Nexus_7000_Series_NX-OS_OTV_Configuration_Guide_chapter4.html#task_70D1B1232EA64A79A5E2AADD6EEDAF3A

However, you cannot run OTV in the SAME VDC along with L3 WAN connections. You need separate VDC for OTV join interfaces. This VDC will have internal interfaces (L2 trunks).

Here is an example:

In terms of MTU, OTV will put appr. 100 bytes header on top of the original packet. If your link MTU is 1500 bytes running OTV, and when you sent a 1500-byte packet with DF bit set. When it going through OTV, it will be almost 1600 bytes and since OTV will not do any fragmentation, in this case the packet will be dropped. Please make sure you WAN link's MTU is 100 bytes higher your servers.

HTH,

jerry

[aaron.cottew]

I would also like to know if OTV can be setup on point-to-point links, but using ASR1000's which do not support adjacency server (unicast mode).

Is it possible to do, what are the limitations?

Some ISPs will provide multicast in the core and others will not, one option being investigated to connect two small DC's approx 250km apart is a pair of managed EoMPLS pipes provided by the ISP - terminating on two pairs of ASR1000's so they are logically directly connected DC-to-DC - this would be the layer3 DCI.  We would then run OTV over this for layer2 LAN extension.

Can OTV work in this scenario - without the use of adjacency server?

I have seen some people talking about doing this with GRE as apposed to EoMPLS to provide the point-to-point WAN link, but dont know what they are doing about multicast support.

Cheers
Aaron

[Jerry Ye]

You question can be summarized into your last point:

Yes, you can use configure OTV over P2P link, with the exception that you have described, your ISP must support multicast if you cannot use unicast mode.

To accomplish this task when the ISP is not supporting multicast over their cloud, you can use GRE tunnel to carry multicast traffic over your ISP's WAN network cloud. This way, you can use ASR to carry OTV multicast mode over non-multicast-supported ISP EoMPLS network. The only caveat that I can think of is - MTU size (to include the OTV and GRE header) since OTV will set the DF bit automatically onto the packet once it hits the overlay interface.

HTH,

jerry

[aaron.cottew]

We will only use an ISP theat supports jumbo frames so MTU will not be an issue - will just need to be tuned appropriatly.

I am still not sure what is required of multicast... If using GRE or EoMPLS to establish a p2p connection, how do the ASR's establish a multicast relationship - should I setup a multicast Rendezvous point on one of the ASR's where OTV terminates? or is multicast simply no longer required?

Thanks

[Jerry Ye]

If ASR only support OTV multicast mode, then multicast is a requirement. I think your question is more about how multicast works other than how OTV works. I am not going to go deep here since multicast can be a 2 days discussion. Depend on the multicast mode, if you use dense mode, your P2P tunnel will be able to communicate via multicast without fancy configuration, assuming it passed the reverse path forwarding (RPF) check, and you don't need to use RP. Dense mode is also known as a push technology, meaning even if you don't want it, it will flood your network. If you use sparse mode, then you need to have RP configured and yes, you can use one of your ASR as RP. All routers along the path (RPF check again), the other ASR need to turn on PIM on the tunnel interface and have the static RP configuration - ip pim rp-address x.x.x.x. 

In short, P2P circuit will not override the multicast requirement to get OTV working (in multicast mode). Choose and properly configurate the multicast is definitely a requirement.

HTH,

jerry