CONTROL PLANE WALKTHROUGH
We are done with configuration, all in all it was not a complex task, what is more important is an understanding what’s 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_JUN’s 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
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 MP-BGP session.
Since PE1_ALU router wants to send an update for a VRF’s 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_ALU’s 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 VPN-IPv4 route with Route Distinguisher value of 0:0 and without MPLS label, but Next-Hop 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_ALU’s update reaches PE2_JUN since it has the IP destination address of10.10.10.3.
Notice, BGP updates traverse Service Provider’s 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)
VRF’s 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.
