OTV on DMVPN

[Muhammed AKYUZ]

Hi,

we are getting L3 MPLS service from ISP. ISP do not provide Multicast Routing. For that reason I will run multicast on DMVPN GRE tunnels. My questions is does OTV works on DMVPN interfaces?

thank you.

[Peter Paluch · Accepted solution]

Hi Muhammed,

I have not personally deployed this. However, considering the fact that all OTV traffic should be IP-encapsulated, for DMVPN, it should be just another IP traffic to carry across. So in my personal opinion, it should work. Obviously, the MTU issues arising from additional layer of GRE+IP headers will have to be deal with.

Best regards,

Peter

[Muhammed AKYUZ]

Hi Peter,

nice to see you here after networkers...

I can deal with the MTU. I will try on ASR routers if i have chance to get routers. I will inform you about the results.

Take care.

[Peter Paluch]

Hi Muhammed,

It's good to see you, too! Please keep me informed - I would like very much to see if there were any major issues running the OTV over DMVPN.

Best regards,

Peter

[Muhammed AKYUZ]

Hi,

I managed to work normal OTV. but after specifying join interface as DMVPN tunnel OTV did not work. EIGRP which is based on multicast works but OTV not. 

my configuration:

otv site bridge-domain 1

!

otv site-identifier 0000.0000.0005

!

crypto isakmp policy 1

encr 3des

authentication pre-share

crypto isakmp key SIFRE address 0.0.0.0       

crypto isakmp keepalive 10

!

!

crypto ipsec transform-set TRANS esp-3des esp-sha-hmac

mode transport

crypto ipsec fragmentation after-encryption

!

crypto ipsec profile CRYPTO-PROFILE

set security-association lifetime seconds 900

set transform-set TRANS

!

!

interface Tunnel10

ip address 172.1.1.1 255.255.255.0

no ip redirects

ip mtu 1400

no ip next-hop-self eigrp 1

no ip split-horizon eigrp 1

ip pim passive

ip nhrp authentication NHRP_KEY

ip nhrp map multicast dynamic

ip nhrp network-id 1

ip nhrp holdtime 450

ip tcp adjust-mss 1360

ip igmp version 3

tunnel source GigabitEthernet1/1/0

tunnel mode gre multipoint

tunnel key 100

tunnel path-mtu-discovery

tunnel protection ipsec profile CRYPTO-PROFILE shared

!

interface Overlay2

no ip address

otv control-group 225.0.0.1

otv data-group 232.0.0.0/8

otv join-interface Tunnel10

service instance 200 ethernet

  encapsulation dot1q 200

  bridge-domain 200

!

!

interface GigabitEthernet1/1/0

ip address 12.12.12.1 255.255.255.0

negotiation auto

cdp enable

!

interface GigabitEthernet1/1/1

no ip address

negotiation auto

cdp enable

service instance 1 ethernet

  encapsulation untagged

  bridge-domain 1

!

service instance 201 ethernet

  encapsulation dot1q 200

  bridge-domain 200

!

!

!

interface GigabitEthernet0

vrf forwarding Mgmt-intf

ip address 1.1.1.1 255.255.255.0

negotiation auto

!

!

router eigrp 1

network 0.0.0.0

passive-interface GigabitEthernet1/1/0

!

ip pim ssm default

[Peter Paluch]

Hello Muhammed,

Perhaps the problem is caused by the missing multicast mappings in NHRP cache on the tunnel interfaces. You see, the ip nhrp map multicast dynamic command is intended to be used on NHS hub router to add all registered NBMA address to multicast mappings automatically. However, its effect on spoke routers may not be sufficient - either it does not automatically add discovered NBMA addresses to multicast mappings (and even if it does, spoke routers would need first to communicate with all other spokes to learn about their NBMA addresses), or it reacts only the NHRP registrations - something that spoke routers never receive.

Can you try entering all multicast mappings on spoke routers statically, i.e.

interface Tunnel10

ip nhrp map multicast X.X.X.X

ip nhrp map multicast Y.Y.Y.Y

for all other spoke router NBMA addresses?

Best regards,

Peter

[Muhammed AKYUZ]

Hi Peter,

i have done that config on spoke side. Eigrp works ok on dmvpn. it means multicast traffic should work. cisco responded me: otv works on core multicast. what is core multicast?

Sent from Cisco Technical Support iPhone App

[Peter Paluch]

Hi Muhammed,

I apologize but I am not exactly sure about the configuration changes you performed. Can you perhaps post a sanitized configuration of the GRE multipoint interface both from your hub and one spoke router please?

Regarding the Cisco's answer: I am not sure what they mean by "core multicast" and speculations won't help here. Did they tell you anything more?

Best regards,

Peter

[Muhammed AKYUZ]

mm

I have received this resonse from support:

Overlay Transport Virtualization (OTV) on Cisco ASR 1000 needs core multicast support. Here's the configuration guide for the OTV feature on the ASR1000 for IOS XE 3.5S:

Wide-Area Networking Configuration Guide: Overlay Transport Virtualization, Cisco IOS XE Release 3S - Configuring Overlay Transport Virtualization

http://www.cisco.com/en/US/docs/ios-xml/ios/wan_otv/configuration/xe-3s/wan-otv-confg.html

Sent from Cisco Technical Support iPhone App

[Peter Paluch]

Hello Muhammed,

I guess what the support is saying is that the core network that interconnects your data centers should be multicast-enabled. However, they do not say that DMVPN is unsupported and the DMVPN itself can be considered multicast-enabled because it behaves as a single network segment.

Once again, please, be so kind to post the configuration of the tunnel interface on your hub router and on one of your spokes (assuming the spokes are identically configured). Thank you!

Best regards,

Peter

[Muhammed AKYUZ]

hi Peter,

spoke configuration is like this:

crypto isakmp policy 1

encr 3des

authentication pre-share

crypto isakmp key SIFRE address 0.0.0.0       

crypto isakmp keepalive 10

!

!

crypto ipsec transform-set TRANS esp-3des esp-sha-hmac

mode transport

crypto ipsec fragmentation after-encryption

!

crypto ipsec profile CRYPTO-PROFILE

set security-association lifetime seconds 900

set transform-set TRANS

!        

!

!

!

!

!

!

interface Tunnel10

ip address 172.1.1.3 255.255.255.0

no ip redirects

ip mtu 1400

ip pim passive

ip nhrp authentication NHRP_KEY

ip nhrp map multicast dynamic

ip nhrp map 172.1.1.1 12.12.12.1

ip nhrp map multicast 12.12.12.1

ip nhrp network-id 1

ip nhrp holdtime 450

ip nhrp nhs 172.1.1.1

ip nhrp registration timeout 30

ip tcp adjust-mss 1360

ip igmp version 3

tunnel source GigabitEthernet1/1/0

tunnel mode gre multipoint

tunnel key 100

tunnel path-mtu-discovery

tunnel protection ipsec profile CRYPTO-PROFILE shared

!

interface Overlay2

no ip address

otv control-group 225.0.0.1

otv data-group 232.0.0.0/8

otv join-interface Tunnel10

service instance 200 ethernet

  encapsulation dot1q 200

  bridge-domain 200

!

[Peter Paluch]

Hello Muhammed,

Thank you! So what I would like to ask you to do is to add additional mapping commands on spoke routers that map other spokes' real addresses with multicast flag, so that when a spoke sends a multicast packet over the DMVPN cloud, it will be replicated to all other spokes. Assuming that there are 4 spokes with addresses 1.1.1.1, 2.2.2.2, 3.3.3.3 and 4.4.4.4, respectively, you would add on Spoke 1:

interface Tun10
 ip nhrp map multicast 2.2.2.2
 ip nhrp map multicast 3.3.3.3
 ip nhrp map multicast 4.4.4.4

on Spoke 2:

interface Tun10
 ip nhrp map multicast 1.1.1.1
 ip nhrp map multicast 3.3.3.3
 ip nhrp map multicast 4.4.4.4

on Spoke 3:

interface Tun10
 ip nhrp map multicast 1.1.1.1
 ip nhrp map multicast 2.2.2.2
 ip nhrp map multicast 4.4.4.4

and on Spoke 4:

interface Tun10
 ip nhrp map multicast 1.1.1.1
 ip nhrp map multicast 2.2.2.2
 ip nhrp map multicast 3.3.3.3

I know this is not a scalable solution at all and it defeats the dynamic mapping nature of DMVPN - but at least we should be able to verify if the OTV is capable of running over DMVPN in this state.

I know that you have objected that EIGRP uses multicasts and works fine. That is true, however, in DMVPN, EIGRP (and other routing protocols) in fact work only in a hub-and-spoke fashion. Spoke routers do not usually communicate in the routing protocol directly. What we need for OTV is a full multicast connectivity.

Best regards,

Peter

[Muhammed AKYUZ]

Hi Peter,

in my lab, there are 2 ASR routers. One is hub another one is spoker. I am not able to get more than 2 ASRs. So There are 1 hub and 1 spoke. I have sent the hub and spoke dmvpn config. On dmvpn config i have tried also pim dense mode and sparse mode, works fine. But OTV mutlicasr doesn not work. I have started OTV debug, ASR sends multicast but does not receive join messages.

Also i have tried simle GRE tunnel. It did not work also.

If you have time on Monday, i can show you remotly at my demo lab.

[Peter Paluch]

Hello Muhammed,

I see now, thanks. (It would have been easier if you described the topology earlier but never mind.)

My fundamental interest now lies in discovering whether the multicasted OTV messages are carried via the DMVPN tunnel from hub to spoke, whether they are correctly received and processed there, and whether the responses make it correctly back to the hub.

What's interesting is the fact that not even a point-to-point GRE tunnel worked. If you connected the routers with just a plain direct cable with no tunnels, would they be capable of establishing the OTV connection correctly - with the identical config, just referencing a different join interface?

Best regards,

Peter

[Peter Paluch]

Muhammed,

One more thing: can you try removing the IPsec configuration for the time being, and leave just the basic unencrypted/unprotected GRE without IPsec? There was another (unresolved) post regarding OTV over GRE that suggested that without IPsec, it worked, but it stopped working after using the IPsec.

Best regards,

Peter