MPLS Layer 3 VPN Explained

(MARKOS A) #89

Hello Networklessons.com team

I would like to make the following question. If for some reason CE1 (Customer A) wants to send a packet to CE4 (Customer B) and also be able to send packets to CE3 ( Customer A), then I guess sthat we will have to configure the PE2 to send the packet to both VRF for customer A and VRF for customer B. In this case the packet will be dropped to the VRF that does not contain the destination route?Is it correct or something else is happening? Thank you

Best Regards
Markos

(Lazaros Agapides) #90

Hello Markos

In order to allow Customer A to have access to CE4 of customer B, then you would use the appropriate RTs to do that. You can give one customer access to the networks behind another customer’s CE router by importing the appropriate RTs in the PE routers.

Now keep in mind that if you do this, the customer networks that are to communicate must use unique IP addresses. You can give one customer access to another customer’s network, but if the IP addresses are the same, such connectivity will not work.

I hope this has been helpful!

Laz

(Fabrice M) #91

Hi Rene,
I never use vpn id in my setup is it mandatory ?
In which case it could help

Cordially

(Lazaros Agapides) #92

Hello Fabrice

The use of a VPN ID is not mandatory. It is just an additional method by which VPNs can be identified.

You can read more about this feature in the following Cisco document which includes various benefits of using it:


I hope this has been helpful!

Laz

MPLS Layer 3 VPN Configuration
(Fabrice M) #93

Thanks very much Lazaros
But i see no benefit please can you share 2 benefit of using vpn id ?

Cordially

(Lazaros Agapides) #94

Hello Fabrice

The specific benefits as described by Cisco are the following:

Benefits
The MPLS VPN ID feature provides the following benefits:

  • Remote access applications, such as the Remote Authentication Dial-In User Service (RADIUS) and Dynamic Host Configuration Protocol (DHCP), can use the MPLS VPN ID feature to identify a VPN. RADIUS can use the VPN ID to assign dial-in users to the proper VPN, based on each user’s authentication information.

  • A VPN is private and uses a private address space that might also be used by another VPN or by the Internet. The IP address used in a VPN is only significant to the VPN in which it exists. The VPN ID identifies the VPN to which the IP address belongs.

  • The MPLS VPN ID feature standardizes the VPN identification method, as described in RFC 2685.

These were obtained from the following documentation:

I hope this has been helpful!

Laz

1 Like
(Kamil K) #95
  1. Does RD give a unique identifier for the same looking prefixes of different VRF’s ?

  2. Is RT there just to allow the sharing between different VRF’s but is not really necessary
    in case if we do not need sharing between VRF’s?

Because in my understanding when you Distinguish two prefixes using RD this shall be enough for the neighbour to know which VRF it belongs to (After all RD is giving this unique value for a reason I guess).

Regards,
Kamil

(Fabrice M) #96

I Think RT is necessary it the case we have many PE in the network, to permit to PE to share prefixes
We need at least to have route-target import both rd and rd is for the actual VPN

(Kamil K) #97

Hey Fabrice,

I think I finally got it now …

RD : used to distinguish between the routes so the advertising PE can actually advertise both (lets assume) “same looking” routes as two unique prefixes (even though originally they look the same).
However It has nothing to do with distinguishing for what VRF this prefix belongs too.

RT: used as a BGP Extended Community which has to be supported by both PE’s. It identifies what VRF
does the route belong to and has nothing to do with uniquely identifying the prefixes.

Now if we would not have RD :

  • two routes would appear the same to mBGP and will be installed into a BGP table
  • only one of those routes would be elected as a best route
  • only the best route is advertised from BGP table to the neighbor and this is what would have happened

Now if we would not have RT:

  • neighbor would have received two unique routes
  • it would not know what to do with them, it would get confused as to which VRF import each route into
  • devices could not successfully exchange routing information and they would not learn the routes
    even though the updates for two separate VPNv4 prefixes would be received on the PE’s

Regards and hope this helps someone too,
Kamil

(Lazaros Agapides) #98

Hello Fabrice

@kamilkugler has got it and has described it quite well. Both the RD and RT along with MP-BGP and VRFs function in order to provide routablility and operations on the control plane. Back to your original question, the VLAN IDs provide a solution to a problem that still exists on the data plane. Rene’s example in the “Transport and VPN Label” section focuses on this problem and how the VPN label solves it.

A packet may traverse the provider’s network and reach the PE device connected to the intended customer. If that PE device has two or more CEs connected to it, and these two CEs have the same IP ranges on their internal networks, there is nothing that will help the PE decide where to forward it to. This is where the VPN label must be present.

I hope this has been helpful!

Laz

(Viral B) #99

Hello Rene and All,

I have issue with the VRF setup:

If you see the attached pic, Gig0/0 int of CE1 is in C38 and Gig2/0 in C39.

PE1 and PE2 are the ISP routers and we have eBGP bet CE1 and PE1, CE2 and PE2. For my lab purposes, i am running iBGP bet PE1 and PE2 routers.

I am able to see the net 192.168.253.245 in vpnv4 BGP table of CE2 and I can see the LO addr (9.9.9.9) of CE2 router under vpnv4 BGP of CE1.

But the problem is that, I cannot ping those ips from each other.

See below:

CE1#ping vrf C38 9.9.9.9
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 9.9.9.9, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
CE1#

CE2#ping vrf C38 192.168.253.245
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.253.245, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
CE2#

Upon checking, I do see that both the routers learn the routes via vpnv4 BGP. But PE1 has no clue of 192.168.253.0/24 network. I did redistribute connected on CE1 routers, but the int Gig0/0 of CE1 is in vrf, so PE1 does not learn about this network.

See below config of CE1 router:

CE1#sh run | s bgp
router bgp 64520
 bgp log-neighbor-changes
 neighbor 192.168.0.9 remote-as 3549
 neighbor 192.168.0.18 remote-as 64530
 neighbor 192.168.0.18 ebgp-multihop 7
 !
 address-family ipv4
  redistribute connected
  neighbor 192.168.0.9 activate
  no neighbor 192.168.0.18 activate
 exit-address-family
 !
 address-family vpnv4
  neighbor 192.168.0.18 activate
  neighbor 192.168.0.18 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf C38
  redistribute connected
  neighbor 9.9.9.9 remote-as 64530
  neighbor 9.9.9.9 ebgp-multihop 4
  neighbor 9.9.9.9 activate
  neighbor 192.168.253.50 remote-as 64522
  neighbor 192.168.253.50 activate
 exit-address-family
 !
 address-family ipv4 vrf C39
  neighbor 192.168.251.70 remote-as 64521
  neighbor 192.168.251.70 activate
 exit-address-family
CE1#

How can I redistribute the VRF route into the ISP router (PE1 and PE2).

(Viral B) #100

I have updated my network diagram with the interfaces label.

I am not sure if I was able to explain the problem clearly, but redistribute the VRF routes on G0/0 int of CE1 RTR on the G1/0 int of CE1 router itself. That way PE1 and PE2 will also learn about 192.168.253.0/24 network.

I am seeing routes on both CustA and CE2 routers, but no pings working.

My goal is to have end-to-end connectivity from CustA RTR to CE2 router.

I have defined same VRFs on CE1 and CE2 routers. (Int lo1 on CE2 is in vrf)

Any help would be really appreciated!

Thanks!

(Rene Molenaar) #101

Hello Viral,

Looking at your topology and configs, the first thing I notice is that you mixed up the CE/PE terminology a bit :grin: If you want to stick to MPLS VPN terminology, the CE router is a “regular” router and the PE routers is where you configure your VRFs/VPNs etc.

Having said that, you should be able to redistribute that VRF interface into a VPN route:

PE1(config)#int loopback1
PE1(config-if)#ip vrf forwarding CUSTOMER
PE1(config-if)#ip address 123.123.123.123 255.255.255.255

PE1(config)#router bgp 234
PE1(config-router)#address-family ipv4 vrf CUSTOMER
PE1(config-router-af)#redistribute connected

We can see it in the local BGP table:

PE1#show ip bgp vpnv4 all
BGP table version is 8, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf CUSTOMER)
 *>   1.1.1.1/32       192.168.12.1             2         32768 ?
 *>i  5.5.5.5/32       4.4.4.4                  2    100      0 ?
 *>   123.123.123.123/32
                       0.0.0.0                  0         32768 ?
 *>   192.168.12.0     0.0.0.0                  0         32768 ?
 *>i  192.168.45.0     4.4.4.4                  0    100      0 ?

You might want to check that, and if you see it…check if it’s advertised to the other PE router.

Rene

(Viral B) #102

Thanks for the reply Rene.

Yes I agree, I may have mixed up the CE/PE terminoligies, may be because CE routers are managed by us and the PE routers are ISP managed.

In my scenario, I have VRFs configured on CE1/CE2 routers, and I am not able to ping from VRF end to end. We are using eBGP bet CE1-PE1 and PE2-CE2.

I tried using OSPF bet CE1-PE1 and PE2-CE2, and I am able to ping VRFs end-to-end (VRF CE1 to VRF on CE2) i.e from CustA route to Cust-RTR route. But with eBGP, it does not work.

Yes, I did redistribute connected under the address-family ipv4 and I can see the route under ‘sh ip bgp vpnv4 all’ but not on the global routing bgp table ‘sh ip bgp’. So the PE1 router does not know abt the routes to CustA or CustB.

For instance see below:
On my CE2 router I am learning the route 192.168.253.0, which is VRF interface IP addr of CE1.

CE2#sh ip bgp vpnv4 all
BGP table version is 8, local router ID is 30.30.30.30
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf C38)
 *>  9.9.9.9/32       0.0.0.0                  0         32768 ?
 *>  192.168.253.0    192.168.0.10             0             0 64520 ?
Route Distinguisher: 2:2 (default for vrf C39)
 *>  80.80.80.80/32   192.168.0.10                           0 64520 64521 ?
 *>  192.168.251.0    192.168.0.10                           0 64520 64521 ?
CE2#
CE2#
CE2#ping vrf C38 192.168.253.245
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.253.245, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
CE2#
CE2#traceroute vrf C38 192.168.253.245
Type escape sequence to abort.
Tracing the route to 192.168.253.245
VRF info: (vrf in name/id, vrf out name/id)
  1  *  *  *
  2  *  *  *
  3  *  *
CE2#

Also, on CE2 I have LO1 9.9.9.9 in vrf C38 and I learn the route on CE1 in vrf C38. But cant ping ir from CE1. See below:

CE1#sh ip bgp vpnv4 all
BGP table version is 7, local router ID is 20.20.20.20
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf C38)
 *>  9.9.9.9/32       192.168.0.18             0             0 64530 ?
 *>  70.70.70.70/32   192.168.253.50           0             0 64522 ?
 *   192.168.253.0    192.168.253.50           0             0 64522 ?
 *>                   0.0.0.0                  0         32768 ?
Route Distinguisher: 2:2 (default for vrf C39)
 *>  80.80.80.80/32   192.168.251.70           0             0 64521 ?
 r>  192.168.251.0    192.168.251.70           0             0 64521 ?
CE1#
CE1#ping vrf C38 9.9.9.9
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 9.9.9.9, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
CE1#tra
CE1#traceroute vrf C38 9.9.9.9
Type escape sequence to abort.
Tracing the route to 9.9.9.9
VRF info: (vrf in name/id, vrf out name/id)
  1  *  *  *
  2  *  *  *
  3  *  *  *
  4  *  *  *
  5
CE1#

In this scenario, I am doing eBGP bet CE1-PE1, iBGP bet PE1-PE2 and eBGP bet PE2-CE2. Below is the bgp config on CE1 and CE2:

CE1#sh run | s bgp
router bgp 64520
 bgp log-neighbor-changes
 neighbor 192.168.0.9 remote-as 3549
 neighbor 192.168.0.18 remote-as 64530
 neighbor 192.168.0.18 ebgp-multihop 7
 !
 address-family ipv4
  redistribute connected
  neighbor 192.168.0.9 activate
  no neighbor 192.168.0.18 activate
 exit-address-family
 !
 address-family vpnv4
  neighbor 192.168.0.18 activate
  neighbor 192.168.0.18 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf C38
  redistribute connected
  neighbor 9.9.9.9 remote-as 64530
  neighbor 9.9.9.9 ebgp-multihop 4
  neighbor 9.9.9.9 activate
  neighbor 192.168.253.50 remote-as 64522
  neighbor 192.168.253.50 activate
 exit-address-family
 !
 address-family ipv4 vrf C39
  neighbor 192.168.251.70 remote-as 64521
  neighbor 192.168.251.70 activate
 exit-address-family
CE1#

    CE2#sh run | s bgp
    router bgp 64530
     bgp log-neighbor-changes
     neighbor 192.168.0.10 remote-as 64520
     neighbor 192.168.0.10 ebgp-multihop 7
     neighbor 192.168.0.17 remote-as 3549
     !
     address-family ipv4
      redistribute connected
      no neighbor 192.168.0.10 activate
      neighbor 192.168.0.17 activate
     exit-address-family
     !
     address-family vpnv4
      neighbor 192.168.0.10 activate
      neighbor 192.168.0.10 send-community extended
     exit-address-family
     !
     address-family ipv4 vrf C38
      redistribute connected
      neighbor 192.168.253.245 remote-as 64520
      neighbor 192.168.253.245 ebgp-multihop 4
      neighbor 192.168.253.245 activate
     exit-address-family
    CE2#

When I use OSPF bet CE1-PE1, PE1-PE2, and PE2-CE2 and use mpls ip on all the non-vrf interfaces between, it just works fine. I am able to ping vrfs end-to-end

CE2#sh ip bgp vpnv4 all
BGP table version is 15, local router ID is 30.30.30.30
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf C38)
 *>  10.10.10.10/32   192.168.0.21             0             0 64531 i
 *>i 70.70.70.70/32   20.20.20.20              0    100      0 64522 i
 r>  192.168.0.20/30  192.168.0.21             0             0 64531 ?
 *>  192.168.0.24/30  192.168.0.21             0             0 64531 ?
 *>i 192.168.253.0    20.20.20.20              0    100      0 64522 i
Route Distinguisher: 2:2 (default for vrf C39)
 *>  10.10.10.10/32   192.168.0.26             0             0 64531 i
 *>i 80.80.80.80/32   20.20.20.20              0    100      0 64521 ?
 *>  192.168.0.20/30  192.168.0.26             0             0 64531 ?
 r>  192.168.0.24/30  192.168.0.26             0             0 64531 ?
 *>i 192.168.251.0    20.20.20.20              0    100      0 64521 ?
CE2#
CE2#ping vrf C38 192.168.253.245 source GigabitEthernet1/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.253.245, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.22
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 80/91/96 ms
CE2#

GigabitEthernet1/0 int is in VRF C38. So it works with OSPF and not with BGP. Would like to know why, since even with BGP both CE1 and CE2 are learning vrf routes but cant ping.

(Hektor M) #103

Hello everyone I was wondering if in the following topology


ping between PE1 and CE2 is possible.
PE1 knows how to reach CE2 but CE2 needs a default route pointing to PE2 but as I see on my wireshark PE2 generates a message back to CE2 that the destination (PE1 LOOPBACK) is unreachable and this is not true because PE2 knows how to reach PE1 through the global routing table.
So what is the problem ? Maybe PE2 is looking for PE1 on its vrf routing table and thats why cant route the packet? Would it fix the issue if we use route leaking between the routing - tables?

(Lazaros Agapides) #104

Hello Hektor

Ping between PE1 and CE2, under normal circumstance, should not be possible. This is because of the reason you state in your post. PE2 is looking for PE1 on its VRF routing table, because all traffic from the customer should be routing using the VRF. Route leaking would allow you to reach PE1 from CE2, but this is a highly unlikely scenario, since ISPs would not want customer equipment to have access to network devices on their internal backbone.

I hope this has been helpful!

Laz

1 Like
(Hektor M) #105

Thank you Mr Lazare you are great.

1 Like
(sims) #106

Hi
in general what is layer 3 vpn and layer 3 vpn ,
is ipsec vpn is l2 ?

Thanks

(Lazaros Agapides) #108

Hello Sims

Whenever we say that something is Layer 3, it means that it involves things like IP addresses, routing, NAT and any other mechanisms that occur at that layer. In this particular case, a Layer 3 VPN simply means that the ISP is participating in routing operations and this routing information is shared between the CE and PE devices. In contrast, a layer 2 VPN will just provide a link between two sites that just behaves as if each site is connected to a switchport of the same Layer 2 switch, essentially allowing connectivity between devices at both sites using a single subnet. Any routing that may be required must be achieved by adding a router at the customer premises. Routing in this case would only take place between the two CE routers and would not involve the ISP devices whatsoever.

As for IPSec VPN, IPSec is a layer 3 technology that provides authentication and authorization and a whole host of other security features. This is definitely a layer 3 technology as it functions as a set of companion protocols that offer these features and services.

I hope this has been helpful!

Laz

(MARKOS A) #109

Hello all

I would like to make a question. In Layer 3 MPLS VPN networks how do Ps forward the packets? I mean the router will not have the destination route in the MPLS forwarding table and routing table. It will see the label value tagged by the MPLS router that forwarded the packet to our P. If the P router has received the same label tag value from more than 1 router through the LDB exchange information process, how does it know where to forward the packet to? Does it see the local interface, where it has received the packet from and associates it with the interface used for the LDP neighborship or something else? Thank you in advance

Best Regards
Markos