EMAIL SUPPORT

dclessons@dclessons.com

LOCATION

NZ

OTV Multi-Homing

OTV Multi-Homing

Posted on Jan 24, 2020 (0)

OTV Multi-Homing

To provide the LAN extension in any site, we can use two OTV Edge device. As due to redundant OTV edge device and STP BPDU not flowing across OTV Overlay, may lead to creation of End to End loop.

To prevent above situation, AED was introduced which has two main task:

  • Forwards Layer 2 traffic between Sites and overlay
  • Advertise MAC reachability information among remote sites

In AED, Concepts AED role is selected per VLAN basis between all OTV Edge devices at same site. OTV uses Site-Vlan configured at each site to detect and establish adjacency with other OTV edge device as shown in below figure:

Now there is possibility that OTV edge device on same site may get failed to detect each other and ends with Active-Active mode and can also result in creation of LOOP.

To avoid this Each OTV edge device maintains the dual adjacencies with other OTV edge device in site and this type of adjacency is also called as Site Adjacency. In addition to this, OTV edge device also forms a second type of adjacency called Overlay adjacency which is established via Join interface over Layer 3 domain and to achieve this each site must be configured with unique site identifier. All OTV edge device who are at same site must be configured with same Site-ID. This Site identifier is advertised in IS-IS hello packet which are sent over overlay as well as on Site VLAN at same site.

To identify neighbor Edge device at same site: Site identifier + IS-IS system ID.

Dual Site adjacency state is used to determine AED role for each VALN which is to be extended across Overlay. Each OTV Edge device inform their neighbor about its capability to become AED and its forwarding readiness at local site.

The AED capability change received from a neighboring edge device in the same site influences the AED assignment, and hence will trigger an AED election. If a neighbor indicates that it is not AED capable, it will not be considered as active in the site. An explicit AED capability down notification received over either the site or the overlay adjacency will bring down the neighbor's dual site adjacency state into inactive state and the resulting AED election will not assign any VLANs to that neighbor.

AED can be used for Odd and Even VLANs between two OTV edge devices by a use of deterministic algorithm. If we talk more specifically, OTV Edge device who has lower System-ID will become AED for all Even VLANs and the OTV edge device which has higher System-ID will be AED for ODD extended VLANs.

Use of AED also prevent the End to End STP loops.  Let’s suppose that a Broadcast is generated at Site-1 DC and frame reaches to both AED OTV device bit only one OTV edge device that is AED is allowed to encapsulate the frame and send it over OTV overlay. Now once the Frame reaches to other site Site-2, all other AED on Site-2 will receive that frame and only AED will decapsulate the frame and send it in to site.

This can be easily seen in below figure:

It may be that while Site Migration from traditional Design to OTV design, where a back to back door Layer 2 extension exits between DC may also cause L2 loop creation.

To avoid creation of end to end Loop following step-by step procedure must be followed:

  • Ensure that the same site VLAN is globally defined on the OTV devices deployed in the two data center sites.
  • Make sure that the site VLAN is added to the set of VLANs carried via the traditional LAN extension solution. This is critical, because it will allow OTV to detect the already existent Layer 2 connection. For this to happen, it is also important to ensure that the OTV edge devices are adjacent to each other on the site VLAN (i.e. a Layer 2 path exists between these devices through the existing DCI connection).
  • From 5.2(1) release, makes sure also that the same site-identifier is configured for all the OTV devices belonging to the same site.
  • Create the Overlay configuration on the first edge device in site 1, but do not extend any VLAN for the moment. Do not worry about enabling OTV on the second edge device belonging to the same site yet.
  • Create the Overlay configuration on the first edge device in site 2, but do not extend any VLAN for the moment. Do not worry about enabling OTV on the second edge device belonging to the same site yet.
  • Make sure the OTV edge devices in site 1 and site 2 establish an internal adjacency on the site VLAN (use the “show otv site” CLI command for that). Assuming the internal adjacency is established, OTV will consider the two sites as merged in a single one. The two edge devices will then negotiate the AED role, splitting between them odd and even VLANs.
  • Configure the VLANs that need to be extended through the OTV Overlay (using the “otv extend-vlan” command) on the OTV edge devices in site 1 and site 2. Notice that even if the two OTV devices are now adjacent also via the overlay (this can be verified with the “show otv adjacency” command) the VLAN extension between sites is still happening only via the traditional Layer 2 connection.
  • Disable the traditional Layer 2 extension solution. This will cause the OTV devices to lose the internal adjacency established via the site VLAN and to detect a “site partition” scenario. After a short convergence window where Layer 2 traffic between sites is briefly dropped, VLANs will start being extended only via the OTV overlay. It is worth noticing that at this point each edge device will assume the AED role for all the extended VLANs.
  • OTV is now running in single-homed mode (one edge device per site) and it is then possible to improve the resiliency of the solution by enabling OTV on the second edge device existing in each data center site.

 


Comment

    You are will be the first.

LEAVE A COMMENT

Please login here to comment.