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

Bring Internet access to CPE

Fab T
Level 1
Level 1

Hello all,

I am trying to learn and practice MPLS VPN. I can successfully connect customer sites together, but how can I bring Internet connectivity "properly" to customer sites ?

I am using the following topology.


Summary:
- eBGP between CORE_1 (CORE_2) and ISP_1 (ISP_2) respectively ;
- iBGP full mesh (between core routers, between core and access, between access) ;
- MP-BGP between ACCESS_1 and ACCESS_2 ;
- each customer has his VRF which is shared with MP-BGP ;

I have connectivity between access routers and "internet", so I know eBGP and iBGP is OK. I also have connectivity between customer sites. I have used same IP ranges for both customers but different IP address to be sure they do not mix :-)

Now about my goal: how to "get out" of that MPLS VPN cleanly ? How to bring internet to customer sites.

I found one way to do this:
- on the access router, create a VLAN interface on f0/0 and put it in the customer VRF
- on both core routers, create a VLAN interface on f0/0 (same VLAN id)
- establish iBGP sessions between customer VRF and core routers to route public prefixes

This works, but I find it not ideal because this means I need to change the config on nearly every device (CPE, access routers, core routers and switches). Also, it means that a packet moving between customers has to go through core routers while I think it would be best if it stayed on the access "layer".

A second way I found is to have a dedicated access device for each customer. I would then establish iBGP sessions between customer VRF and that dedicated device, and between that device and access routers. This solution does not fix everything, I still need to configure all devices but core routers, and I have a new device to manage, per customer :-( However, if the customer requires a unique internet access for all sites, this would make sense.

What do you think ?

Maybe my topology is too simple or completely wrong ?

 

Thank you for your patience if you've made it up to this point :-)

1 Accepted Solution

Accepted Solutions

Hello.

If a customer asks for public IP-address on the site - it's time to do route leaking (for the IP-address) with "Internet" vrf (0.0.0.0/0 from Internet and specific public IP from customer's vrf).

View solution in original post

5 Replies 5

Hello.

If you are running public IP-addresses per customer, then why do you need VPN?

If you are running private IP-addresses, then you need to do NAT at some place and it should be per customer.

PS: also there is an option to do route-leaking with "Internet" vrf.

Hello,

the scenario is the following: I have two customers (green and blue). Both customers require a VPN between their respective sites. So I have setup BGP between my PE (ACCESS_1 and ACCESS_2) and the CPE, each session in its own VRF, and I route between sites using MPLS.

Then for some reason, the customers require public IP addresses on the same sites, in addition to the VPN.

Of course, I could tear down the MPLS, just route public IP addresses and tell them to use classic IP VPN, but ...

Hello.

If a customer asks for public IP-address on the site - it's time to do route leaking (for the IP-address) with "Internet" vrf (0.0.0.0/0 from Internet and specific public IP from customer's vrf).

OK, I begin to understand. I think I found a document that explains this. For some reason, I did not find it before -_-

https://supportforums.cisco.com/document/32341/providing-internet-access-mpls-l3-vpns

It seems it is also possible to use the global routing table instead of a separate VRF.

 

In a dynamic environment, would not it be better to use a routing protocol instead of static routes ? I mean, since the PE can get out to internet via multiple devices, wouldn't it make more sense ?

So, I tried in GNS3 and it works fine.

On ACCESS_1, I add static routes from global to vrf to reach the public IP addresses on customer sites. I also add 2 different default routes to get out of the vrf, each pointing to a different CORE router.

It is also possible to use ip sla and track on with those routes to keep the path redundancy.

Thank you for your help :-)