Multicast Traffic over an Encrypted OTV Unicast Transport on the CSR

I set out trying to create a way to funnel multicast traffic from various back end networks to a remote facility without creating a bunch of very special new interfaces at the remote facility.  OTV seems like the perfect technology for this because of they have addressed alot of the problems that normally come with layer 2 overlays.  My remote facility might not have multicast available so that meant I needed the OTV unicast transport option.  This is also sensitive data so I needed to encrypt the traffic and I might not have jumbo frames available so that meant the only platform that could encrypt and fragment OTV left to me was the ASR or CSR routers.  I started with the CSR(virtual)  since all of my ASR (physical) were busy.

There is a lot of documentation about how to perform OTV on the Nexus 7000, but much less on the ASR/CSR line.

It was fairly easy to get unicast up and running, I started with this blog which is very well written but contains one mistake from what I can tell I’ll get to that later.

http://www.layerzero.nl/blog/2013/05/otv-and-lisp-on-the-csr-1000v/

otv_blog_1

 

So my test started with the above configuration which consisted of two eSXi 5.5 hosts connected by an Ethernet link crudely simulating the WAN.

 

HOME Router:

otv site bridge-domain 1

!

otv fragmentation join-interface GigabitEthernet1

otv site-identifier 0000.0000.0001

license boot level premium

interface Overlay1

no ip address

otv join-interface GigabitEthernet1

otv use-adjacency-server 10.10.10.78  unicast-only

service instance 1 ethernet

encapsulation dot1q 633

bridge-domain 633

interface GigabitEthernet1

ip address 10.10.10.79 255.255.255.128

negotiation auto

!

interface GigabitEthernet2

description inside

no ip address

service instance 1 ethernet

encapsulation untagged

rewrite ingress tag push dot1q 633 symmetric

bridge-domain 633

REMOTE Router:

otv site bridge-domain 1

!

otv fragmentation join-interface GigabitEthernet1

otv site-identifier 0000.0000.0002

license boot level premium

interface Overlay 1

 no ip address

otv join-interface GigabitEthernet1

 otv use-adjacency-server 10.10.10.78 unicast-only

 otv adjacency-server unicast-only

 service instance 1 ethernet

  encapsulation dot1q 633

  bridge-domain 633

interface GigabitEthernet1

ip address 10.10.10.78 255.255.255.128

negotiation auto

interface GigabitEthernet2

 description inside

 no ip address

 negotiation auto

 service instance 1 ethernet

  encapsulation untagged

  rewrite ingress tag push dot1q 633 symmetric

  bridge-domain 633

 service instance 2 ethernet

  encapsulation dot1q 2

  bridge-domain 1

 
 
REMOTE-1#  sh otv ro
Codes: BD – Bridge-Domain, AD – Admin-Distance,
       SI – Service Instance, * – Backup Route
OTV Unicast MAC Routing Table for Overlay1
 Inst VLAN BD     MAC Address    AD    Owner  Next Hops(s)
———————————————————-
 0    633  633    000c.293b.9dd6 40    BD Eng Gi2:SI1
 0    633  633    0050.56b1.cf06 50    ISIS   HOME-1
2 unicast routes displayed in Overlay1
 ———————————————————-
2 Total Unicast Routes Displayed
 

 

Once unicast worked, I proceeded to multicast but could not get multicast traffic to work.

I could see the multicast traffic locally at the sites, but the *,G from the remote site was never showing up as you can see below.

HOME#sh otv mro
 OTV Multicast Routing Table for Overlay1
 Bridge-Domain = 633, s = *, g = *
 Outgoing interface list:
 Default, NoRedist
 Incoming interface count = 0, Outgoing interface count = 1
 Bridge-Domain = 633, s = 10.10.100.2, g = 225.1.1.3
 Incoming interface list:
 Service Instance 1, GigabitEthernet2, 0050.56b1.cf06
 Incoming interface count = 1, Outgoing interface count = 0
 2 multicast routes displayed in Overlay1
 ---------------------------------------------------------
 2 Total Multicast Routes Displayed

 

Well I’ll skip to the good part, here is the magic command

ip igmp snooping querier

It must be on both routers.

I cannot understand why this command is so well hidden, in all of the documentation I could find it is nowhere to be found.  I opened a TAC case and the Cisco engineer could not find the answer even with his internal access.

I dont see it here?

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/wan_otv/configuration/xe-3s/wan-otv-xe-3s-book/wan-otv-adj-server.html#reference_EDD49D9567A440F5B191ACE3815CC8CB

I did find it sort of mentioned here, but not in context to the ASR/CSR and not exactly the same command so it wouldn’t help you if you didn’t already know the answer.

http://www.cisco.com/c/dam/en/us/td/docs/solutions/Enterprise/Data_Center/DCI/5-0/OTVmulticast.pdf

It probably should have been listed here:

http://www.cisco.com/c/en/us/support/docs/routers/asr-1000-series-aggregation-services-routers/117158-configure-otv-00.html

It definitely should have been included here:

http://www.cisco.com/c/en/us/td/docs/solutions/Hybrid_Cloud/DRaaS/CSR/CSR.pdf

Finally I found it here, http://d2zmdbbm9feqrf.cloudfront.net/2014/usa/pdf/BRKDCT-3103.pdf

Page 136 in the appendix !

Below you can see the output of the wireshark capture of the transferred packet prior to adding encryption:  IP in Eth in MPLS in GRE in IP in Eth

otv_blog_2

Well once that was working, getting it encrypted was a breezehttp://stayinginit.blogspot.in/2013/12/encrypting-overlay-transport.html

Adding IP Sec

On .78
 crypto isakmp policy 1
hash md5
authentication pre-share
group 5
 crypto isakmp key cisco123 address 10.10.10.79
 crypto ipsec transform-set ed1_ts esp-aes esp-sha-hmac
 ip access-list extended ed1_acl
permit gre host 10.10.10.78 host 10.10.10.79
 
crypto map ed1_map 1 ipsec-isakmp
set peer 10.10.10.79
set transform-set ed1_ts
match address ed1_acl
 interface GigabitEthernet1
crypto map ed1_map
 
 
On .79
 
crypto isakmp policy 1
 hash md5
authentication pre-share
group 5
 crypto isakmp key cisco123 address 10.10.10.79
 crypto ipsec transform-set ed1_ts esp-aes esp-sha-hmac
 ip access-list extended ed1_acl
permit gre host 10.10.10.79 host 10.10.10.78
 crypto map ed1_map 1 ipsec-isakmp
set peer 10.10.10.78
set transform-set ed1_ts
match address ed1_acl
 
interface GigabitEthernet1
crypto map ed1_map
 
 
Finally getting back to Tom Lijnse’ blog, he says:
 
 
Configuring OTV
The next thing I do is preparing the OTV join interface for multicast operation. I enable multicast routing, set the IGMP version to 3 and enable PIM in passive mode on the OTV join interface:
! ip multicast-routing distributed
!
interface GigabitEthernet1
ip pim passive
ip igmp version 3
!
Note: Unlike the Nexus 7000, the CSR requires multicast routing to be enabled in order to enable the IGMP functionality that is required for OTV. On the Nexus 7000 it is not necessary to enable multicast routing and PIM. Simply setting the IGMP version to 3 is sufficient on that platform

What I found was that none of that mattered, you could have left off all the statements listed there as they don’t appear to do anything in my lab, but what you must have is the

ip igmp snooping querier
 
 

Maybe some conditions of the test are at play here, or perhaps changes are being made in teh code from revision to revision I’m using 3.12   I’ll update if I find out more as this project progresses.

 

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s