OTV Join Interface Limitations

Hi all
Can anyone confirm if it is possible to use an SVI as a join interface for OTV on NX-OS 5.2(3a)?
Thank you

Hello again,
I've been reading for last few days and here is what I found.
According to this article, using CTS + OTV should not be a problem at all (and I hope the same applies for MPLS too :-)).
However, I have yet another question with regards to OTV - is the following topology supported?
My thinking is that if we have DC1-OTV-A device authoritative for VLAN10, but at the same time having vPC peer DC1-OTV-B secondary EAD for VLAN20, neither the vPC rule will allow this VLAN over the peer link nor the OTV will be (currently) able to send it across the overlay as it is not authoritative for this vlan. Ive been reading alot and everything I managed to find is >> this <<
"The vPC peer-link is leveraged in the initial release to steer the traffic to the AED device. In future releases where the edge device does not play the AED role, a given VLAN will be allowed to forward unicast traffic to the remote sites via the OTV overlay, providing a desired per-flow load-balancing behavior."
This is a bit vague. Is that mean that the vPC check rule will basically allow the traffic to traverse via peer-link if an OTV feature is being used? I couldn't find anything else so any thoughts will be much appreciated!
Thanks!
P.s. I know that I can make it the other way around - e.g. CORE-A/B being vPC members and OTV L2 links being configured as standard Port-channels, but in my case I don't have separate VDC for OTV and need to have both - vPC and OTV running in same VDC. Which leads to another question - is it still a limitation that SVI interfaces are not allowed in VDC where OTV is used or this applies for extended VLANs only? (Because I read different documentation, stating both :|)

Similar Messages

OTV Internal Interface Configuration

Hi
I am trying to implement OTV between 2 sites. I am slightly confused about the config for the join interface and site VLAN. Attached is the basic setup on one of the sites, I am using ASR 1002X routers to perform the OTV functions.
There seem to be limited sources for the ASR OTV configs, but on source states the internal interface on the ASR router should be configured as follows for each vlan
no ip address
service instance 10 ethernet
  encapsulation dot1q 10
  bridge-domain 10
service instance 20 ethernet
  encapsulation dot1q 20
  bridge-domain 20
service instance 30 ethernet
  encapsulation dot1q 30
  bridge-domain 30
I guess on the internal switch it will just be a trunk port allowing the above VLANs?
Thanks

Thanks Minh,
So it is possible to have switchports configured as routed, fabricpath and trunk/access in a fabricpath configuration? Do i need to add any spanning-tree pseudo or priority configuration?
Sample configs:
#ASR
interface GigabitEthernet0/0/1
no ip address
service instance 1 ethernet
  encapsulation dot1q 1
  bridge-domain 1
service instance 2 ethernet
  encapsulation dot1q 2
  bridge-domain 2
service instance 3 ethernet
  encapsulation dot1q 3
  bridge-domain 3
#Nexus 56xx
interface e1/5
switchport mode trunk
switchport trunk allow vlan 1,2,3

Cisco ASR - How to connect an OTV internal interface to a FabricPath domain

Scenario - migrate servers while maintaining their existing IP address from data centre 1 to data centre 2 with minimal downtime. Diagram attached.
I'm planning on using a Cisco ASR1001-X with AES license at DC1 and DC2 and configuring the routers with OTV to extend 10 x VLANs between the data centres. The join interface would connect directly to the WAN circuit NTU and the Internal Interface would connect to the switch and be configured as a service instance with 10 VLANs tagged using dot1q. The problem is that DC1 switch infrastructure is using Cisco Nexus 56xx configured with FabricPath. I can't find any information that suggests that i can patch the Cisco ASR router's internal interface directly into a FabricPath switchport or what the configuration would be.
Older OTV documentation refers to Nexus 7000 and OTV stating the following: "Because OTV encapsulation is done on M-series modules, OTV cannot read FabricPath packets. Because of this restriction, terminating FabricPath and reverting to Classical Ethernet where the OTV VDC resides is necessary."
Is this true for the Cisco ASR also? The only workaround i can think of is to install a cheap catalyst switch connected to the FabricPath domain and re-introduce spanning-tree at the edge but this seems backwards to me. Any help or suggestions appreciated? Thanks

Thanks Minh,
So it is possible to have switchports configured as routed, fabricpath and trunk/access in a fabricpath configuration? Do i need to add any spanning-tree pseudo or priority configuration?
Sample configs:
#ASR
interface GigabitEthernet0/0/1
no ip address
service instance 1 ethernet
  encapsulation dot1q 1
  bridge-domain 1
service instance 2 ethernet
  encapsulation dot1q 2
  bridge-domain 2
service instance 3 ethernet
  encapsulation dot1q 3
  bridge-domain 3
#Nexus 56xx
interface e1/5
switchport mode trunk
switchport trunk allow vlan 1,2,3

OTV Overlay interface MTU

Hi All,
when I checked the overlay interface it shows 1400 as the MTU.
OTV-1# sh int overlay 1
Overlay1 is up
    MTU 1400 bytes, BW 1000000 Kbit
     Encapsulation OTV
     Last link flapped 19:02:22
     Last clearing of "show interface" counters never
     Load-Interval is 5 minute (300 seconds)
     RX
       6045068 unicast packets 0 multicast packets
       0 bytes 0 bits/sec 72 packets/sec
     TX
       0 unicast packets 0 multicast packets
       0 bytes 0 bits/sec 0 packets/sec
OTV-1#
Above is the working OTV device output. Does this means that we can transport only packets of MTU 1400 through OTV ? is this MTU considers only the payload or with headers ? if with headers upto which header it calculates ?
I checked on the configuration and couldn’t find any place where I can change this value, therefore I need to know, on what basis this 1400 is coming the OTV interface.
I tried by changing the isis lsp-mtu under otv isis but it did not make any change in the overlay interface MTU.
Rgds
Harin

Above is the working OTV device output. Does this means that we can transport only packets of MTU 1400 through OTV ? is this MTU considers only the payload or with headers ? if with headers upto which header it calculates ?
No it doesn't mean the device is only able to transport 1400 bytes packet. This value is the MTU of ISIS control packet. You can try a very simple test if you can affort an outage:
- change the OTV joint interface's MTU to 1000
- shut, no shut the overlay interface
- at this point, OTV will not come up. You can verify it by using show otv isis adj
- once you change to joint interface's MTU back to 1500, OTV will come up
How big of the MTU can OTV transport? It is depends on the path MTU size.
HTH,
jerry

FabricPath as OTV internal interface?

As of NX-OS 6.2(6), F3 modules are supported in the Nexus 7700 series switches, and support all protocols including FabricPath and OTV.
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/6_x/nx-os/release/notes/62_nx-os_release_note.html#pgfId-647330
My question is, does this mean we can now use FabricPath ports as the OTV internal interface facing our aggregation switch, or do they still need to be in CE mode?

Thanks Minh,
So it is possible to have switchports configured as routed, fabricpath and trunk/access in a fabricpath configuration? Do i need to add any spanning-tree pseudo or priority configuration?
Sample configs:
#ASR
interface GigabitEthernet0/0/1
no ip address
service instance 1 ethernet
  encapsulation dot1q 1
  bridge-domain 1
service instance 2 ethernet
  encapsulation dot1q 2
  bridge-domain 2
service instance 3 ethernet
  encapsulation dot1q 3
  bridge-domain 3
#Nexus 56xx
interface e1/5
switchport mode trunk
switchport trunk allow vlan 1,2,3

OTV MAC address limitation

Has anyone heard of any MAC address limitations with OTV on the Nexus 7000s? I heard from a guy yesterday that they did an OTV POC and ran into issues when the MAC address count got above 500.

Jeremy,
There a current limit of 12K MAC Addresses across all the extended VLANs in all configured overlays.
http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/otv/configuration/guide/Cisco_Nexus_7000_Series_NX-OS_OTV_Configuration_Guide__Release_5.x_appendix1.html
Regards,
Robert

WISM : vlans and interface limitation

We have a WISM within our 6509. On the 2 different controllers within the WISM, we have 2 different VLAN's that are attached to 2 different interfaces, can we have each interface attach to the same VLAN?

Yes.

MPLS + OTV + MACSec/802.1AE

Hello,
I have some quick quiets ion with regards to DCI links. If I have L2 between two data centres and want to use MPLS + OTV + MACSec - will that work? I remember there was some limitations where OTV join interface cannot be SVI but must be physical instead (or l3 port-channel). In which case I am not sure will the 802.1ae work as well as the MPLS (needed for layer 3 VPNs across both DCs)
Many thanks in advance!

Hello again,
I've been reading for last few days and here is what I found.
According to this article, using CTS + OTV should not be a problem at all (and I hope the same applies for MPLS too :-)).
However, I have yet another question with regards to OTV - is the following topology supported?
My thinking is that if we have DC1-OTV-A device authoritative for VLAN10, but at the same time having vPC peer DC1-OTV-B secondary EAD for VLAN20, neither the vPC rule will allow this VLAN over the peer link nor the OTV will be (currently) able to send it across the overlay as it is not authoritative for this vlan. Ive been reading alot and everything I managed to find is >> this <<
"The vPC peer-link is leveraged in the initial release to steer the traffic to the AED device. In future releases where the edge device does not play the AED role, a given VLAN will be allowed to forward unicast traffic to the remote sites via the OTV overlay, providing a desired per-flow load-balancing behavior."
This is a bit vague. Is that mean that the vPC check rule will basically allow the traffic to traverse via peer-link if an OTV feature is being used? I couldn't find anything else so any thoughts will be much appreciated!
Thanks!
P.s. I know that I can make it the other way around - e.g. CORE-A/B being vPC members and OTV L2 links being configured as standard Port-channels, but in my case I don't have separate VDC for OTV and need to have both - vPC and OTV running in same VDC. Which leads to another question - is it still a limitation that SVI interfaces are not allowed in VDC where OTV is used or this applies for extended VLANs only? (Because I read different documentation, stating both :|)

Cisco OTV Vlan Not Forward Capable

Hi All,
I am trying to setup OTV between two routers.
Using show otv adjacency I can see the other router with stat UP, But the VLAN I want to extend has NFC as its current state.
# show otv vlan
OTV Extended VLANs and Edge Device State Information (* - AED)
Legend:
(NA) - Non AED, (VD) - Vlan Disabled, (OD) - Overlay Down
(DH) - Delete Holddown, (HW) - HW: State Down
(NFC) - Not Forward Capable
VLAN Auth. Edge Device Vlan State Overlay
1200 inactive(NFC) Overlay1
I cannot find any documentation on this state and what it can be caused by.
Does someone know what can cause this state? What can I do to troubleshoot this?
This is my current config:
feature otv
otv site-vlan 1508
interface Overlay1
otv join-interface port-channel2
otv control-group 239.1.1.1
otv data-group 232.1.1.0/28
otv extend-vlan 1200
no shutdown
otv site-identifier 0x1508
Any help would be appreciated :)

Hello Tim
Brayton Hackworth had a similar post as yours, found here;
https://supportforums.cisco.com/message/3684179#3684179
Brayton is using the Mitel 5330 phones where the LLDP no longer fed VLAN information to the phone network. But, he reverted to use a DHCP server to provide the VLAN information.
Unfortunately, I (personally) cannot test any Mitel resources (since I don't have them) so my labs usually only consist of either 7900 series or SPA500/900 series phones.
The best thing I can really recommend to you is to make a package of data consisting of;
Topology which consists of;
Modem type
Router including IP
All devices including IP of switches
Servers / relevant workstations
# of attached devices and # of users on the LAN
Switch config file + show tech on a notepad
Syslog output from the switch
Working PCAP
PCAP showing failure
PCAP legend showing what IP address are who (unless topology contains all IP)
Where the PCAP is taken from and method
We then can create a service request for you and pass it for review.
-Tom

ISSU to NX-OS 6.2(2) fails. OTV error

Just tried upgrading 2 of the 4 chassis' I have and it went horribly wrong. Well not really, it just failed with almost no packet drops.
This is a OTV setup across two sites. I did a ISSU upgrade on 2 chassis simultanuously (1 in each site) and got exactly the same error on both.
2013 Aug 23 20:45:28 glsdswn7k001 %$ VDC-1 %$ %PLATFORM-2-MOD_REMOVE: Module 6 removed (Serial number JAFXXXX)
2013 Aug 23 20:45:28 glsdswcore001 %$ VDC-2 %$ last message repeated 1 time
2013 Aug 23 20:45:28 glsdswotv001 %$ VDC-3 %$ last message repeated 1 time
2013 Aug 23 20:49:23 glsdswn7k001 %$ VDC-1 %$ %SYSMGR-STANDBY-2-CONVERT_FUNC_FAILED: Conversion function failed for service "otv" (error-id 0xFFFFFFFF).
2013 Aug 23 20:49:54 glsdswn7k001 %$ VDC-1 %$ %SYSMGR-STANDBY-2-CONVERT_FUNC_FAILED: Conversion function failed for service "otv" (error-id 0xFFFFFFFF).
2013 Aug 23 20:50:25 glsdswn7k001 %$ VDC-1 %$ %SYSMGR-STANDBY-2-CONVERT_FUNC_FAILED: Conversion function failed for service "otv" (error-id 0xFFFFFFFF).
2013 Aug 23 20:50:56 glsdswn7k001 %$ VDC-1 %$ %SYSMGR-STANDBY-2-CONVERT_FUNC_FAILED: Conversion function failed for service "otv" (error-id 0xFFFFFFFF).
2013 Aug 23 20:51:27 glsdswn7k001 %$ VDC-1 %$ %SYSMGR-STANDBY-2-CONVERT_FUNC_FAILED: Conversion function failed for service "otv" (error-id 0xFFFFFFFF).
2013 Aug 23 20:51:58 glsdswn7k001 %$ VDC-1 %$ %SYSMGR-STANDBY-2-CONVERT_FUNC_FAILED: Conversion function failed for service "otv" (error-id 0xFFFFFFFF).
2013 Aug 23 20:52:29 glsdswn7k001 %$ VDC-1 %$ %SYSMGR-STANDBY-2-CONVERT_FUNC_FAILED: Conversion function failed for service "otv" (error-id 0xFFFFFFFF).
2013 Aug 23 20:53:00 glsdswn7k001 %$ VDC-1 %$ %SYSMGR-STANDBY-2-CONVERT_FUNC_FAILED: Conversion function failed for service "otv" (error-id 0xFFFFFFFF).
Resetting boot variables. Please wait.
2013 Aug 23 20:53:32 glsdswn7k001 %$ VDC-1 %$ %SYSMGR-STANDBY-2-CONVERT_FUNC_FAILED: Conversion function failed for service "otv" (error-id 0xFFFFFFFF).
[####################] 100%
2013 Aug 23 20:53:47 glsdswn7k001 %$ VDC-1 %$ %PLATFORM-2-MOD_REMOVE: Module 6 removed (Serial number JAFXXXX)
2013 Aug 23 20:53:47 glsdswcore001 %$ VDC-2 %$ last message repeated 1 time
2013 Aug 23 20:53:47 glsdswotv001 %$ VDC-3 %$ last message repeated 1 time
Failure recovery action::
"Standby will be rebooted to force netboot and image download".
Install has failed. Return code 0x4093001E (Standby failed to come online).
Please identify the cause of the failure, and try 'install all' again.
The logs show the following:
2013 Aug 23 20:47:10 glpdswn7k002 %PLATFORM-2-MOD_REMOVE: Module 6 removed (Serial number JAFXXXX)
2013 Aug 23 20:49:21 glpdswn7k002 %BOOTVAR-5-NEIGHBOR_UPDATE_AUTOCOPY: auto-copy supported by neighbor supervisor, starting...
2013 Aug 23 20:50:56 glpdswn7k002 %SYSMGR-STANDBY-2-CONVERT_FUNC_FAILED: Conversion function failed for service "otv" (error-id
0xFFFFFFFF).
2013 Aug 23 20:50:56 glpdswn7k002 %SYSMGR-STANDBY-3-SERVICE_TERMINATED: Service "otv" (PID 8979) has finished with error code SY
SMGR_EXITCODE_SYSERR (1).
2013 Aug 23 20:51:27 glpdswn7k002 %SYSMGR-STANDBY-2-CONVERT_FUNC_FAILED: Conversion function failed for service "otv" (error-id
0xFFFFFFFF).
2013 Aug 23 20:51:27 glpdswn7k002 %SYSMGR-STANDBY-3-SERVICE_TERMINATED: Service "otv" (PID 9132) has finished with error code SY
SMGR_EXITCODE_SYSERR (1).
2013 Aug 23 20:51:58 glpdswn7k002 %SYSMGR-STANDBY-2-CONVERT_FUNC_FAILED: Conversion function failed for service "otv" (error-id
0xFFFFFFFF).
2013 Aug 23 20:51:58 glpdswn7k002 %SYSMGR-STANDBY-3-SERVICE_TERMINATED: Service "otv" (PID 9349) has finished with error code SY
SMGR_EXITCODE_SYSERR (1).
2013 Aug 23 20:52:29 glpdswn7k002 %SYSMGR-STANDBY-2-CONVERT_FUNC_FAILED: Conversion function failed for service "otv" (error-id
0xFFFFFFFF).
2013 Aug 23 20:52:29 glpdswn7k002 %SYSMGR-STANDBY-3-SERVICE_TERMINATED: Service "otv" (PID 9384) has finished with error code SY
SMGR_EXITCODE_SYSERR (1).
2013 Aug 23 20:53:00 glpdswn7k002 %SYSMGR-STANDBY-2-CONVERT_FUNC_FAILED: Conversion function failed for service "otv" (error-id
0xFFFFFFFF).
2013 Aug 23 20:53:00 glpdswn7k002 %SYSMGR-STANDBY-3-SERVICE_TERMINATED: Service "otv" (PID 9402) has finished with error code SY
SMGR_EXITCODE_SYSERR (1).
2013 Aug 23 20:53:31 glpdswn7k002 %SYSMGR-STANDBY-2-CONVERT_FUNC_FAILED: Conversion function failed for service "otv" (error-id
0xFFFFFFFF).
2013 Aug 23 20:53:31 glpdswn7k002 %SYSMGR-STANDBY-3-SERVICE_TERMINATED: Service "otv" (PID 9435) has finished with error code SY
SMGR_EXITCODE_SYSERR (1).
2013 Aug 23 20:54:02 glpdswn7k002 %SYSMGR-STANDBY-2-CONVERT_FUNC_FAILED: Conversion function failed for service "otv" (error-id
0xFFFFFFFF).
2013 Aug 23 20:54:02 glpdswn7k002 %SYSMGR-STANDBY-3-SERVICE_TERMINATED: Service "otv" (PID 9623) has finished with error code SY
SMGR_EXITCODE_SYSERR (1).
2013 Aug 23 20:54:33 glpdswn7k002 %SYSMGR-STANDBY-2-CONVERT_FUNC_FAILED: Conversion function failed for service "otv" (error-id
0xFFFFFFFF).
2013 Aug 23 20:54:33 glpdswn7k002 %SYSMGR-STANDBY-3-SERVICE_TERMINATED: Service "otv" (PID 9769) has finished with error code SY
SMGR_EXITCODE_SYSERR (1).
2013 Aug 23 20:55:00 glpdswn7k002 %SYSMGR-3-SERVICE_TERMINATED: Service "installer" (PID 26230) has finished with error code SYS
MGR_EXITCODE_FAILURE_NOCALLHOME (20).
2013 Aug 23 20:55:02 glpdswn7k002 %PLATFORM-2-MOD_REMOVE: Module 6 removed (Serial number JAFXXXX)
2013 Aug 23 20:57:21 glpdswn7k002 %BOOTVAR-5-NEIGHBOR_UPDATE_AUTOCOPY: auto-copy supported by neighbor supervisor, starting...
2013 Aug 23 20:59:03 glpdswn7k002 %MODULE-5-STANDBY_SUP_OK: Supervisor 6 is standby
Any idea anyone?

Thought I'd dump the config of the OTV VDC here as well...
version 6.1(4)
hostname lpdswotv002
feature tacacs+
cfs eth distribute
feature ospf
feature otv
feature udld
feature interface-vlan
feature hsrp
feature lacp
feature dhcp
feature bfd
username admin password 5 kk role vdc-admin
ip domain-lookup
ip access-list ALL_IPs
10 permit ip any any
mac access-list ALL_MACs
10 permit any any
ip access-list HSRP_IP
10 permit udp any 224.0.0.2/32 eq 1985
20 permit udp any 224.0.0.102/32 eq 1985
mac access-list HSRP_VMAC
10 permit 0000.0c07.ac00 0000.0000.00ff any
20 permit 0000.0c9f.f000 0000.0000.0fff any
arp access-list HSRP_VMAC_ARP
10 deny ip any mac 0000.0c07.ac00 ffff.ffff.ff00
20 deny ip any mac 0000.0c9f.f000 ffff.ffff.f000
30 permit ip any mac any
vlan access-map HSRP_Localization 10
        match mac address HSRP_VMAC
        match ip address HSRP_IP
        action drop
vlan access-map HSRP_Localization 20
        match mac address ALL_MACs
        match ip address ALL_IPs
        action forward
vlan filter HSRP_Localization vlan-list 1500-1509,1600-1620
snmp-server user admin vdc-admin auth md5 0x4789e0334323ad58a117a4a94b priv 0x478934334338a117a4a94b localizedkey
rmon event 1 log trap public description FATAL(1) owner PMON@FATAL
rmon event 2 log trap public description CRITICAL(2) owner PMON@CRITICAL
rmon event 3 log trap public description ERROR(3) owner PMON@ERROR
rmon event 4 log trap public description WARNING(4) owner PMON@WARNING
rmon event 5 log trap public description INFORMATION(5) owner PMON@INFO
ip routing event-history general size medium
ip route 0.0.0.0/0 10.236.0.13
vrf context management
ip route 0.0.0.0/0 10.236.16.1
vlan 1,14,1500-1509,1600-1620
vlan 14
name DC1_OTV_Site_VLAN
otv site-vlan 14
service dhcp
ip dhcp relay
interface Vlan1
interface port-channel6
description OTV Internal Interface
switchport
switchport mode trunk
switchport trunk allowed vlan 14,1500-1699
interface Overlay1
otv join-interface Ethernet7/1
otv extend-vlan 1500-1699
otv use-adjacency-server 10.236.0.1 10.237.0.10 unicast-only
no shutdown
interface Ethernet7/1
description OTV Join Interface
rate-mode dedicated force
mtu 9216
no ip redirects
ip address 10.236.0.14/30
no ipv6 redirects
ip ospf network point-to-point
no ip ospf passive-interface
ip router ospf 1 area 0.0.0.0
ip ospf bfd
no shutdown
interface Ethernet7/2
rate-mode dedicated force
switchport
switchport mode trunk
switchport trunk allowed vlan 14,1500-1699
channel-group 6 mode active
no shutdown
interface Ethernet7/3
interface Ethernet7/4
interface Ethernet7/5
interface Ethernet7/6
interface Ethernet7/7
interface Ethernet7/8
interface Ethernet7/9
rate-mode dedicated force
switchport
switchport mode trunk
switchport trunk allowed vlan 14,1500-1699
channel-group 6 mode active
no shutdown
interface Ethernet7/10
interface Ethernet7/11
interface Ethernet7/12
interface Ethernet7/13
interface Ethernet7/14
interface Ethernet7/15
interface Ethernet7/16
interface Ethernet7/17
interface Ethernet7/18
interface Ethernet7/19
interface Ethernet7/20
interface Ethernet7/21
interface Ethernet7/22
interface Ethernet7/23
interface Ethernet7/24
interface Ethernet7/25
interface Ethernet7/26
interface Ethernet7/27
interface Ethernet7/28
interface Ethernet7/29
interface Ethernet7/30
interface Ethernet7/31
interface Ethernet7/32
interface mgmt0
ip address 10.236.16.23/24
cli alias name wr copy run start
line console
terminal width 128
line vty
router ospf 1
router-id 10.236.16.23
log-adjacency-changes
passive-interface default
otv site-identifier 0x10
ip arp inspection filter HSRP_VMAC_ARP vlan 1500-1699

OTV with multiple VRFs

Hi,
we want to deploy OTV in order to interconnect 2 active/active DCs , but we have multiple VRFs classifying the different SVIs (VLANs). We have 2 Nexus 7706 in each DC.
We would like to know if this would be supported.
Example
VRF A --> Has SVI Vlan1,2
VRF B --> Has SVI Vlan3,4
Join interface that is Po100 to be virtualized into multiple logical sub-interfaces as many VRFs as we have, so:
int Po100.1
vrf member A
int Po100.2
vrf member B
and then configure 2 overlay interfaces in the same switch.
interface overlay 1
otv join-interface po100.1
otv extend-vlan 1-2 --> SVI in VRF A
interface overlay 2
otv join-interface po100.2
otv extend-vlan 3-4 --> SVI in VRF B
Traffic is always segregated and VRFs configuration is maintain. Note that the configuration is only showing the VRF part and it is not complete it.
Is this setup supported? in order to support VRFs we should do it differently? Here we are only showing one switch configuration and we would like to know if we would be able to load balance as we have 2 Nexus per DC.
Thanks a lot.
Regards,
J

Hmm,
I think you're over complicating it. OTV maintains separation at the layer 2 level. Just extend vlans 1-4 over the otv tunnel and apply the VRF's to the SVI's (layer 3) on the other side and you're done. Unless there's more than two datacenters in the mix I'm not sure why you would want to maintain two separate overlays.
~jerry

Configuring OTV adjacency server

Hi, Scenario is as follows: Data Center 1 - N7K-1, N7K-2. Data Center 2 - N7K-3, N7K-4. N7K-1 is the primary adjacency server N7K-3 is the secondary adjacency server Can't seem to find any sample config showing redundant OTV adjacency server configuration. Can anyone confirm if the attached config is correct in the Overlay interface ? Especially on N7K-3 (the secondary adjacency server) THanks Eng Wee

Your config looks like mine. This is how I have mine setup in my lab and it seems to work well. If its wrong then I'd like to know too
Overlay 1 is the overlay I use in my lab for this:
#Primary Adj Server#
version 5.2(1)
feature otv
otv site-vlan 951
interface Overlay0
description MCAST OTV
otv join-interface Ethernet1/13
otv control-group 239.1.1.1
otv data-group 239.1.2.0/28
otv extend-vlan 850-854
no shutdown
interface Overlay1
otv join-interface Ethernet1/13
otv extend-vlan 855
otv use-adjacency-server 192.168.1.17 192.168.1.21 unicast-only
otv adjacency-server unicast-only
no shutdown
otv-isis default
vpn Overlay0
    redistribute filter route-map OTV_HSRP_filter
vpn Overlay1
    redistribute filter route-map OTV_HSRP_filter
otv site-identifier 0x1
#Secondary Adj Server#
version 5.2(1)
feature otv
otv site-vlan 951
interface Overlay0
otv join-interface Ethernet1/13
otv control-group 239.1.1.1
otv data-group 239.1.2.0/28
otv extend-vlan 850-854
no shutdown
interface Overlay1
otv join-interface Ethernet1/13
otv extend-vlan 855
otv use-adjacency-server 192.168.1.17 192.168.1.21 unicast-only
otv adjacency-server unicast-only
no shutdown
otv-isis default
vpn Overlay0
    redistribute filter route-map OTV_HSRP_filter
vpn Overlay1
    redistribute filter route-map OTV_HSRP_filter
otv site-identifier 0x1

OTV site vlan with multiple overlay interface

Hi,
I have an OTV multihoming sites. 2 sites. 2 otv edge device each site.
and with multiple overlay interface sharing 1 joint interface
otv edge device connected to multiple VDC.
each internal / downlink will forward different vlan for each vdc.
================================
example
int overlay 1
otv extends-vlan 10
int overlay 2
otv extends vlan 20
int eth 2/1
description trunk to VDC1
switchport trunk allowed vlan 10,100
int eth 2/2
description trunk to VDC2
switchport trunk allowed vlan 20,100
otv site-vlan 100
================================
i understand that i can only use 1 site vlan.
so in order for the failover to happen, both eth 2/1 and eth2/2 must fail?
what if only int eth2/1 fail? will the int overlay 1 failover to secondary otv device?
thanks,
ivan

"So when querying the adjacency server the ED then knows which other ED is within the same site?"
Yes for the first part of the question, using the site Vlan unique to each site.
Why do you need a routed link between ED's at local site? You dont need to connect those back-back over L3. Moreover if you want to use it for L3 ADJ over peer-link, you need to make sure that VLAN that you are using is not allowed on the VPC member ports, just on the peer-link, else VPC loop alrorithm will break your traffic.
Are you planning to use multicast or a Unicast deployment? I remember I tried testing the topology in a POC for one of my customer, things did not work as expected in multicast deployment mode and worked fine in Unicast Adjacency server mode. I need to go back and check my notes on this.
I would rather have the join-interface go back to a routed core at site rather than back-back connecivity as it opens up the tested Multicast deployment mode.
Cheers,
-amit singh

OTV Connecting M1 ports to F2 ports

HI Guyz,
I am Designing a OTV Topology, where i have M1 series card (N7K-M108X2-12L) in OTV VDC & F2 Series card (N7K-F248XP-25E) in Aggregation VDC.
I need to connect M1 interface as its OTV INTERNAL interface to F2 interface in Aggregation VDC to learns local mac-addr.
i will dual hommed M1 interfaces from OTV VDC to 2 different 7K aggregation VDC using VPC.
as shown in fig Link-3 & 4 will be vpc member ports for 7K-A , 7K-B.
Are there any Limitations for connecting M1 interface direcltly to F2 interface , as shown above OTV VDC M1 port connects to Aggn VDC F2 port.???
thanks,
Mazhar

The only requirement to deploy OTV is the join interface must be in the M-module or F3 module (not avaliable for Nexus 7000 platform yet, only Nexus 7700).
The OTV internal interface, can be a M1 or even F-card in the lastest release.
About mix F2e with M1 modules, when you do that, the F2e routing capability is disabled, so all routing decision will be proxied to the M-module. This routing capacity is limited by the quatity of ports M that you have in your VDC.
http://www.cisco.com/en/US/docs/switches/datacenter/sw/nx-os/virtual_device_context/configuration/guide/vdc_mgmt.html#wp1263392

Using M1 and F1 ports in OTV set up

I am building a typical OTV architecture (on a stick, not inline) on Nexus 7000s; the join and internal interfaces in my OTV VDC are using M1 card ports. Can the other end of those links -- i.e. the interfaces in my Agg VDC -- use ports on my F1 card? Or do both ends of the internal and join links (all 4 ports) need to be on my M1 card? Asking because my M1 card is full at present.

Hi,
What is your nexus version ?? , below version 6.0 don't support on F1 module . 6.2 version supports on F1 module .
Version 6.2
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/6_x/nx-os/release/notes/62_nx-os_release_note.html#31296
OTV
The following Overlay Transport Virtualization (OTV) features are available in Release 6.2(2):
The VLAN translation feature allows you to connect applications that reside in separate Layer 2 domains between data centers.
Selective unknown Unicast flooding is a per MAC address configuration that allows OTV to flood across the DCI for the specified MAC address. This feature is particularly helpful for applications that go silent and timeout from the ARP tables.
Dedicated broadcast group allows you to configure a separate multicast address for broadcast traffic. This feature is useful for organizations that need separate QoS policies for broadcast traffic.
OTV has built-in BFD support that does not require any additional configuration on the OTV side, which helps with any reconvergence that OTV might have to handle.
The scale of OTV and how fast it converges are improved in this release.
F1 Series and F2e Series modules can be used as internal interfaces with the OTV VDC.
Version 6.0
Q. What modules of the Cisco Nexus 7000 Series will support OTV?
A. OTV is supported on all M-series modules. OTV is not supported on F1-series modules. Deployments using F1 series can leverage VDC separation to achieve the desired combination of line cards and functionality.
http://www.cisco.com/c/en/us/products/collateral/switches/nexus-7000-series-switches/qa_c67-574969.html
OTV Hardware Support and Licensing Information
The only Cisco platform supporting OTV functionality at this time is the Nexus 7000. Figure 1-37 shows all existing M1 linecards OTV fully supports.
Figure 1-37 M1 Linecards Supporting OTV
Full support essentially means that both Join and internal interfaces can be configured on one of the M1 modules mentioned. OTV on F1 modules is not supported on NX-OS releases shipping at the time of writing of this document (5.2 and 6.0 releases) and will be introduced in a future software release but restricted only to internal interfaces (an M1 linecard will always be required on the OTV edge device to source the OTV encapsulated traffic out of the Join interface).
http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Data_Center/DCI/whitepaper/DCI3_OTV_Intro/DCI_1.html#wp1186106
HTH
Sandy.

OTV Join Interface Limitations

Similar Messages

Maybe you are looking for