OTV
OTV vs Other DCIs
Many possible options for Layer 2 DCI
Dark Fiber (CWDM/DWDM), L2TPv3, AToM, VPLS, Bridging over GRE, VXLAN
Considerations vs other technologies
Transport Requirements
Spanning-Tree
Failure Event Propagation
Multipath & Multipoint Tunneling
BUM flooding
What is OTV
Overlay Transport Virtualization (OTV)
Ethernet over IP tunnel: MAC in IP Routing
Used to extend layer 2 domain across Data Center Interconnect (DCI): e.g span a VLAN between two DC sites
OTV is a site-to-site tunnel
Inter-fabric tunnel as opposed to an intra-fabric tunnel like VXLAN
Analogous to site-to-site IPSec VPN vs remote access VPN: e.g a router to router tunnel
Main OTV use case is Virtual Machine Workload Mobility: e.g VMWare VMotion
OTV is purpose built for DCI
Transport agnostic: any ipv4 transport works
Scaling enhancements: STP suppression, ARP suppression, Unknown flooding suppression
Hardware Accelerated
Up to 100GE line rate
Like VXLAN, platform/linecard support is specific
Nexus 7K M & F3 cards
ASR 1K & CSR1000v (ASR1Kv)
How OTV works
OTV Edge Devices auto-discover each other by default: uses IS-IS over IPv4 Multicast
MAC addresses are advertised as IS-IS routes: different from FabricPath or ACI usage of IS-IS
Traffic between sites is unicast IP encapsulated
Ethernet over MPLS over GRE over IP: original frame format (M1 card)
Ethernet over UDP over IP: Newer frame format (ASK 1K or N7K F3 card) -> Need to match encapsulation between devices
OTV Terminology
OTV Edge Device: Edge routers running OTV
Authoritative Edge Device (AED)
Active edge device for a particular VLAN
Allows multiple redundant edge routers while preventing loops
Extend VLANs: VLAN being bridged over OTV
Site VLAN: internal VLAN used to elect AED
Site Identifier: Unique ID per DC site, shared between AEDs
Overlay Interface: the logical OTV tunnel interface
OTV Join Interface: The physical link or port-channel used to route upstream towards the DCI
OTV Control Group: Multicast address used to discover the remote sites in the control plane
OTV Data Group: used when you're tunneling multicast traffic over OTV in the data plane
OTV Control Plane
Uses IS-IS to advertise MAC addresses between AEDs
Encapsulated as Control Group Multicast
IS-IS over Ethernet over MPLS over GRE over IPv4 Multicast
IS-IS over Ethernet over UDP over IPv4 Multicast
Implies that DCI must support ASM Multicast
Can be encapsulated as Unicast with OTV adjacency server
OTV Data Plane
Uses both Unicast and Multicast Transport
Multicast Control Group
Multicast or Broadcast Control Plane Protocols
e.g ARP, OSPF, EIGRP, etc
Unicast Data: normal unicast is encapsulated as Unicast between AEDs
Multicast Data Group:
Multicast Data flows are encapsulated as SSM Multicast
Implied AEDs use IGMPv3 for (S,G) Joins
Configuration
Multicast Transport
Enable feature
Create and specify site VLAN
Configure OTV site ID
Configure OTV tunnel
Specify join interface
Specify control group
Specify data group
Specify extend VLANs
Unicast Transport
Adjacency server
Adjacency client
Verification
show otv
show otv site detail
show otv isis adjacency
show otv vlan
show otv route
show otv isis database detail
show mac address-table
Debugging OTV
debug otv isis iih
(config)# logging level otv 7
AED Node HA
Multiple AED are supported per-site per-tunnel: Adds both node level redundancy and load distribution
AEDs within the site communicate over the Site VLAN
IS-IS adjacency formed over site VLAN
Used to elect which AED forwards which VLANs: load split on even/odd VLAN numbers, not configurable in current version
AEDs within the site also communicate over layer 3
IS-IS over multicast IPv4
IS-IS over unicast IPv4 with adjacency server
Recovering from AED Node Failure
AEDs within the site track each other two ways
Layer 2 IS-IS adjacency over Site VLAN
Layer 3 IS-IS adjacency through overlay tunnel
Called the "dual site ajacency"
Three possible AED failure cases
AEDs lose layer 2 reachability but not layer 3 reachability
AEDs lose layer 3 reachability but not layer 2 reachability
AEDs lose both layer 2 reachability and layer 3 reachability
Verified with show otv site detail: Dual site adjacency must be "Full"
Tuning AED Node Failure Detection
AED failure detection has 2 components
Layer 3 failure detection
Layer 2 failure detection
Layer 3 failure detection
IS-IS Timer inside the overlay tunnel
Convergence is a function of underlay transport
Tune the underlay transport for HA, and OTV transport is tuned for HA
Layer 2 failure detection
IS-IS timer over the site VLAN
AEDs may not be directly connected, result is long failure detection time
Workaround is to run BFD over site VLAN
Verification
show bfd clients
show bfd neighbors [detail]
Layer 3 Multicast HA for AEDs
OTV AEDs rely on Multicast transport for
IS-IS control plane exchange
Link local multicast sent across the overlay
e.g IGMP report message from clients across the overlay
Multicast in multicast transport
e.g IPTV layer 2 multicast across overlay tunnel
How can we achieve Multicast HA?
Tune underlying unicast IGP/BGP routing
Add Rendezvous point redundancy, e.g. Anycast RP
Adjacency Server HA
Without multicast, AEDs cannot find tunnel endpoints
Adjacency server maintains mappings of extend VLANs to tunnel endpoint
Analogous to a dynamic DNS server
If single adjacency server is down, tunnel endpoints cannot resolve -> lost control plane and data plane
Best practice is to use redundant Adjacency Server
HA is now based on IGP/BGP unicast convergence to Adjacency Server IP
OTV and FHRP Localization
Apply filter on AEDs
Reference
https://packetpushers.net/?s=otv
Last updated