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.

is as efficient as the core IP network <strong>and</strong> can deliver optimal traffic load balancing,<br />

multicast traffic replication, <strong>and</strong> fast failover just like the core would.<br />

The mappings of the MAC address to the IP next hop in the forwarding table are advertised<br />

by a control protocol, thus eliminating the need for flooding of unknown unicast traffic<br />

acr<strong>os</strong>s the overlay. The control protocol is extensible <strong>and</strong> includes useful MAC addressspecific<br />

information such as VLAN, site ID, <strong>and</strong> associated IP address (for IP h<strong>os</strong>ts). These<br />

requirements are needed to eliminate failure domains <strong>and</strong> fate-sharing; OTV provides the<br />

intelligence to implement multihoming, load-balancing, end-to-end loop-prevention, localize<br />

First-Hop Resiliency Protocol (FHRP) capability, <strong>and</strong> even localize ARP traffic without<br />

creating additional operational over head for each function. Thus, OTV can be used to<br />

provide connectivity based on MAC-address destinations while preserving m<strong>os</strong>t of the<br />

characteristics of a Layer 3 interconnection.<br />

However, before MAC reachability information can be exchanged, all OTV Edge Devices<br />

must become “adjacent” to each other from an OTV perspective. This can be achieved in<br />

two ways, depending on the nature of the transport network interconnecting the various sites:<br />

• Multicast mode: If the transport is multicast-enabled, a specific multicast group can<br />

be configured to exchange the control protocol messages between the OTV Edge<br />

Devices.<br />

• Unicast mode: Starting with NX-OS release 5.2(1) <strong>and</strong> later, the adjacency server<br />

was introduced. If the transport is not multicast-enabled, a Nexus 7000 OTV Edge<br />

Device can be configured as an adjacency server to which all other Edge Devices<br />

register <strong>and</strong> communicates belonging to a given overlay.<br />

Example 11-7 through Example 11-10 demonstrate the OTV control-plane configuration <strong>and</strong><br />

verification.<br />

Example 11-7. Show OTV ISIS Control-Plane Information<br />

Click here to view code image<br />

show otv isis<br />

ISIS process : default<br />

VPN: Overlay1<br />

System ID : f866.f209.e243 IS-Type : L1<br />

SAP : 439 Queue H<strong>and</strong>le : 11<br />

Maximum LSP MTU: 1392<br />

Graceful Restart enabled. State: Inactive<br />

Last graceful restart status : none<br />

Metric-style : advertise(wide), accept(narrow, wide)<br />

Area address(es) :<br />

00<br />

Process is up <strong>and</strong> running<br />

VPN ID: 171<br />

Incremental update routes during SPF run

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

Saved successfully!

Ooh no, something went wrong!