CONTROL PLANE WALKTHROUGH

We are done with configuration, all in all it was not a complex task, what is more
important is an understanding whats going on with control and data planes? I
believe you will like this step-by-step walk through every node in the network.
I will start with dissection of a control plane operation from the point where MP-BGP
session between PE routers has been already established and we are enabling VRFs
on customers routers. Refer to this overview chart and see how an information
about CE1_JUNs loopback interface propagates through the entire network to
CE2_JUN counterpart:
All pictures are clickable, to see the full sized pics choose open an image in a
separate tab option in your browser.

Steps 1-3
Step 1
CE1_JUN router has an export policy export_loopback configured which is used by
BGP to construct the BGP UPDATE message with lo0 prefix as NLRI.
Step 2
CE1_JUN sends a regular BGP UPDATE message to its eBGP peer PE1_ALU.

Step 3
PE1_ALU router receives this update via its interface toCE1 configured in vprn 20
context. PE1_ALU populates its VRF 20 with a route to 1.1.1.1/32 via 10.20.99.1.
Step 4
PE1_ALU router has an established MP-iBGP session with PE2_JUN so it takes a BGP
route from VRF 20 and automatically sends a MP-BGP UPDATE message to its peer.
Note, that ALU routers will send MP-BGP update automatically only for the
connected to VRF routes and the routes received via BGP. If we had OSPF between
CE1 and PE1, we would configure an export policy to propagate this update over MPBGP session.
Since PE1_ALU router wants to send an update for a VRFs route it should
construct a MP-BGP Update message which has a specific Path attribute
MP_REACH_NLRI to communicate routing information. And PE1_ALU will
transform the 1.1.1.1/32 IPv4 prefix to a VPN-IPv4 one.

Take a close look at this BGP message. See how PE1_ALU router added some
valuable additional information to correctly pass CE1_ALUs loopback address via
MP-BGP. First of all examine how NLRI has been transformed in MP-BGP: it now has a
route distinguisher which we configured for VRF 20 earlier, it has the IPv4 prefix
itself and it has the MPLS label (131068 value)!
PE1_ALU router allocated a VPN label which it associated with VRF 20. This label
tells PE1_ALU router that if it ever receives a data packet with this label it should

consult encapsulated with this label data with VRF 20! This way ingress PE routers
tell others what label should be used as a VPN label for a routes residing in
particular VRF.
There are two methods of allocating VPN labels:
per VRF. all routes originated from a single VRF will have the same VPN
label.Alcatel-Lucent routers default to this.
per VRF per next-hop. If a VRF has >1 CE interfaces, PE router will allocate different
labels for different CE interfaces inside one VRF. Juniper routers default to this.
And of course we see the Route Target 200:20 as a part of Extended Community
attribute.
Important things happened to the Next-Hop, not only Next-Hop looks now like VPNIPv4 route with Route Distinguisher value of 0:0 and without MPLS label, but NextHop IPv4 address has been changed to PE1_ALU system (loopback)
interface 10.10.10.1. This is how PE1 router tells PE2 that PE2 can reach VRF 20
routes via PE1.
All in all, PE1_ALUs update reaches PE2_JUN since it has the IP destination address
of10.10.10.3.
Notice, BGP updates traverse Service Providers network as simple IP packets, MPLS
is out of play at the moment. P1_ALU router simply routes IP packets and has no
knowledge about BGP at all.
Steps 5-7
Step 5
PE2_JUN receives the BGP UPDATE with VPN-IPv4 route. Once this route passes
validation checks (Nexhop resolvable, no AS Path loop) it places this route to a
specific table calledbgp.l3vpn.0 . This table stores all BGP VPN routes, refer to this
figure to examine some of its content:

PE2_JUN extracts routing information from this update an based on Route

Target value and installs an IPv4 route 1.1.1.1/32 into VRF 20 20.inet.0 . PE2_JUN
resolved next-hop address of the fellow PE1_ALU (10.10.10.1) via MPLS Label
Switched Path (LSP) and placed this information in the 20.inet.0 table:

Remember that it is mandatory to have an active LSP to the remote PE, since we
have to have MPLS transport to remote end.
Step 6
Since we installed route for the 1.1.1.1/32 IPv4 prefix into VRF 20 and we have an
active eBGP peer in VRF 20, we should send an update for this IPv4 prefix to
CE2_JUN router. This update goes as an ordinary eBGP update
Step 7
CE2_JUN receives BGP UPDATE and installs a route into the only table it has for IPv4
routes inet.0 .
This completes Control Plane operation regarding the prefix 1.1.1.1/32 , same
process goes for other loopbacks and connected to VRFs link addresses for both
Alcatel and Juniper customers.

DATA PLANE WALKTHROUGH

To complete this post we should see how data plane uses all the hard work control
plane did. We will see how data packets destined to 1.1.1.1 propagate through our
network.

Step 1
CE2_JUN wants to send a data packet to CE1_JUN via L3VPN service provided by our
network. CE2 has an active route in its route table inet.0 pointing to connected
address10.20.99.2 via ge-0/0/0(fig. 1.1). CE2 has data layer MAC address (fig. 1.2)
so it constructs the whole packet and puts it on the wire.

Step 2
PE2_JUN receives Ethernet frame on the interface ge-0/0/1 which belongs to VRF 20,
that is how PE2 decides to associate this packet to VRF 20. PE2 consults with VRF 20
routing table and sees that it has to use LSP toPE1 (fig. 2.1) to propagate incoming
data packet further. Then PE2 gets MPLS label which it received earlier from RSVP
neighbor P1_ALU (fig. 2.2) during LSP signalization process.
But this was just a transport MPLS label, it helps PE2_JUN to reach PE1_ALU, but PE2
needs one more VPN Label to tell PE1_ALU to which VRF it should put
encapsulated data. This label was signalled earlier (see Control Plane operation
section) via MP-BGP (fig. 2.3).
Now PE2 has everything it needs:
MPLS VPN label to encapsulate data packets from its VRF 20 destined to VRF 20 on
PE1_ALU
Transport MPLS Label to get to PE1_ALU via MPLS core
and thus it constructs a packet (fig. 2.4) with two labels stacked and fires it off.
Step 3
P1_ALU is totally unaware of the whole services and customers mess, it just
switches MPLS packets (fig. 3.1, 3.2) by replacing incoming transport label with
outcoming one.
Step 4
PE1_ALU receives an MPLS packet from P1_ALU. It pops out the transport label (fig.
4.1) and examines enclosed MPLS label. This label value 131068 was signalled by
PE1_ALU via MP-BGP during Control Plane operation. So PE1 knows that it has to pop
this label and associate enclosed packet with VPRN 20 (VRF 20) (fig. 4.2)

VRFs 20 routing table says that packets destined to 1.1.1.1 should be forwarded
to 10.20.99.3 address (fig. 4.3), which is a connected network leading to CE1_JUN
(fig. 4.4). PE1_ALU constructs the packet and moves it via Ethernet out of the 1/1/2
port (fig. 4.5).
Step 5
CE2_JUN receives an ordinary packet with a destination address matching its
interface. It decapsulates ICMP echo request and send back echo reply.