Internet Access

Example 7-41

239

Conguration of GRE Tunnel in Global Routing Space on the PE (Continued)

interface Ethernet0/1 /2
ip vrf for warding cus t-one
ip add ress 10.10. 2.2 255.255 .255.0
!
ip rout e 192.168.1 .0 255.255. 255.0 Tunnel1
london-ce#
!
interface T unnel1
ip addre ss 10.10.20 .2 255.255. 255.0
t u n n e l s o ur c e 1 0 . 1 0 . 2. 1
tunnel d estination 10.10.2.2
!
ip ro ute 0.0.0. 0 0.0.0.0 T unnel1

Internet Access Through the Global Routing Table with Static Routes
You can provide Internet access to the VPN customers by forwarding their trafc to the Internet
gateway of the service provider. The Internet gateway is known to all P routers in the MPLS VPN
network because the gateway IP address is known in the global routing table of the service
provider. It surely is running eBGP with a router of an Internet provider. The PE routers are already
running BGP, so they can provide MPLS VPN services. The PE routers can also run an iBGP
peering session for IPv4 to the Internet gateway router. To provide Internet access to a VRF, the
global routing table must forward the trafc. This occurs by creating a static route in the VRF table
on the PE router and specifying a next hop that is in the global routing table. To do this, use the
keyword global on the static VRF route. This ensures that trafc owing from the CE router to the
PE router via the VRF interface and being forwarded according to the static route is forwarded to
the next hop in the global routing table. This next-hop IP address should be on the Internet gateway
router. You need to forward to the VRF the trafc that is owing from the Internet. Conguring a
static route on the PE router and specifying the next hop to be the CE router accomplishes this. To
ensure that the Internet gateway knows about this route, distribute the static route into BGP or the
IGP of the service provider. Because the trafc is no longer VPN-to-VPN but is forwarded in the
global routing table, it has only one label in the MPLS VPN network.
Look at Example 7-42 for the conguration on the london PE router where the static route is
distributed into BGP. The Internet gateway router is 10.200.254.5, and 192.168.1.0/24 is the
subnet of the customer who needs Internet access. All trafc that has no specic route in the VRF
cust-one routing table is forwarded according to the default route in the VRF with the next-hop
10.200.254.5 in the global routing table. The trafc from the Internet toward the london-ce router

240

Chapter 7: MPLS VPN

is forwarded according to the static route for 192.168.1.0/24 pointing to the interface Ethernet 0/
1/2 on the PE router toward the CE router.
Example 7-42

Internet Access Through the Global Routing Table with Static Routes

london#
!
interface E thernet0/1 /2
ip vrf forw arding cus t-one
ip addr ess 10.10. 2.2 255.255 .255.0
!
router bgp 1
b gp log-nei ghbor-chang es
redistribut e static
neigh bor 10.200. 254.3 remo te-as 1
no auto-sum mary
!
ip route vrf cust-one 0 .0.0.0 0.0. 0.0 10.200.25 4.5 global
ip r oute 192.16 8.1.0 255. 255.255.0 E thernet0/1/2 10.10.2.1
!
show ip route 0.0.0.0 0.0. 0.0
london-ce#s
Routing entry for 0.0.0.0/0, supernet
Known via "rip", distance 120, metric 2, candidate default path
Redistributing via rip
Last update from 10.10.2.2 on Ethernet1/1, 00:00:14 ago
Routing Descriptor Blocks:
* 10.10.2.2, from 10.10.2.2, 00:00:14 ago, via Ethernet1/1
Route metric is 2, traffic share count is 1

Internet Access Through a Central VRF Site

Instead of trafc from each VPN site being forwarded directly to the Internet gateway router, it is
possible to forward all the Internet trafc from the VRF sites to the CE router(s) of a central VRF
site in a VPN. The advantage is that security featuressuch as rewall servicesor other
servicessuch as Network Address Translation (NAT)are implemented only once and centrally
in the central VRF site. The Internet trafc between the VRF sites and the VRF central site is then
forwarded across the regular VRF interfaces in the normal manner for MPLS VPN. Look at Figure
7-31 for the network in this scenario. This is most likely the preferred scenario for hub-and-spoke
VPN networks anyway. Note that at the central VRF site, you can deploy a rewall to verify all
Internet trafc.