Figure 11-3. OTV Data Plane Encapsulation OTV encapsulation increases the overall MTU size of 42 bytes; as a result, the path from AED to AED must accommodate the additional 42 bytes of MTU end to end. The OTV Edge Device removes the CRC and the 802.1Q fields from the original Layer 2 frame and adds an OTV header. The OTV header contains the VLAN information, overlay ID information, and IP header. The MTU is important to spend additional time on because the OTV control and data-plane encapsulation originate from an OTV Edge Device and set the Don’t Fragment (DF) bit set. Because the DF bit is set, fragmentation and reassembly are not supported on the Nexus 7000 today. Mechanisms such as Path MTU Discovery (PMTUD) are not an option in this case because the MTU must be increased on all the physical interfaces along the path between the source and destination endpoints to account for introducing the extra 42 bytes by OTV. Consider the following example: If the edge MTU is set to 1500 bytes; the MTU end to end needs to be 1500 bytes + 42 bytes for a total of 1542 bytes minimum MTU. If the transport does not support an MTU greater than 1500 bytes, here are a couple thoughts or recommendations: • Set the edge (server) MTU to 1458 bytes; this enables 1458 bytes + 42 bytes for a total of 1500 bytes. • Leverage OTV on the ASR1000 because you can support fragmentation and reassembly on the ASR platform. Be aware of potential performance issues and outof-order packet delivery. Data-Plane Multicast Traffic Many applications have a requirement to support Layer 2 multicast communication between data centers that have Layer 2 extended between them. The implementation details depend on whether you have OTV configured for multicast transport or unicast transport. For Multicast-enabled transport, a multicast source sending traffic to a specific group is deployed in a VLAN in data center 1, and a multicast receiver belonging to the same VLAN is placed in data centers that have a requirement to receive traffic for the same group.
For the Layer 2 multicast communication between senders and receivers between data centers, the Layer 2 multicast traffic must go across the OTV overlay network. Because you have multicast-enabled transports, you do not have suboptimal head-end replication to support Layer 2 multicast communication between multiple data centers for application server requirements. Source Specific Multicast (SSM) is used for the data plane application Layer 2 Multicast requirements. The SSM multicast is different than the ASM Multicast groups for the OTV control-plane adjacencies. For the data-plane requirements with multicast-enabled transport; a multicast source is activated on the data center and starts streaming traffic to the multicast-group (G). The local OTV edge device receives the first multicast frame and creates a mapping between the group Gs and a specific SSM group Gd available in the transport infrastructure; the multicast group from source (Gs) is mapped to SSM data group (Gd). The range of SSM groups to be used to carry Layer 2 multicast data streams are specified during the configuration of the overlay interface. To configure the range of an SSM data, use the following command under the overlay interface created in the OTV VDC: OTV-VDC-A(config-if)# otv data-group 188.8.131.52/26 You need to plan for the amount of data-group multicast and multicast state. For the data grouping, a single data group can be used in the core to carry all the (S,G) site multicast streams; the remote sites would receive all the streams as soon as a receiver joined a specific group. If a dedicated data group were used for each (S,G) site group, each site would receive multicast traffic only for the specific groups joined by local receivers. For Unicast-enabled transport, multicast capabilities are not enabled in the transport infrastructure. This means that the Layer 2 multicast traffic can be sent across the OTV overlay where the multicast source is located; this results in head-end replication. IGMP Snooping ensures that the Layer 2 multicast packets are sent only to remote data centers where there are active receivers; IGMP Snooping reduces the amount of required head-end replication. OTV and QoS To clarify the behavior of OTV from a QoS perspective, you should distinguish between control- and data-plane traffic: • Control plane: The control plane frames are always originated by the OTV Edge Device and statically marked with CoS = 6/DSCP = 48. • Data plane: The assumption is that the Layer 2 frames received by the Edge Device to be encapsulated have already been properly marked (from a CoS and DCSP perspective). When OTV encapsulates the packet, the QoS marking transfers to the header of the encapsulated packet in the following two ways: • With 802.1p tagged packets the L2-CoS is copied to the outer DSCP, and the inner DSCP is preserved as is across the overlay. • With 802.1p untagged packets the outer DSCP is zero (TOS = 0x00) and the inner