cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1004
Views
15
Helpful
5
Replies

MPLS over DMVPN traffic engineering- continued

clukongo
Level 1
Level 1

MPLSHi all,

 

Not having had any feedback regarding my question on the subject covered in the link: https://community.cisco.com/t5/routing/mpls-over-dmvpn-traffic-engineering/m-p/4435095#M353137
probably because the subject was considered closed, I reiterate my request by opening a new subject.

 

As I said in the previous exchanges on the link https://community.cisco.com/t5/routing/mpls-over-dmvpn-traffic-engineering/m-p/4435095#M353137, I had succeeded in making the tunnel go up in P2MP mode with the configuration in the PNR_1 file (screenshot Test_P2MP_1).

However I have 2 problems:

The first is that despite the fact that the TE tunnels are up (Tunnel 101 and 102), it does not indicate that it is in service as it does not appear as next hop for the routes to the other sites (screenshot Test_P2MP_2).

I noticed a couple of things that make setting up TE P2MP tunnels difficult for me. For example the tunnel mpls traffic-eng autoroute announce command which allows the tunnel to be announced in the IGP (ospf-TE in my case) is not supported in P2MP and seems to have to be done otherwise.
If someone can tell me what is missing in my conf (PNR_1) for tunnels 101 and 102, it will help me a lot for the rest of my project.

The second problem is:
Following the problem encountered with the P2MP, I wanted to just use PtP tunnels between the SPOKES (PNR and DOUALA) and the HUB (PARIS).
The Tunnels go up well to the SPOKES level (PNR and DOUALA).
I then assigned these tunnels to 2 VRFs (IT and OT). VRF IT uses Tunnel 101 and VRF OT uses tunnel 102.
The traffic goes well between the SPOKES and the HUB. For example the VRF IT of PNR manages to join the VRF IT of PARIS and the VRF IT of DOUALA also manages to join the VRF IT of PARIS.
On the other hand, the VRFs cannot be reached between SPOKES (i.e. the VRF IT of PNR cannot reach the VRF IT of DOUALA.

Can you tell me what I'm missing? Is it absolutely necessary to create TE Tunnels on the HUB to make the SPOKES communicate? How to do?

Please find in attached files all the files mentioned.
Let me know if you need more information.

 

Best Regards,

 

Chris LUKONGO

1 Accepted Solution

Accepted Solutions

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello @clukongo ,

P2MP MPLS tunnels are not easy

 

>>

The first is that despite the fact that the TE tunnels are up (Tunnel 101 and 102), it does not indicate that it is in service as it does not appear as next hop for the routes to the other sites (screenshot Test_P2MP_2).

>>

I noticed a couple of things that make setting up TE P2MP tunnels difficult for me. For example the tunnel mpls traffic-eng autoroute announce command which allows the tunnel to be announced in the IGP (ospf-TE in my case) is not supported in P2MP and seems to have to be done otherwise.

 

P2MP tunnels are a very complex feature that can provide a one to many forwarding path for muticast traffic for example.

see

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipmulti_pim/configuration/xe-3s/asr903/16-12-1/b-imc-pim-xe-16-12-1-asr900/b-imc-pim-xe-16-12-1-asr900_chapter_01010.html?dtid=osscdc000283#GUID-7A527D93-4857-4182-9FCA-9E355C44CEC9

 

So I don't think they are what you need unless you are going to route multicast traffic to multiple sites.

 

Normally P2MP TE  are triggered / signaled  using special Address famillies in MP BGP like in NExt Generation Multicast VPN or in other ways.

 

You should consider using p2p tunnels instead and you have a DMVPN underlay network not a native MPLS backbone.

 

Having a DMVPN as underlay means that any forwarding optimization of a P2MP TE tunnel is useless if you have to send a packet to three destinations from the hub the hub needs to send three copies one to each Spoke. The LAN is emulated by NHRP  not real !!!

 

Spoke to spoke tunnels in DMVPN are dynamic and they exist only in the forwarding plane using OSPF and NHRP two spokes can set up a direct tunnel for exchanging unicast traffic.

However routing protocols exchanges happen only on the Spoke to Hub permanent directions sub GRE tunnels.

 

For this reason probably a Spoke to Spoke p2p TE tunnel has to go via the the HUB to work.

Hubt to spokes and spoke to Hub p2p tunnels should be able to work.

 

Hope to help

Giuseppe

 

View solution in original post

5 Replies 5

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello @clukongo ,

P2MP MPLS tunnels are not easy

 

>>

The first is that despite the fact that the TE tunnels are up (Tunnel 101 and 102), it does not indicate that it is in service as it does not appear as next hop for the routes to the other sites (screenshot Test_P2MP_2).

>>

I noticed a couple of things that make setting up TE P2MP tunnels difficult for me. For example the tunnel mpls traffic-eng autoroute announce command which allows the tunnel to be announced in the IGP (ospf-TE in my case) is not supported in P2MP and seems to have to be done otherwise.

 

P2MP tunnels are a very complex feature that can provide a one to many forwarding path for muticast traffic for example.

see

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipmulti_pim/configuration/xe-3s/asr903/16-12-1/b-imc-pim-xe-16-12-1-asr900/b-imc-pim-xe-16-12-1-asr900_chapter_01010.html?dtid=osscdc000283#GUID-7A527D93-4857-4182-9FCA-9E355C44CEC9

 

So I don't think they are what you need unless you are going to route multicast traffic to multiple sites.

 

Normally P2MP TE  are triggered / signaled  using special Address famillies in MP BGP like in NExt Generation Multicast VPN or in other ways.

 

You should consider using p2p tunnels instead and you have a DMVPN underlay network not a native MPLS backbone.

 

Having a DMVPN as underlay means that any forwarding optimization of a P2MP TE tunnel is useless if you have to send a packet to three destinations from the hub the hub needs to send three copies one to each Spoke. The LAN is emulated by NHRP  not real !!!

 

Spoke to spoke tunnels in DMVPN are dynamic and they exist only in the forwarding plane using OSPF and NHRP two spokes can set up a direct tunnel for exchanging unicast traffic.

However routing protocols exchanges happen only on the Spoke to Hub permanent directions sub GRE tunnels.

 

For this reason probably a Spoke to Spoke p2p TE tunnel has to go via the the HUB to work.

Hubt to spokes and spoke to Hub p2p tunnels should be able to work.

 

Hope to help

Giuseppe

 

Hi Giuseppe,

 

Thanks for your feedback.
Indeed, I agree with you, the series of tests I have done indicate that spoke-hub-spoke P2P traffic seems to be the best option.
I will maintain this option. Thank you again for your much appreciated feedback.

 

Best regards,

 

Chris LUKONGO

not full understand issue here but, 

TE support with OSPF and I think you config DMVPN with EIGRP ?

Hi,

no, i have configured DMVPN with ospf.

The issue is that I was looking for a way to be able to create multipoint TE tunnels from the Hub to all the spokes so as not to have a large number of PtP tunnels on the Hub. For now, I have applied traffic engineering only on the spokes with PtP Tunnels pointing to the Hub.

 

Rgds,

 

Chris LUKONGO

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: