MPLS VPN Not working

[nwekechampion]

Hi all,

I am new to this.

I have simulated an MPLS L3VPN using:

1. EBGP for CE-PE  connectivity

2. VRFs on PE routers

4. MP BGP on PE routers and

4. VPNv4

However whenever I try to ping one site from another (eg: from CustBSite01 to CustBSite02) it does not work.

Can anyone help out please or point me to what needs to be done?

See diagram and configs attached

[Francesco Molino]

Hi

I'm looking at your config very quickly through my phone. I'll take a closer look tomorrow.

In the mean time:
- is that working for customer A?
- can you do a sh ip bgp on ce1b?
- on both PE, can you run sh io bgp vpnv4 vrf CustomerB?

Please share all outputs.

[nwekechampion]

Hi Francesco,

Thanks again for following up on my questions:

1. No not working for CustomerA as well
2. Sh ip bgp I get the following:
sh ip bgp
BGP table version is 2, local router ID is 172.16.1.254
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
*> 172.16.2.0/24 10.0.0.5 0 64501 64302 i

3.

On PE1:

sh ip bgp vpnv4 vrf CustomerB
BGP table version is 9, local router ID is 10.1.1.1
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: 64501:2 (default for vrf CustomerB)
*>i 172.16.2.0/24 10.1.1.3 0 100 0 64302 i

PE1#sh ip bgp vpnv4 vrf CustomerA
BGP table version is 9, local router ID is 10.1.1.1
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: 64501:1 (default for vrf CustomerA)
*> 172.16.1.0/24 10.0.0.2 0 0 64401 i
*>i 172.16.2.0/24 10.1.1.3 0 100 0 64402 i

On PE2:

#sh ip bgp vpnv4 all
BGP table version is 7, local router ID is 10.1.1.3
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: 64501:1 (default for vrf CustomerA)
*>i 172.16.1.0/24 10.1.1.1 0 100 0 64401 i
*> 172.16.2.0/24 10.0.0.18 0 0 64402 i
Route Distinguisher: 64501:2 (default for vrf CustomerB)
*> 172.16.2.0/24 10.0.0.22 0 0 64302

[Cristian Matei · Accepted solution]

Hi,

  For customer B, you have a wrong BGP network statement (copy paste from the other side probably) on CE1B (network 172.16.2.0 mask 255.255.255.0 is wrong, use 172.16.1.0 mask 255.255.255.0). At this point you should see on both CE routers a BGP route for the remote CE (show ip route BGP), and you should also have IP connectivity. If you ping between CE's to verify connectivity, make sure to specify the source of the ping, otherwise it will exit with a source IP address of the CE-PE interconnect, which is not advertised into BGP (via redistribute connected on the PE routers), which means routing will fail and data plane will fail (no BGP route, no label).

Regards,

Cristian Matei.

[nwekechampion]

HI Cristian,

Made the changes as below:

++++++++++++++++++++++++++++++++++++++++++++++++++++++

PE1

router bgp 64301
bgp log-neighbor-changes
network 172.16.1.0 mask 255.255.255.0
neighbor 10.0.0.5 remote-as 64501

PE2

router bgp 64302
bgp log-neighbor-changes
network 172.16.2.0 mask 255.255.255.0
neighbor 10.0.0.21 remote-as 64501

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CE1b's route now appears on PE1's BGP Table.

However, I have a very important question surrounding the concept of MPLS,RD,VRF,VPNV4, etc

1. How do I also ensure that I am pinging the right route? As I have both networks on each side in exactly the same subnet (172.16.1.0/24 and GW: 172.16.1.254) ==> Site01 and (172.16.2.1.0/24 GW: 172.16.2.254) ==> GW

1. Which of the above (i.e: MPLS,RD,VRF,VPNV4), would be chielfy responsible for distinguishing the routes? My guess is RD.if so or if not, how does it work please?

Thanks so much for your time and input.

[Cristian Matei]

Hi,

   Now, what i'm about to explain next, might differ based on the design and what you want to accomplish, but the fundamentals are defined. I highly recommend reading this book if you want to understand the inner workings: https://www.ciscopress.com/store/mpls-fundamentals-9781587051975

    1. What you're saying is that you have both Customers (A and B) with the same IPv4 address space. So a PE can receive same IP address space from multiple customers and this is not a problem as it receives it, as it receives it in different VRF's. The problem is that the PE needs to propagate these routes further via BGP and these routes need to be different/distinguished. For this reason, on each PE, you'll have a unique RD (Route Distinguisher) for each VRF, so that when the same IPv4 address space is advertised as VPNv4 via BGP, the prefixes are distinguished. For example:

    Customer A has 172.16.1.0/24 and Customer B also has 172.16.1.1.0/24, both connected to same PE in different VRF's. Because VRF A has RD of 100:100, while VRF B has RD of 200:200, when these IPv4 routes are picked up from ICP PE-CE routing and advertised via BGP, they became VPNv4 routes, by having the RD value attached, thus they are now unique, distinguishable. Customer A VPNv4 route becomes 100:100:172.16.1.0/24, while Customer B VPNV4 route becomes 200:200:172.16.2.0.24 

    2. You ensure you're pinging the correct "route", and by this you mean you're reaching the remote site of the intended customer, not the unintended one, due to your RT configuration under the VRF. On the ingress PE, when you take IPv4 routes from PE-CE IGP and advertise it to BGP, this is called the export operation and at this point the routes becomes VPNv4 route and will also have attached as extended communities all RT export values defined in the VRF. These VPNv4 routes get propagated across the ISP and when a PE receives a VPN route, it looks at the attached RT values and looks into its locally defined VRF's to see in which one does it import the routes via RT import statements in order to accept the VPNV4 route or not. When you take the VPNV4 routes and redistribute it back to PE-CE IGP routing, this is called the import process. So in order Not to leak routes between customers accidentally, you need to take good care on the used RT values and they import/export definition.

Regards,

Cristian Matei.

[Georg Pauwen]

Hello,

in addition to the other posts, I think on PE1 and PE2 you are missing network 10.0.0.4/30 and network 10.0.0.20/30  in your EIGRP:

PE1

router eigrp 1

--> network 10.0.0.4 0.0.0.3
network 10.0.0.8 0.0.0.3
network 10.1.1.1 0.0.0.0

PE2

router eigrp 1

--> network 10.0.0.20 0.0.0.3
network 10.0.0.12 0.0.0.3
network 10.1.1.3 0.0.0.0

[Georg Pauwen]

Hello,

using your configurations, I recreated your setup in GNS3. I think the problem is, in additon to the wrong network statement mentioned by Christian, the mask on the loopback interface of PE1:

interface Loopback0
ip address 10.1.1.1 255.255.255.252 <-- change that to 255

[nwekechampion]

Hey George,

Not sure if really need that, as I am already using BGP for CE to PE routing?

so the route already advertised to mpls network via bgp.

Wont show up in routing table as AD is higher than BGP's

I did make changes, as directed though but did not see any noticeable effect.

Could you possibly clarify if needed please?

Still having some connectivity issues especially host to host

Thank you so much

[samirhkreal]

I think this is problem related to VRF. Try this changes.

PE1
ip vrf CustomerA
rd 64501:1
route-target export 64501:1
route-target import 64501:3

ip vrf CustomerB
rd 64501:2
route-target export 64501:2
route-target import 64501:4

PE2
ip vrf CustomerA
rd 64501:3
route-target export 64501:3
route-target import 64501:1

ip vrf CustomerB
rd 64501:4
route-target export 64501:4
route-target import 64501:2