一个基本的 MPLS BGP VPN 配置

　　ip vrf vrf00001

　　rd 888:1

　　route-target both 888:1

　　ip vrf vrf00002

　　rd 888:2

　　route-target both 888:2

　　route-target import 888:1

　　import map vrf00002-import-map

　　route-map vrf00002-import-map permit 10

　　match ...

　　It is important to note that the route map is only needed for fine tuning. Normal import/export with VRFs can just extended communities. The thought of security depending on getting route maps built right rather scares me. Luckily, basic security is provided at the extended community level, making route hiding the normal situation. Then route maps can be used to limit connectivity to extranet partner sites, if the customers don't wish to do that for themselves by speaking BGP to the PE routers.

　　These VRFs would typically then be associated with interfaces:

　　interface Fastethernet 0/2

　　ip vrf forwarding vrf00001

　　ip address ...

　　interface Fastethernet 0/3

　　ip vrf forwarding vrf00002

　　ip address ...

　　interface Fastethernet 0/4

　　ip vrf forwarding vrf00002

　　ip address ...

　　VRF vrf00002 is associated with two interfaces that connect to two sites for Customer B. I'm deliberately showing FastEthernet, since some people now think that's how we'll be connecting to SPs in metropolitan settings. (Think BLEC: Building Local Exchange Carrier, providing VPN, Internet, and Voice connectivity).

　　We need to be speaking MBGP to carry VPN-IPv4 routes and attributes to peer PE routers. We don't need ordinary BGP routes to PE peers however. (On a larger scale, we might use route reflectors vice iMBGP full-mesh peering):

　　router bgp 888

　　no synchronization ! don't do IGP synchronization (since

　　! the IGP won't carry the right routes anyway)

　　no bgp default ipv4-activate ! don't do ordinary BGP

　　neighbor 10.60.0.5 remote-as 888 ! identify an iBGP neighbor and AS

　　neighbor 10.61.0.1 remote-as 888 ! identify another

　　address-family vpnv4 unicast

　　neighbor 10.60.0.5 activate ! activate session to some MBGP peer

　　neighbor 10.61.0.1 activate ! some other MBGP peer

　　exit-address-family

　　Our design might use eBGP to communicate routes to CE routers in a controlled way, to get routes into each VRF. Or it might use static routing, or some other mix. We can also define per-VRF static routes as shown below.

　　address-family ipv4 unicast vrf vrf00001

　　redistribute static

　　redistribute connected

　　neighbor 10.20.1.1 remote-as 65535 ! private AS number

　　neighbor 10.20.1.1 activate

　　no auto-summary

　　exit-address-family

　　address-family ipv4 unicast vrf vrf00002

　　redistribute static

　　redistribute connected

　　neighbor 10.20.2.2 remote-as 65535

　　neighbor 10.20.2.2 activate

　　no auto-summary

　　exit-address-family

　　ip route vrf vrf00001 15.0.0.0 255.0.0.0 e0/2 10.20.1.1