Hello all…wanted to share my version of a MPLS lab with
you....as if there's not enough MPLS material online! Well, here's one more! The base of the lab was configured with the guidance of Keith Barker, who
put up an excellent you tube video on MPLS-check it out here!
I just kind of elaborated on it a bit-added a second customer,
a third customer CE, and some GETVPN to get some traffic encryption going. Here’s
the config for PE-R2…… at the end of all this, I’ll make my GNS3 lab available
for those who want to download it.
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname PE-R2
!
boot-start-marker
boot-end-marker
!
!
vrf definition dtech
rd 120:120
!
address-family ipv4
route-target export 20:20
route-target import 30:30
route-target import 40:40
route-target import 137:137
exit-address-family
!
vrf definition isp
rd 137:137
!
address-family ipv4
import map DTECH_SELECT
route-target export 137:137
route-target import 21:21
route-target import 31:31
route-target import 20:20
route-target import 30:30
route-target import 40:40
exit-address-family
!
vrf definition pizza
rd 121:121
!
address-family ipv4
route-target export 21:21
route-target import 31:31
route-target import 137:137
exit-address-family
!
no aaa new-model
no ip domain lookup
ip domain name lab.local
ip cef
no ipv6 cef
!
!
multilink bundle-name authenticated
!
interface Loopback0
ip address 2.2.2.2
255.255.255.255
!
interface FastEthernet0/0
ip address 10.0.23.2
255.255.255.0
speed auto
duplex auto
mpls ip
!
interface FastEthernet0/1
ip address 10.0.24.2
255.255.255.0
speed auto
duplex auto
mpls ip
!
interface FastEthernet1/0
vrf forwarding dtech
ip address 172.16.12.2
255.255.255.0
speed auto
duplex auto
!
interface FastEthernet1/1
vrf forwarding pizza
ip address 172.16.29.2
255.255.255.0
speed auto
duplex auto
!
router ospf 2 vrf pizza
router-id 0.0.29.29
redistribute bgp 27 subnets
network 172.16.29.0 0.0.0.255
area 0
default-information originate
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 10.0.0.0 0.0.255.255
area 0
!
router rip
!
address-family ipv4 vrf dtech
redistribute bgp 27 metric 2
network 172.16.0.0
no auto-summary
version 2
exit-address-family
!
router bgp 27
bgp log-neighbor-changes
neighbor 7.7.7.7 remote-as 27
neighbor 7.7.7.7 update-source
Loopback0
neighbor 11.11.11.11 remote-as
27
neighbor 11.11.11.11
update-source Loopback0
!
address-family vpnv4
neighbor 7.7.7.7 activate
neighbor 7.7.7.7
send-community extended
neighbor 11.11.11.11 activate
neighbor 11.11.11.11
send-community extended
exit-address-family
!
address-family ipv4 vrf dtech
redistribute rip
exit-address-family
!
address-family ipv4 vrf pizza
redistribute ospf 2
exit-address-family
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
!
!
ip prefix-list DTECH_LOOPS seq 5 permit 1.1.1.1/32
ip prefix-list DTECH_LOOPS seq 10 permit 8.8.8.8/32
ip prefix-list DTECH_LOOPS seq 15 permit 12.12.12.12/32
!
route-map DTECH_SELECT deny 10
match ip address prefix-list
DTECH_LOOPS
!
route-map DTECH_SELECT permit 20
|
Define your customer VRF and assign a unique Route Distinguisher
value in order to keep possible overlapping customer routes unique when
traversing MP-BGP.
Define which routes in the customer’s VRF you want to share with
other VRFs route-targets. Most times you can just assign the same value for
import and export, since you would normally want to share all routes among
the same customer vrf, but I just wanted to make them unique for each vrf
instance. One for each PE.
For the ISP vrf, I used a route map import so that only select routes
were imported in, and others denied. Using the route-target values is all or
nothing. Import and export maps will give you more control. In this case, the
ISP vrf is importing all other vrf routes, with the exception of dtech, and are
modified via the import map command. See at the bottom of the config…
Enable mpls for the interfaces connecting your core routers
This would be your customer facing interface- you’ll want to place
this interface in the vrf for your customer. This interface will also
exchange routes with the CE’s local routing protocol.
This customer (pizza) uses OSPF as their IGP at the CE. This OSPF
instance is placed in the customer vrf and MP-BGP is redistributed into it-
which is carrying the injected routes through the MPLS core from the other
customer VRFs\PE interface. Note the use of “default-information originate”
here. This is necessary to distribute a default route to the CE via OSPF. The
route is originated on PE-R7 in the isp vrf, and distributed via MP-BGP like
the rest of the routes.
OSPF 1 servers as the core IGP for the MPLS backbone
This customer (dtech) uses RIPv2 as their IGP at the CE. This rip
instance is placed in the customer vrf and MP-BGP is redistributed into it-
which is carrying the injected routes through the MPLS core from the other
customer VRFs\PE interfaces
Here we are defining the BGP pairings for our PE routers that define
the MPLS backbone. I did a full mesh between the 3. Also using the loopback0
as the update source instead of the physical interface for redundancy.
It’s here, in the vpnv4 address family, where you are activating the
PE BGP neighbors to send vpnv4 customer prefixes which are made globally
unique by use of the Route Distinguisher defined earlier. Also, it is the
enabling of the extended send-communities in MP-BGP that carry the RD and RT
information needed for MPLS vpns to work.
Next, we redistribute the CE’s local IGP into BGP within the respective
customer vrfs
Here’s the prefix used in the above import map. I didn't want the isp
vrf to show the dtech loopback networks (lets pretend these were top
secret networks). So the loopbacks are defined in the prefix list here, then
denied in the DTECH_SELECT route map, effectively preventing them from
importation on the to the isp network. Notice the unmatched permit statement at
the end of the route map…basically saying “leave everything else as is”
|
Now, take a look at PE-R7…I’ll go over the differences from
PE-R2- it’s all configured the same except for these exceptions.
When your CE’s are using EIGRP as there local routing IGP,
you can just create a single EIGRP AS instance on the PE (AS 7 in this case)-
then, under your address-family commands, reference the CE’s local EIGRP AS number….
(8, 10, 13 respectively)- then you’ll redistribute BGP into those AS’s so that
your customers get the routes.
router eigrp 7
!
address-family
ipv4 vrf dtech
redistribute bgp
27 metric 1 1 1 1 1
network 0.0.0.0
autonomous-system
8
exit-address-family
!
address-family
ipv4 vrf pizza
redistribute bgp
27 metric 1 1 1 1 1
network 0.0.0.0
autonomous-system
10
exit-address-family
!
address-family
ipv4 vrf isp
redistribute bgp
27 metric 1 1 1 1 1
network 0.0.0.0
autonomous-system
13
exit-address-family
Now, there’s a default static route on PE-R7 pointing to
the ISP router. I have this route shared among all the vrfs, so that any
traffic wo specific routes heads out towards the internet. I distributed this route
via the MPLS network to the CEs.
ip route vrf isp 0.0.0.0 0.0.0.0 137.137.137.13
router bgp 27
address-family ipv4 vrf isp
redistribute
static
default-information originate
exit-address-family
You’ll want to redistribute static routes into BGP for the isp vrf as shown above- you’ll also need default-information originate so that’s
it’s distributed via MP-BGP and shows up in the ipv4 tables for all the vrfs on
all the Pes. I’m also peering with the ISP routers local EIGRP as show above on
this PE-R7…..other than that, it’s the same as PE-2
The CE routers are just straight peering with their respective IGPs (no redistribution done at the CEs)- advertise the networks you want (I advertised all the CE loopbacks- ie R1 loopback is 1.1.1.1/32) and you should be good to go. You should see the routes for your respective customer offices on the CE (show ip route).
To check the that you have the correct BGP routes on your PE routers, use show ip bgp all - you'll get a table for each vrf under the VPNv4 address family. (see below) Note the default route in each vrf
The CE routers are just straight peering with their respective IGPs (no redistribution done at the CEs)- advertise the networks you want (I advertised all the CE loopbacks- ie R1 loopback is 1.1.1.1/32) and you should be good to go. You should see the routes for your respective customer offices on the CE (show ip route).
To check the that you have the correct BGP routes on your PE routers, use show ip bgp all - you'll get a table for each vrf under the VPNv4 address family. (see below) Note the default route in each vrf
Now, you have a functioning MPLS network serving 2 customers!
Pretty cool! But….dtech is worried about the security of their traffic between
office locations. Pizza doesn’t care- they’re busy making pizzas! So, I’ll
implement GETVPN over MPLS to encrypt the interoffice traffic for DTech in the
next section. And I'll upload the lab files as well....... until then....thanks for reading.
Update: 3-2015.............................................................................................................................
Actually....I went through the GETVPN config on another lab.....combining it with DMVPN....so if interested, you can head there and take a look. http://techjuice.blogspot.com/2015/03/dmvpn-w-getvpn-for-encryption.html
Update: 3-2015.............................................................................................................................
Actually....I went through the GETVPN config on another lab.....combining it with DMVPN....so if interested, you can head there and take a look. http://techjuice.blogspot.com/2015/03/dmvpn-w-getvpn-for-encryption.html
Update: 1-2024...............................................................................................................................
Added new Cisco Modeling Labs version of the lab (Less the GET-VPN part) Download Lab
No comments:
Post a Comment