cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
429
Views
0
Helpful
5
Replies

MPLS over DMVPN - Design Concept and Use-Case

nwekechampion
Participant
Participant

Hi all,

Just looking to understand the design concept and use-case of MPLS over DMVPN.

Why would one need to have both of them running conccurently and how does it work from high-level understanding?

My understanding of DMVPN ==> done over Internet (NBMA IP)

My understanding of MPLS ==> done over Service Provider MPLS cloud 

So why merge the 2 above? What does that solve?

Thanks

Champ

1 Accepted Solution

Accepted Solutions

Hello @nwekechampion ,

I have read the document at the link you have provided

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_dmvpn/configuration/xe-16-10/sec-conn-dmvpn-xe-16-10-book/sec-conn-dmvpn-xe-16-10-book_chapter_010000.html

Short answer :

This is a specialized niche feature that allows to support end to end  MPLS L3 VPN traffic of multiple VPNs over a single DMVPN cloud.

Long answer:

It is a specialized feature for carrying MPLS L3 VPN traffic and MPLS L3 VPN control plane  ( MP BGP AF vpnv4 ) over a single DMVPN cloud.

This solution leverages on DMVPN  Phase 2 where  the

next hops

are left unchanged.

MP BGP Ipv4  AF can be used to  advertise the BGP

next-hops

used by  MP BGP

vpnv4 prefixes

A

VPNv4 prefix

includes a BGP

next-hop

one or more route targets and a

VPNv4 prefix

that is made of

RD+IPv4 prefix

A VPN label allocated by the remote PE is associated with the

VPNv4 prefix

The HUB has to act as iBGP route reflector for all address families IPv4 and VPNv4.

A Spoke A / PEA that receives traffic on an interface associated to   a VRF 

VRF_A1

will use the route table of the VRF to find out the BGP

next-hop

of the destination address.

The BGP

next-hop

should be the loopback of remote SpokeB / PE node.

By using knowledge from MP BGP IPv4 and NHRP Spoke A understands that it has to setup an IPSec dynamic spoke to spoke tunnel to Spoke B.

The tunnel is started and once it is operational Spoke A can send an MPLS frame to the other end of the tunnel with a single label the VPN label that has been advertised by Spoke B in VPNv4.

Spoke B examines the label to understand the VRF the packet belongs to. It strips the label and sends the packet out the VRF interface towards the destination address.

Because the dynamic tunnel is a logical direct connection between SpokeA and Spoke B and the PHP applies there is no need to use LDP to build end to end LSPs between loopback addresses of spokes.

In fact the feature does not use LDP.

The VPN traffic can travel only on direct spoke to spoke tunnel and not via the hub for what is written just above.

The advantage  of this feature is that multiple VPNs can use a single DMVPN cloud compared to a VRF lite approach where each VRF would need a dedicated DMVPN cloud to achieve end to end connectivity.

The possible use case are limited to :

enteprises that want to have MPLS L3 VPNs extended between sites but the sites have only internet access links where a DMVPN cloud is implemented

Very specific feature with limited use case.

Hope to help

Giuseppe

 

View solution in original post

5 Replies 5

They different technologies that do completely different things. They are not mutually exclusive. What if an ISP has a HUB/Spoke topology that they are running MPLS on and want to incorporate DMVPN. You can have both or neither in any environment.

DMVPN simplifies the HUB/Spoke topology setup while requiring minima configuration and MPLS uses labels to forward so the underlying transport can be more than just IP.

 

Hope that helps

-David

Hello
The main reason would be to have resilience, MPLS would be the main circuit and the DMVPN would be the back up, or maybe you have a part of the network that needs to be segregated from the mpls service that but not at the cost of running mpls.



Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

nwekechampion
Participant
Participant

So sorry guys, I have read both comments several times and still don't understand why and how MPLS would co-exist with DMVPN.

I have read the below a few times too, but Cisco docs ae notoriously terrible at explaining advanced concept like these in a easy to understand manner.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_dmvpn/configuration/xe-16-10/sec-conn-dmvpn-xe-16-10-book/sec-conn-dmvpn-xe-16-10-book_chapter_010000.html

@paul driver .. are you referring to an enterprise having 2 transports (MPLS and WAN) ? Not sure that is what the above doc refers to

@David Ruess could you maybe break this down a little bit, how exactly DMVPN achieves that "minimal config"

Hello @nwekechampion ,

I have read the document at the link you have provided

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_dmvpn/configuration/xe-16-10/sec-conn-dmvpn-xe-16-10-book/sec-conn-dmvpn-xe-16-10-book_chapter_010000.html

Short answer :

This is a specialized niche feature that allows to support end to end  MPLS L3 VPN traffic of multiple VPNs over a single DMVPN cloud.

Long answer:

It is a specialized feature for carrying MPLS L3 VPN traffic and MPLS L3 VPN control plane  ( MP BGP AF vpnv4 ) over a single DMVPN cloud.

This solution leverages on DMVPN  Phase 2 where  the

next hops

are left unchanged.

MP BGP Ipv4  AF can be used to  advertise the BGP

next-hops

used by  MP BGP

vpnv4 prefixes

A

VPNv4 prefix

includes a BGP

next-hop

one or more route targets and a

VPNv4 prefix

that is made of

RD+IPv4 prefix

A VPN label allocated by the remote PE is associated with the

VPNv4 prefix

The HUB has to act as iBGP route reflector for all address families IPv4 and VPNv4.

A Spoke A / PEA that receives traffic on an interface associated to   a VRF 

VRF_A1

will use the route table of the VRF to find out the BGP

next-hop

of the destination address.

The BGP

next-hop

should be the loopback of remote SpokeB / PE node.

By using knowledge from MP BGP IPv4 and NHRP Spoke A understands that it has to setup an IPSec dynamic spoke to spoke tunnel to Spoke B.

The tunnel is started and once it is operational Spoke A can send an MPLS frame to the other end of the tunnel with a single label the VPN label that has been advertised by Spoke B in VPNv4.

Spoke B examines the label to understand the VRF the packet belongs to. It strips the label and sends the packet out the VRF interface towards the destination address.

Because the dynamic tunnel is a logical direct connection between SpokeA and Spoke B and the PHP applies there is no need to use LDP to build end to end LSPs between loopback addresses of spokes.

In fact the feature does not use LDP.

The VPN traffic can travel only on direct spoke to spoke tunnel and not via the hub for what is written just above.

The advantage  of this feature is that multiple VPNs can use a single DMVPN cloud compared to a VRF lite approach where each VRF would need a dedicated DMVPN cloud to achieve end to end connectivity.

The possible use case are limited to :

enteprises that want to have MPLS L3 VPNs extended between sites but the sites have only internet access links where a DMVPN cloud is implemented

Very specific feature with limited use case.

Hope to help

Giuseppe

 

Thank you

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: