Официален блог на WebEKM EKM очаквайте сайта онлайн скоро.
Download Free Templates http://bigtheme.net/ free full Wordpress, Joomla, Mgento - premium themes.
Data Center Interconnect and Overlay Transport Virtualization over multicast and non-multicast aware Transport
Overlay Transport Virtualization is the technology that you may encounter, if you are going to span your Data Center across different geographical location with full retaining of layer 2 information. It literally enables you connectivity between 2 servers within the same Vlan that are placed far away of each other.
Data Center Interconnect
Data Center Interconect in plain words is a connection that is responsible for carrying LAN and SAN information between remote Data Centers. Usually is being used for secure data replication, server clustering, load balancing or work mobility (vmware vMotion). DCI uses the medium like Dark Fibers, MPLS layer 2 and layer 3 VPNs, but may be also utilized everywhere where there is an IP connectivity. The only condition is that 2 sits can ping each other.
OTV Overlay Transport Virtualization
OTV has been invented in order to remove the scalability limitation. Assuming, we have a large domain with hundreds of thousands of virtual machines, the switches wouldn’t be able to learn all MAC addresses for lack of memory and space in CAM table. OTV enables us dividing the Data Center onto smaller parts, put them in different geographical locations and still treats as a one big Data Center. Thanks to this 2 servers that are in the same Vlan and in the same subnet but in different locations are able to cummunicate with each other at layer 2, because OTV encapsulates layer 2 in layer 3 (VPN) and this way provides VLANs extension over IPv4. To sum up, OTV can overlay multiple VLANs and multiple edge routers without complicated design and what is not meaningless doesn’t extend STP domain. Another big advantage of OTV is that the result of BUM Traffic (Broadcast, Unknown Unicast and Multicast) is cached on the edge router, so the edge router doesn’t have to send BUM traffic through OTV every time.
OTV Terminology
OTV Edge Device – edge switch that is running OTV on the Outside interface
AED Authoritative Edge Device – active edge switch that is authotitative for particular vlans, we may have multiple edge routers for redundancy. Some switches may be authorititative for some Vlans but not for the others.
Extend vlans – vlans that are being bridged over OTV
Site Vlan – internal vlan used to conect edge device and elect AED, should be different for each site
Site identifier – unique ID per DC site, shared between AEDs, 2 devices with the same ID are considered as being in the same Data Center
Overlay interface – logical OTV tunnel interface (ethernet frame encapsulated inside the IP packet and send over the DCI – GRE tunnel)
OTV join interface – physical link or port-channel that you use to route upstream towards DCI, OUTSIDE interface
Internal interfaces – local L2 interfaces on edge device, INSIDE interface
OTV Control Group – multicast address, used to discover the remote sites in the control plane.
OTV Data Group – used when you are tunneling multicast traffic over OTV in the data plan eg IP Television, video streaming.
OTV Control Plane
Uses IS-IS to advertise MAC addresses betwen AEDs. IS-IS is encapsulated as a Control Group Multicast, so DCI must support Multicast, but IS-IS can be also encapsulated as Unicast with OTV Adjacency Server.
OTV Data Plane
OTV overhead is 42 bytes, so we have to increase the value of MTU up to 1542, but
usually DCIs support Jumbo Frames, so we don’t have to worry about fragmentation. AEDs uses IGMPv3. OTV Adjacency Server removes requirement for Multicast completely.
Spanning Tree and OTV
OTV doesn’t allow for extending STP domain behind the OTV edge device! That’s mean that if there was a link failure in one Data Center, the problem is significant locally and STP is recalculated only for this site of Data Center.
CONFIGURATION
The configuration on Nexus platforms boils down to a few steps :
enable feature
feature otv
create and specify site VLAN
otv site-vlan 200
configure OTV site ID
otv site-identifier 256
configure OTV tunnel
interface ethernet 1/1
ip address 1.1.1.1/24
ip igmp version 3
we create Overlay logical interface
Interface overlay 1
Under Overlay interface we:
specify join interface
otv join-interface interface ethernet 1/1
specify control group
otv control-group 239.1.1.1
specify data group
otv data-group 239.1.1.0/24
specify extend VLANs
otv extend-vlan 100-400
THE LABS
As I mentioned OTV can be deployed in 2 ways: via multicast aware DCI and non multicast aware DCI. We will try to configure in both ways, configuration is simillar. In case of Unicast core we don’t touch multicast configuration at all, so we don’t have control and data group on the “overlay interface”. Because Nexus 7000 in GNS3 that is actually Titanium image doesn’t support OTV I used CSR 1000v image that supports very well OTV feature.
OTV over Multicast DCI LAB
The lab consists of 4 servers placed in Vlan 10 and 20, I also used generic switches, the interfaces toward CSR are configured as trunk, downstream interfaces towards servers are configure in Vlan 10 and 20. It is important configure OTV in a few stages alternately on both sites, otherwise the OTV link may not come up.
STAGE 1st
We have to enable multicast routing I also specified SSM mode. On the “join interface” we have to change MTU and enable igmpv3
ip multicast-routing distributed
ip pim ssm default
interface GigabitEthernet1
mtu 1542
ip address 1.1.1.1 255.255.255.0
ip pim passive
ip igmp version 3
negotiation auto
no shutdown
STAGE 2nd
The site bridge domain is a Vlan that will be used by AEDs on the same site. This VLAN is not the part of the OTV process so may be the same in both sites. Next we have to set up site identifier, of course different on each site.
otv site bridge-domain 1
otv site-identifier 0000.0000.0001
STAGE 3rd
We configure logical interface “Overlay”. We specify the mutlicast address (control- group) to discover the other OTV sites and also to get updates and hello messages. Next we configure data-group, the range of addresses that will be using to carry VLANs data via multicast. At the end we specify the join interface. Under interface Overlay we have to determine which VLANs will be streched between 2 sites. We achieve this by creating bridge domain under service instance. We don’t up interface overlay yet.
interface Overlay1
no ip address
otv control-group 239.255.10.20
otv data-group 232.10.20.0/24
otv join-interface GigabitEthernet1
interface Overlay1
service instance 10 ethernet
encapsulation dot1q 10
bridge-domain 10
service instance 20 ethernet
encapsulation dot1q 20
bridge-domain 20
STAGE 4th
We configure internal interface that leads to the L2 switch. We create bridge domains for each VLAN that we are going to allow pass through the GigabitEthernet2
interface GigabitEthernet2
no shutdown
no ip address
negotiation auto
service instance 1 ethernet
encapsulation untagged
bridge-domain 1
service instance 10 ethernet
encapsulation dot1q 10
bridge-domain 10
service instance 20 ethernet
encapsulation dot1q 20
bridge-domain 20
STAGE 5th
Now we may run the “Overlay” interface
interface Overlay1
no shutdown
On the other site(s) we configure respectively
ip multicast-routing distributed
ip pim ssm default
interface GigabitEthernet1
mtu 1542
ip address 1.1.1.2 255.255.255.0
ip pim passive
ip igmp version 3
negotiation auto
no shutdown
otv site bridge-domain 2
otv site-identifier 0000.0000.0002
interface Overlay1
no ip address
otv control-group 239.255.10.20
otv data-group 232.10.20.0/24
otv join-interface GigabitEthernet1
interface Overlay1
service instance 10 ethernet
encapsulation dot1q 10
bridge-domain 10
service instance 20 ethernet
encapsulation dot1q 20
bridge-domain 20
interface GigabitEthernet2
no shutdown
no ip address
negotiation auto
service instance 2 ethernet
encapsulation untagged
bridge-domain 2
service instance 10 ethernet
encapsulation dot1q 10
bridge-domain 10
service instance 20 ethernet
encapsulation dot1q 20
bridge-domain 20
no shut
interface Overlay1
no shutdown
Let’s verify if the OTV link is up:
OTV over Unicast DCI LAB
The lab consists of 4 servers placed in Vlan 10 and 20, also generic switches have been used, the interfaces toward CSR are configured as trunk, downstream interfaces towards servers are configure in Vlan 10 and 20. It is important configure OTV in a few stages alternately on both sites, otherwise the OTV link may not come up.
Nothing fancy, we just configure “join interface” for IP connectivity with the other site.
interface GigabitEthernet1
mtu 1542
ip address 1.1.1.1 255.255.255.0
negotiation auto
no shutdown
STAGE 2nd
otv site bridge-domain 1
otv site-identifier 0000.0000.0001
STAGE 3rd
Only the 3rd stage is different to compare with Multicast DCI. We have to configure the “Adjacency Server”. The Adjacency Server enables unicast transport between edge devices. It works exactly in the same way as in multicast core DCI, but now each edge device has to sent multiple copies of the same control plane packets to all other edge devices. It provides a lot of traffic that has to be sent through the OTV VPN what makes this solution not very scalable and is recommended between at most a few Data Center sites. In every VPN (a bunch of OTV edge devices in different sites) we have to have at least one Adjacency Server that is responsible for informing the other edge devices about reachability with the other edge devices. I would compare this to well known NHRP protocol that resolves IP addresses in DMVPN between Spokes via the Hub. An adjacency server distributes the unicast replication list (URL) of all edge devices addresses to the members of the overlay network. Each edge device then uses this list to encapsulate multicast packets in a unicast IP header destined for the unicast IP address of each remote edge device.
We have 2 new commands :
otv adjacency-server unicast-only – this command configures this edge device as adjacency server
otv use-adjacency-server [IP_address] unicast-only – configures an OTV edge device to register to an adjacency server with given Ip address
In our lab we will set up both sites as adjacency servers.
interface Overlay1
no ip address
otv adjacency-server unicast-only
otv use-adjacency-server 2.2.2.2 unicast-only
otv join-interface GigabitEthernet1
interface Overlay1
service instance 10 ethernet
encapsulation dot1q 10
bridge-domain 10
service instance 20 ethernet
encapsulation dot1q 20
bridge-domain 20
STAGE 4th
interface GigabitEthernet2
no shutdown
no ip address
negotiation auto
service instance 1 ethernet
encapsulation untagged
bridge-domain 1
service instance 10 ethernet
encapsulation dot1q 10
bridge-domain 10
service instance 20 ethernet
encapsulation dot1q 20
bridge-domain 20
STAGE 5th
interface Overlay1
no shutdown
The second site of the OTV link:
interface GigabitEthernet1
mtu 1542
ip address 2.2.2.2 255.255.255.0
negotiation auto
no shutdown
otv site bridge-domain 2
otv site-identifier 0000.0000.0002
interface Overlay1
no ip address
otv adjacency-server unicast-only
otv use-adjacency-server 1.1.1.1 unicast-only
otv join-interface GigabitEthernet1
interface Overlay1
service instance 10 ethernet
encapsulation dot1q 10
bridge-domain 10
service instance 20 ethernet
encapsulation dot1q 20
bridge-domain 20
interface GigabitEthernet2
no shutdown
no ip address
negotiation auto
service instance 2 ethernet
encapsulation untagged
bridge-domain 2
service instance 10 ethernet
encapsulation dot1q 10
bridge-domain 10
service instance 20 ethernet
encapsulation dot1q 20
bridge-domain 20
interface Overlay1
no shutdown
and some verification
