[c-nsp] OTV between couple of CSRs 1000v and dot1q TAG rewriting

[Andrei Kozlov]

Hello everybody!

Thanks to all who replied here. Aaron, as you said, rewriting stanza is
correct; the issue was related to VMware dvSwitch configuration.
With default security settings of the port-group where site interface of
CSR is connected to, virtual switch will drop inbound and outbound frames
with (respectively) destination and source MAC address that differs from
one in .vmx configuration file of the CSR VM.

Problem has gone after VMware folks changed "MAC address changes" and "Forged
transmits" settings of port-group to "Accept". Details about those
parameters described there:
*http://pubs.vmware.com/vsphere-55/index.jsp?topic=%2Fcom.vmware.vsphere.networking.doc%2FGUID-809743E1-F366-4454-9BA5-9C3FD8C56D32.html
<http://pubs.vmware.com/vsphere-55/index.jsp?topic=%2Fcom.vmware.vsphere.networking.doc%2FGUID-809743E1-F366-4454-9BA5-9C3FD8C56D32.html>*

On Mon, Aug 31, 2015 at 7:14 PM, Aaron Shultz <aarongshultz at gmail.com>
wrote:

> Hi Andrei,
>
> Your vlan tag rewrite configuration is correct. I would look for the
> problem elsewhere, though I would recommend getting working L2 connectivity
> on either side with equivalent tags before adding re-write into the mix.
> You can use*show otv vlan* to verify each overlay interface is carrying
> the intended traffic.
>
> Since you're running in a virtual environment, also make sure any virtual
> switching involved is set to work in promiscuous mac mode (vmware vswitch
> etc..).
>
> Aaron
>
> On Mon, Aug 31, 2015 at 12:53 PM, Andrei Kozlov <ak at gaaga.org> wrote:
>
>> Hello everyone.
>>
>> 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.
>>
>> ==========Configuration on the CSR-left
>>
>> 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
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>
>