22.05.2017 Views

nx.os.and.cisco.nexus.switching.2nd.edition.1587143046

Nexus Switching 2nd Edition

Nexus Switching 2nd Edition

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Figure 11-3. OTV Data Plane Encapsulation<br />

OTV encapsulation increases the overall MTU size of 42 bytes; as a result, the path from<br />

AED to AED must accommodate the additional 42 bytes of MTU end to end. The OTV Edge<br />

Device removes the CRC <strong>and</strong> the 802.1Q fields from the original Layer 2 frame <strong>and</strong> adds an<br />

OTV header. The OTV header contains the VLAN information, overlay ID information, <strong>and</strong><br />

IP header.<br />

The MTU is important to spend additional time on because the OTV control <strong>and</strong> data-plane<br />

encapsulation originate from an OTV Edge Device <strong>and</strong> set the Don’t Fragment (DF) bit set.<br />

Because the DF bit is set, fragmentation <strong>and</strong> reassembly are not supported on the Nexus<br />

7000 today. Mechanisms such as Path MTU Discovery (PMTUD) are not an option in this<br />

case because the MTU must be increased on all the physical interfaces along the path<br />

between the source <strong>and</strong> destination endpoints to account for introducing the extra 42 bytes<br />

by OTV.<br />

Consider the following example: If the edge MTU is set to 1500 bytes; the MTU end to end<br />

needs to be 1500 bytes + 42 bytes for a total of 1542 bytes minimum MTU. If the transport<br />

does not support an MTU greater than 1500 bytes, here are a couple thoughts or<br />

recommendations:<br />

• Set the edge (server) MTU to 1458 bytes; this enables 1458 bytes + 42 bytes for a<br />

total of 1500 bytes.<br />

• Leverage OTV on the ASR1000 because you can support fragmentation <strong>and</strong><br />

reassembly on the ASR platform. Be aware of potential performance issues <strong>and</strong> outof-order<br />

packet delivery.<br />

Data-Plane Multicast Traffic<br />

Many applications have a requirement to support Layer 2 multicast communication between<br />

data centers that have Layer 2 extended between them. The implementation details depend<br />

on whether you have OTV configured for multicast transport or unicast transport.<br />

For Multicast-enabled transport, a multicast source sending traffic to a specific group is<br />

deployed in a VLAN in data center 1, <strong>and</strong> a multicast receiver belonging to the same VLAN<br />

is placed in data centers that have a requirement to receive traffic for the same group.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!