cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
357
Views
0
Helpful
1
Replies
Highlighted
Beginner

OTV between couple of CSRs 1000v and dot1q TAG rewriting

Hello,

 

I have couple of CSRs 1000v which can reach each other via IP network. 1st CSR is in datacenter LEFT and 2nd CSR is in datacenter RIGHT. Site interfaces of CSRs are dot1q trunks. A task is to extend broadcast segment between data centres using OTV feature, considering that dot1q tag in DC-LEFT is 111 and in DC-RIGHT is 11. Last circumstance requires dot1q rewriting to be done as described in command reference

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/wan/command/wan-cr-book/mace_enable_through_rtcp_regenerate.html#wp1867662720

I want to apply tag rewriting on CSR-left by doing configuration as you can see below. I see OTV-adjacency is OK and IS-IS exchanges MAC addresses between OTV-peers, but communication between end-systems doesn't work; there are no MAC<>IP mapping in arp tables of the end-hosts. At the moment I suspect that reason of the issue might be with tag rewriting.

 

I would appreciate for any advise regarding usage of rewrite ingress tag command. Am I using it correctly or missed something? Thanks in advance.

 

interface Overlay1
 no ip address
 otv join-interface GigabitEthernet1
 otv adjacency-server unicast-only
 service instance 111 ethernet
  encapsulation dot1q 11
  bridge-domain 111
 !
end

interface GigabitEthernet2
 description **OTV LAN-FACED**
 no ip address
 negotiation auto
 service instance 111 ethernet
  encapsulation dot1q 111
  rewrite ingress tag translate 1-to-1 dot1q 11 symmetric
  bridge-domain 111
 !
 service instance 999 ethernet
  encapsulation dot1q 999
  bridge-domain 999
 !
end

 

==========Configuration on the CSR-right

interface Overlay1
 no ip address
 otv join-interface GigabitEthernet1
 otv use-adjacency-server 10.67.44.22 unicast-only
 service instance 111 ethernet
  encapsulation dot1q 11
  bridge-domain 111
 !
end
interface GigabitEthernet2
 description **OTV LAN-FACED**
 no ip address
 negotiation auto
 service instance 111 ethernet
  encapsulation dot1q 11
  bridge-domain 111
 !
 service instance 999 ethernet
  encapsulation dot1q 999
  bridge-domain 999
 !
end

1 ACCEPTED SOLUTION

Accepted Solutions
Beginner

Re: OTV between couple of CSRs 1000v and dot1q TAG rewriting

Found my own 3yo post and here is the solution to that. Hopefully could be helpful for others:

 

In fact the problem was on the VNFI level - I worked it out with VMware management folks who have changed the security policy for a port on distributed virtual switch, where the site interfaces of CSRs were connected to. In particular following options were set to "accept":

 

a) Promiscuous mode;

b) MAC address changes;

c) Forged transmits.

 

Having reject policy for those options is breaking the data plane of OTV on site interface. More details what those option do can be found here:

 

https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.networking.doc/GUID-E9A41435-4081-47D9-9B34-48CABE7BF60C.html

 
 

View solution in original post

Everyone's tags (3)
1 REPLY 1
Beginner

Re: OTV between couple of CSRs 1000v and dot1q TAG rewriting

Found my own 3yo post and here is the solution to that. Hopefully could be helpful for others:

 

In fact the problem was on the VNFI level - I worked it out with VMware management folks who have changed the security policy for a port on distributed virtual switch, where the site interfaces of CSRs were connected to. In particular following options were set to "accept":

 

a) Promiscuous mode;

b) MAC address changes;

c) Forged transmits.

 

Having reject policy for those options is breaking the data plane of OTV on site interface. More details what those option do can be found here:

 

https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.networking.doc/GUID-E9A41435-4081-47D9-9B34-48CABE7BF60C.html

 
 

View solution in original post

Everyone's tags (3)