Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

OTV on DMVPN

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.

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

OTV on DMVPN

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

20 REPLIES
Cisco Employee

OTV on DMVPN

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

New Member

OTV on DMVPN

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.

Cisco Employee

OTV on DMVPN

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

New Member

OTV on DMVPN

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

Cisco Employee

Re: OTV on DMVPN

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

New Member

Re: OTV on DMVPN

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

Cisco Employee

Re: OTV on DMVPN

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

New Member

Re: OTV on DMVPN

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

Cisco Employee

Re: OTV on DMVPN

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

New Member

Re: OTV on DMVPN

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

!

Cisco Employee

Re: OTV on DMVPN

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

New Member

Re: OTV on DMVPN

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.

Cisco Employee

Re: OTV on DMVPN

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

Cisco Employee

Re: OTV on DMVPN

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

New Member

Re: OTV on DMVPN

I had DMVPN running OTV. I did it two ways. I put the join interface on a loopback and used pim sparse/pim nbma and also tried with pim dense on the tunnel. It worked well (caveat at the bottom)

The second set of configs had the join interface set as the tunnel (caveat at the bottom).

In all instances I had to manually add an "ip igmp join x.x.x.x" for the control group on the join interface. This pops in a CLNS duplicate system ID message. All I did was add a logging discriminator to ignore those messages.

We had to abandon OTV since it requires that all clients support SSM. Since multicast relies on igmp snooping it does not work with ssm static mappings.

New Member

Re: OTV on DMVPN

can you share your latest configuration?

Cisco Employee

Re: OTV on DMVPN

Hi,

Even though this post is quiet old, I just to add one small information here, as of today there is no formal support to use logical interfaces as a join-interface [in ASR1K]. So, the solution if you cannot have a multicast-core is to go for unicast usage of OTV [adjacency server usage]

New Member

Re: OTV on DMVPN

How about you try running OTV with adjacency server instead ? Available with 5.2 and no need for multicast in the core/backbone

Sent from Cisco Technical Support iPhone App

New Member

Re: OTV on DMVPN

How about you try running OTV with adjacency server instead ? Available with 5.2 and no need for multicast in the core/backbone.

Sent from Cisco Technical Support iPhone App

Cisco Employee

Re: OTV on DMVPN

Sorry for the delay in getting back to you guys, but I just came across this post. As of IOS XE3.10, using a GRE Tunnel as a join interface is not supported on ASR1000. The join interface must be a POS interface, GigE interface, GigE sub-interface, Port-channel interface, or Port-channel sub-interface.  While you may be able to configure a GRE tunnel interface as the join interface and have it work successfully, it is not an officially supported configuration.  This is due to the fact that we need to be able to detect all conditions where an OTV router looses connectivity to the other OTV routers via the join interface.  We can do this for the interface types listed but not for the logical interfaces (including Loopbacks, GRE tunnels, etc).

You can however configure GetVPN on the phyiscal join interfaces to provide the encryption,

3541
Views
0
Helpful
20
Replies
CreatePlease login to create content