MPLS VPN PE-CE OSPF Global Default Route

Lessons Discussion
1

This topic is to discuss the following lesson:

2

Hi Rene, Thanks for the lesson. could you please also show global to vrf route leaking in non MPLS environment. How it works

3

Hello Pushpender

You can find an example of VRF route leaking in a non-MPLS environment at the following lesson:

I hope this has been helpful!

Laz

4

Hi Rene.

Regarding global-to-VRF communication, I am curious about how it should be handled in the scenario where CEs have multiple networks, let’s say 20. are static routes the only way to do it? or maybe in this case there is a way to redistribute them from OSPF VRF CUSTOMER to OSPF GRT?

Thanks!

5

Hello Wuilmer

Yes, it is possible to redistribute dynamic routing protocols to redistribute routes between VRFs and the global routing table. However, in order to do so, you must be running separate instances of a routing protocol in the VRF and the global routing domain. In the lesson, the global routing domain only uses static routes. However, if you take a look at the following lesson, you will see how routes are being redistributed between the global routing domain and a VRF using dynamic routing protocols:

Take a look at this lesson and let us know if you have any further questions.

I hope this has been helpful!

Laz

6

you need to advertise 66.66.66.66 lo0 interface on the GW router

7

Hello Bahri

Actually, the 66.66.66.66 network doesn’t have to be advertised. Any traffic to 66.66.66.66 will match the default route configured in the PEs. The default route will allow traffic to reach the GW device, thus reaching 66.66.66.66.

I hope this has been helpful!

Laz

8

thank you Laz i understand it.

1 Like
9

Hi,
I attempted to come up with a solution without reading the notes first and mine was different, it involved:

  1. Configuring OSPF on GW, including Lo0:6.6.6.6 loopback (same as you).
  2. Creating a VRF on GW and joining Lo1 to it - configure RD and unique RT (export only).
  3. Configuring BGP on the GW router and forming neighbor relationships with PE1 and PE2.
  4. Configuring GW VRF to import PE1 and PE2 VPNV4 customer routes.
  5. Configuring a static default route pointing at null on GW VRF.
  6. Redistribute static default route into BGP IPv4 GW VRF and using default-info originate.
  7. On PE1 and PE2 customer VRFs, importing the GW routes (using route-target).
  8. Configure OSPF default-information originate on PE1 and PE2 customer VRFs (same as you).

Ping end to end worked but I also discovered that the GW VRF was unable to route back to PE customer VRFs with overlapping IPs (my lab was setup with two customers both having identical AS and network addresses) and also concluded NAT would be needed somewhere.

My Topology:

image
image1282×838 81 KB

Sam

10

Hello Sam

Excellent work experimenting with this topology! You’ve actually built a production-grade Shared Services MPLS VPN solution rather than a simplified educational example. The shared service in this case is Internet access. Let’s take a look at your core questions:

The solution in the lesson leaks the default route into the global routing table of the PE routers. That means that traffic exits the VRF context at the local PE and is forwarded as native IP (unlabeled) to the GW. It does not traverse the MPLS core in a labeled or tunneled manner.

Yes, you’re absolutely right. Regardless of whether you use your solution or the one in the lesson, this will be the case. As Rene states in the lesson:

If you use private IP addresses in your VRFs as I do and you have multiple VRFs, you have to be careful that you don’t have overlapping networks. Because we route traffic through the global routing table, you can’t have two VRFs with the same network addresses. When you can’t avoid overlapping address space, you have to use NAT on your CE routers.

So your instincts are spo on. Nice work developing a modified version of the lab!

I hope this has been helpful!

Laz

1 Like