Académique Documents
Professionnel Documents
Culture Documents
Terminology:
In the figure, imagine the red routers are connected with one VPN, and the blue ones with
another. (I tried to draw in some lines to suggest connectivity, but things rapidly got
rather cluttered). An extranet is where some red routers connect to some blue routers. The
red path with arrow shows traffic from the bottom red CE router to the top one. The first
(bottom) gray provider router is the entry PE router, and the final gray provider router is
the exit PE router (terms used below).
All that the entry PE routers need to do to packets is somehow deliver them to the
appropriate exit PE router, the next hop known via the mandatory MBGP next hop
attribute. But with MPLS and any IGP carrying routes to the PE routers, we will already
have an MPLS Label Switch Path (LSP) from the entry PE to each possible exit PE! And
that does it.
When a packet comes in, we look up the long (VPN) destination prefix in the MBGP
routing information base (RIB). That tells us the next hop router, the exit PE router. We
would normally look up how to get to that router in the IGP, and determine the IP next
hop. But this gets short-circuited by MPLS: we find we have a label available for an LSP
that delivers packets very efficiently to the MBGP next hop router, the exit PE router.
And (here's the clever part) if we use the LSP, the core routers in the core never have
to examine IP addresses or headers, they just use the labels to forward the packet!
So MPLS LSPs act as tunnels through the Service Provider core, meaning we can get
away with an IGP in the SP core, and thus the SP core routers can remain ignorant of the
many, many possible destinations for all subnets in all VPNs.
Route distinguisher 0 and VPN 0 can be regarded as the current Internet.
Note that smart Service Providers might build their AS number into the VPN route
distinguisher, as a way to provide uniqueness and allow cooperation in providing MPLSbased VPN services to their customers.
between corporate sites than connect to the same PE router). We'll see how to do this
below.
For an intranet, the VRF contains just the routes from that VPN.
Say we've done all this for Customer A. To connect a Company A site to a business
partner B, we import routes for the VPN from B (possibly filtering them, so that we can
only route to specified sites within B). So that business partner B can reach Customer A,
we also export routes to target community B (or the extended community number for B).
We can do this per-location within Customer B's network, providing very fine-grained
control over which Customer B sites can reach Customer A. Alternatively, we can use a
different VPN ID (route distinguisher and extended community) for the A-B extranet, and
then export routes to and import routes from this extranet VPN to the VRF's at the sites
that have to communicate with the business partner(s). Note how scalable and extensible
this is!
Subinterfaces can be used so that extranet traffic can be forced through a CE firewall or
so the CE can filter routes to control what internal sites the extranet partners can get to.
Since the Internet is just RD and extended community 0, the Service Provider can also
selectively connect customer sites to the Internet.
The above figure shows some sample VRFs associated with the interfaces on the PE
router at the left of the picture. These are suggestive of the situation for the configuration
that follows in the next section. The VRF named VRF00001 contains routes to other blue
VPN sites (subnets). The VRF named VRF00002 contains red VPN subnets, along with
an imported blue VPN subnet. A route map might have been used to provide the finegrained control over what blue subnets are imported into VRF00002. See below for
configuration details.