Академический Документы
Профессиональный Документы
Культура Документы
can we do the same thing which we did to extend vlan from switch A to
switch C in above example? Ofcourse Not!!, so what the are the solutions to
achieve this?
Until OTV came into picture, we had few of the below options to achieve this:
-VPLS
-Dark Fiber (CWDM or DWDM)
-AToM
-L2TPv3
These are the services provided by Service Providers and they work on
different mechanisms but basicaly what they do is, they provide you a layer
2 path between DC1 to DC2 similar to a trunk link between Switch A and
Switch B. So what does that mean? If a broadcast is sent or a ARP request is
sent, that will travel across the service provider to another data center in
that VLAN? Ofcourse YES!! Your STP domain will also get extended over DCI.
So, if a device in vlan 10 in DC1 is trying to communicate with another
device which is also in DC1 but the ARP request will go all the way to DC2
switches on which that particular vlan is configured.
3) New AED role established for the vlan at site-1 but traffic continues to fail.
The duration of the connectivity issue can range from a few seconds to
several minutes depending on the length of time it takes for Host-2 to
generate a packet.
Failover scenario for between non-silent host. Rarely in real networks will a
there be completely silent devices. Thus, failovers between AEDs converge
quickly as the local MACs are relearned. Generally, the "silent host" scenario
is seen in testing environments only.
1) Before failover, traffic between hosts is working successfully.
3) AED immediately learns Host-2's MAC and is able to install the entry into
it's CAM and OTV route table. It then advertises the route to S2-OTV-1 and
connectivity is quickly restored. Note that the original AED failure generates
a TCN on the vlan of site-1. Thus packets from Host-2 to Host-1 will be
flooded throughout the network ensuring that it reaches the new AED.
If there is any issue in establishing OTV ISIS adjacency, you can look at the
ISIS adjacency log as below:
/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table
Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-stylenoshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-styleparent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin-top:0in;
mso-para-margin-right:0in; mso-para-margin-bottom:10.0pt; mso-paramargin-left:0in; line-height:115%; mso-pagination:widow-orphan; fontsize:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New
Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;}
SITE1-OED1# show otv isis internal event-history adjacency
ISIS default process
adjacency Events for ISIS process
2011 May 21 08:54:53.773678 isis_otv default [10371]:
L1
SITE2-OED1 over Overlay1 - UP
2011 May 21 08:54:53.773662 isis_otv default [10371]:
add adja
cency for overlay:Overlay1, addr: 10.10.17.6
2011 May 21 08:54:53.653906 isis_otv default [10371]:
adjacency
SITE2-OED1 over Overlay1 IPv4 address to 10.10.17.6
2011 May 21 08:54:53.653827 isis_otv default [10371]:
L1
SITE2-OED1 over Overlay1 - INIT (New)
2011 May 21 08:54:53.653799 isis_otv default [10371]:
fo
r L1 MT-0 for iib Overlay1
You can clear the log as below:
SITE1-OED1# clear otv isis event-history
6. Verify OTV overlay interface
Verify Overlay interface is up.
SITE1-OED1# show otv
OTV Overlay Information
UP
We want the two servers in 10.0.10.0/24 to reach each other through the
routed fabric in between. The supervisor were using has a 4 VDC limit and in
this example I will be using all 4. The smaller router icons are VRFs on the
SW1 and SW2 VDCs which you will see return in the configuration.
Im going to assume you have a working knowledge of basic NX-OS, OSPF
and OTV knowledge and have the VDCs set up, have the proper licenses,
made the proper interface allocations (mind your M and F linecards and
make sure absolutely no other connections are active and trunking, youll
have a field day looking for why it doesnt work otherwise) and can start from
there. First, some basic information:
OTV Extended VLAN: 10
OTV Site-VLAN: 99
OTV Site-IDs: 0x1 & 0x2
OTV Control: 239.1.1.1
OTV Data Range: 232.1.1.0/24
Lets begin with numbering all the interfaces and creating the OSPF network:
OTV1
feature ospf
! Define VLANs
vlan 10
name SERVERS
vlan 99
name OTV-SITE
! Enable OSPF
router ospf 1
log-adjacency-changes
! Join interface
interface Ethernet1/27
ip address 172.16.0.2/30
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
no shutdown
! Internal interface
interface Ethernet8/1
switchport mode trunk
switchport trunk allowed vlan 10,99
no shutdown
SW1
feature ospf
! Define VLANs
vlan 10
name SERVERS
vlan 99
name OTV-SITE
! Define vrf context for separating 'intra-dc' traffic from local traffic
vrf context OTV
! Used for OSPF router-id
interface loopback0
vrf member OTV
ip address 1.1.1.1/32
! OSPF redistribution for following ranges
ip prefix-list OSPF-REDIST permit 172.16.0.0/30
ip prefix-list OSPF-REDIST permit 1.1.1.1/32
route-map OSPF_REDIST permit 10
match ip address prefix-list OSPF_REDIST
! Have OSPF send default gateway to following peers:
ip prefix-list OSPF_DEF_ROUTE permit 172.16.0.0/30
route-map OSPF_DEF_ROUTE permit 10
match ip address prefix-list OSPF_DEF_ROUTE
! Enable OSPF and redistribute proper prefixes and default gateway to OTV
VDC
router ospf 1
default-information originate always route-map OSPF_DEF_ROUTE
redistribute direct route-map OSPF_REDIST
log-adjacency-changes
vrf OTV
! Link to OTV1 (Join interface)
interface Ethernet1/28
vrf member OTV
ip address 172.16.0.1/30
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
no shutdown
! Link to SW2
interface Ethernet1/37
vrf member OTV
ip address 192.168.0.1/30
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
no shutdown
! Join interface
interface Ethernet1/48
ip address 172.16.1.2/30
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
no shutdown
! Internal interface
interface Ethernet8/15
switchport mode trunk
switchport trunk allowed vlan 10,99
no shutdown
With that out of the way you should have a routed network and OTV1 should
be able to reach OTV2:
OTV1# ping 172.16.1.2
PING 172.16.1.2 (172.16.1.2): 56 data bytes
64 bytes from 172.16.1.2: icmp_seq=0 ttl=254 time=48.052 ms
64 bytes from 172.16.1.2: icmp_seq=1 ttl=254 time=4.923 ms
64 bytes from 172.16.1.2: icmp_seq=2 ttl=254 time=20.752 ms
64 bytes from 172.16.1.2: icmp_seq=3 ttl=254 time=2.935 ms
64 bytes from 172.16.1.2: icmp_seq=4 ttl=254 time=4.965 ms
--- 172.16.1.2 ping statistics --5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 2.935/16.325/48.052 ms
Now its time for the multicast and OTV configuration. Disclaimer: I am not
a multicast expert, but I know enough to get it to work. It might be very well
that there is a more efficient way of setting this up, this is just what I did to
get it working.
OTV1
feature otv
! Define local OTV identifiers
otv site-vlan 99
otv site-identifier 0x1
! Join interface
interface Ethernet1/27
ip igmp version 3
! Define OTV overlay with join interface, the extended VLAN and multicast
addresses
interface Overlay0
pim
pim
pim
pim
pim
pim
pim
pim
ip pim sparse-mode
ip igmp version 3
interface loopback0
ip pim sparse-mode
OTV2
feature otv
! Define local OTV identifiers
otv site-vlan 99
otv site-identifier 0x2
! Join interface
interface Ethernet1/48
ip igmp version 3
! Define OTV overlay with join interface, the extended VLAN and multicast
addresses
interface Overlay0
otv join-interface Ethernet1/48
otv control-group 239.1.1.1
otv data-group 232.1.1.0/24
otv extend-vlan 10
no shutdown
At this time, you should have a working OTV adjacency between OTV1 and
OTV2. Dont freak out when theres no connectivity at first, as OTV
adjacencies could take a while before they are actually forwarding. If theres
no connectivity, check the output of this command:
OTV1# sh otv vlan
Configure the site ID. It cant hurt. And its now mandatory (per TFM).
As to why, see the next item.
If you have two OTV devices at a site, make sure they can route to
each other. OTV now requires both site VLAN heartbeat and OTV-side
adjacency to operate. I prefer to have a fairly direct connection for this,
i.e. if the L3 side of the OTV device or VDC connects to your site or
WAN core, then make sure the two WAN cores are connected to each
other at L3. Routing via a site L2 core and crosslink puts a lot ofup.
(Required the last time I tested it, anyway.)
We have been setting the OTV devices up with each having a virtual
port channel to the L2 Aggregation switches, and no cross-link between
them (no real value to having one). If you cross-connect the OTV pair,
you probably want wide vPC from them to the Aggregation pair,
assuming the latter are Nexus / Nexus VDC and doing vPC.
The OTV VDC or device can use static routing. Dynamic routing has the
virtue of providing logging of adjacency loss when the link goes down,
which is usually more conspicuous. Links bouncing is normal, routing
adjacency issues tend to get noticed.
Note the OTV ARP timer should be far less than the MAC aging timer.
You want this in general on switches, to avoid / reduce unicast flooding.
Limit which VLANs cross the OTV tunnel(s). Yeah, every-VLANeverywhere in one datacenter (VLAN entropy) may eventually mean
every-VLAN-everywhere-in-every-datacenter. It strikes me as
worthwhile risk reduction to fight the battle to limit VLAN scopes as
much as possible. It may be a rear-guard action, but still is worthwhile.
YMMV.
If you run PIM on the OTV join interface, make sure it is not PIM DR:
adjust the DR priority to ensure this.