zNetLaB › Guided labs › Service Provider
MPLS L3VPN from customer to customer
Service Provider Advanced 5 devices 5 checked tasks 100 points Plan lab
Two customer sites in different autonomous systems meet across a provider core that knows nothing about them. Build the IGP and LDP, the VPNv4 session between the PEs, the VRF, and BGP to each customer. You build it in a browser, type real commands at each device, and every task below is
checked against the running configuration — so you find out it is wrong before anybody else does.
Open this lab in the simulator
The simulator runs in your browser with nothing to install. This lab is part of the full simulator: open it free for 7 days with a new account, then with a plan. It needs an account, which keeps your progress.
The scenario
Two customer sites in different autonomous systems meet across a provider core that knows nothing about them. Build the IGP and LDP, the VPNv4 session between the PEs, the VRF, and BGP to each customer.
Your role: an engineer in the provider’s network operations centre. Level: Advanced Done when: all 5 goals show as passed (100 points).
Network status
Devices: 5 routers, cabled as drawn. No Layer 1 or Layer 2 faults: every link is connected and up. CE1, PE1, P, PE2, CE2 start with an empty configuration. Known problems
None: nothing is misconfigured. The network is simply not finished: what the goals list is what you have to build or secure. Goals
LDP is up across the core (15 pts) The PEs share a BGP session between loopbacks (15 pts) PE1 holds the far customer route in the VRF (20 pts) The core has no customer route (15 pts) CE1 reaches CE2 end to end (35 pts) The activity, in order
LDP is up across the core Why: Each goal is a state the lab can check on the running device. Verify with: show running-config The PEs share a BGP session between loopbacks Why: BGP does nothing until the TCP session is Established. Active or Idle means a wrong AS number, no route to the peer, or a block. Verify with: show ip bgp summary PE1 holds the far customer route in the VRF Why: Each goal is a state the lab can check on the running device. Verify with: show running-config The core has no customer route Why: A route that should not exist is a leak or a loop waiting to happen. Verify with: show ip route CE1 reaches CE2 end to end Why: A ping needs a route in BOTH directions. This is the end-to-end proof that everything before it worked. Verify with: ping 172.16.2.1 Tips
Work in the order given: later goals depend on the earlier ones. After every change, run the verify command before moving on; do not guess. Stuck? Read the verify output first. It names the interface, neighbour or route that is wrong. Why this matters
Two customer sites in different autonomous systems meet across a provider core that knows nothing about them. Build the IGP and LDP, the VPNv4 session between the PEs, the VRF, and BGP to each customer.
What you will be able to do
LDP is up across the core
The PEs share a BGP session between loopbacks
PE1 holds the far customer route in the VRF
The core has no customer route
The network
Catalyst 8000V — 5 devices in all, already cabled.
Gi1 Gi1 Gi2 Gi1 Gi2 Gi2 Gi1 Gi1 CE1 PE1 P PE2 CE2 Drawn from this lab: devices, cables, ports and the addresses already set. Device Model Address already set
CE1 Catalyst 8000V configure it PE1 Catalyst 8000V configure it P Catalyst 8000V configure it PE2 Catalyst 8000V configure it CE2 Catalyst 8000V configure it
Cabling
CE1 Gi1 ↔ PE1 Gi1 PE1 Gi2 ↔ P Gi1 P Gi2 ↔ PE2 Gi2 PE2 Gi1 ↔ CE2 Gi1
What is configured at the start
Nothing is configured to start with beyond the addresses above: you build the configuration from a clean start.
Tasks, and how each one is checked
Every task is decided by reading the live network — a neighbour in FULL, a ping that succeeds, a line in the running configuration — not by looking for a keyword you typed. The same command shows you what the lab sees.
# Task Pts How to verify it yourself
1 LDP is up across the core 15 Checked automatically against the device’s live state (ldpNbrs). 2 The PEs share a BGP session between loopbacks 15 On PE1: show ip bgp summary — neighbour 3.3.3.3 is Established. 3 PE1 holds the far customer route in the VRF 20 Checked automatically against the device’s live state (vrfRoute). 4 The core has no customer route 15 On P: show ip route does not list 172.16.2.1/32. 5 CE1 reaches CE2 end to end 35 On CE1: ping 172.16.2.1 must succeed.
Stuck? Ask the coach
Tell the coach what you see or what you tried. It gives you a hint, not the answer, the way a senior engineer would. Included with a free trial or any plan.
Ask the coach
Reference solution
Try it yourself first — the lab checks your work either way. This is one configuration that makes every task pass, device by device:
P interface GigabitEthernet1
ip address 10.0.12.2 255.255.255.0
no shutdown
exit
interface GigabitEthernet2
ip address 10.0.23.2 255.255.255.0
no shutdown
exit
interface Loopback0
ip address 2.2.2.2 255.255.255.255
exit
router ospf 1
router-id 2.2.2.2
network 2.2.2.2 0.0.0.0 area 0
network 10.0.12.0 0.0.0.255 area 0
network 10.0.23.0 0.0.0.255 area 0
mpls ldp autoconfig
exit PE1 vrf definition CUST
rd 65000:1
route-target export 65000:1
route-target import 65000:1
address-family ipv4
exit-address-family
exit
interface GigabitEthernet2
ip address 10.0.12.1 255.255.255.0
no shutdown
exit
interface GigabitEthernet1
vrf forwarding CUST
ip address 192.168.1.1 255.255.255.0
no shutdown
exit
interface Loopback0
ip address 1.1.1.1 255.255.255.255
exit
router ospf 1
router-id 1.1.1.1
network 1.1.1.1 0.0.0.0 area 0
network 10.0.12.0 0.0.0.255 area 0
mpls ldp autoconfig
exit
router bgp 65000
neighbor 3.3.3.3 remote-as 65000
neighbor 3.3.3.3 update-source Loopback0
address-family vpnv4
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 send-community extended
exit-address-family
address-family ipv4 vrf CUST
redistribute connected
neighbor 192.168.1.2 remote-as 65001
neighbor 192.168.1.2 activate
exit-address-family
exit PE2 vrf definition CUST
rd 65000:2
route-target export 65000:1
route-target import 65000:1
address-family ipv4
exit-address-family
exit
interface GigabitEthernet2
ip address 10.0.23.3 255.255.255.0
no shutdown
exit
interface GigabitEthernet1
vrf forwarding CUST
ip address 192.168.2.1 255.255.255.0
no shutdown
exit
interface Loopback0
ip address 3.3.3.3 255.255.255.255
exit
router ospf 1
router-id 3.3.3.3
network 3.3.3.3 0.0.0.0 area 0
network 10.0.23.0 0.0.0.255 area 0
mpls ldp autoconfig
exit
router bgp 65000
neighbor 1.1.1.1 remote-as 65000
neighbor 1.1.1.1 update-source Loopback0
address-family vpnv4
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 send-community extended
exit-address-family
address-family ipv4 vrf CUST
redistribute connected
neighbor 192.168.2.2 remote-as 65002
neighbor 192.168.2.2 activate
exit-address-family
exit CE1 interface GigabitEthernet1
ip address 192.168.1.2 255.255.255.0
no shutdown
exit
interface Loopback1
ip address 172.16.1.1 255.255.255.255
exit
router bgp 65001
neighbor 192.168.1.1 remote-as 65000
network 172.16.1.1 mask 255.255.255.255
redistribute connected
exit CE2 interface GigabitEthernet1
ip address 192.168.2.2 255.255.255.0
no shutdown
exit
interface Loopback1
ip address 172.16.2.1 255.255.255.255
exit
router bgp 65002
neighbor 192.168.2.1 remote-as 65000
network 172.16.2.1 mask 255.255.255.255
redistribute connected
exit Related labs
Where to start
The lessons all guided labs plans
CCNA®, CCNP® and Cisco® are trademarks of Cisco Systems, Inc. zNetLaB is not affiliated with or endorsed by Cisco.