Gns3 Mpls and BGP Lab
Gns3 Mpls and BGP Lab
Table of Contents
Overview ....................................................................................................................................................... 2
Topology ................................................................................................................................................... 2
Requirements................................................................................................................................................ 2
Internet ..................................................................................................................................................... 2
Clients........................................................................................................................................................ 2
MPLS ......................................................................................................................................................... 3
IP Table...................................................................................................................................................... 3
MPLS and BGP Lab Guide, Part 1 .................................................................................................................. 5
Internet1 ................................................................................................................................................... 5
Internet2 ................................................................................................................................................... 6
MPLS and BGP Lab Guide, Part 2 .................................................................................................................. 7
MPLS-P ...................................................................................................................................................... 7
MPLS-PE1 .................................................................................................................................................. 8
MPLS-PE2 .................................................................................................................................................. 9
MPLS and BGP Lab Guide, Part 3 ................................................................................................................ 10
London-I .................................................................................................................................................. 10
Paris-I ...................................................................................................................................................... 12
MPLS and BGP Lab Guide, Part 4 ................................................................................................................ 13
NewYork-I................................................................................................................................................ 13
MPLS and BGP Lab Guide, Part 5 ................................................................................................................ 15
MPLS-PE1 ................................................................................................................................................ 15
MPLS-PE2 ................................................................................................................................................ 17
MPLS and BGP Lab Guide, Part 6 ................................................................................................................ 19
London-M................................................................................................................................................ 19
NewYork-M ............................................................................................................................................. 20
Paris-M .................................................................................................................................................... 21
Chicago-M ............................................................................................................................................... 21
http://freeciscolab.com | Overview 1
GNS3 MPLS and BGP Lab
Overview
This lab was created from a lab I found on one of the network forms. I found it very educational and
thought I should share it as it is great practice for MPLS VPNs and BGP along with some network
technologies such as OSPF, NAT, IPSEC and GRE.
Topology
Requirements
Internet
* The two Internet routers should serve as transit AS’s. No other routers should permit transit traffic.
* Internet sites (modeled by loopbacks) should be accessible by all Lan IP’s.
Clients
* London, Paris, and New York have Internet connections to their respective ISP’s. New York is dual-
homed.
http://freeciscolab.com | Overview 2
GNS3 MPLS and BGP Lab
* London, Paris, New York, and Chicago all have MPLS connections to the same provider. New York and
Chicago constitute one company, while London and Paris constitute another. Their routes should not
mix over MPLS.
* London, Paris, and New York each have datacenters with a DMZ that should be publicly accessible.
* London, Paris, New York, and Chicago each have 2 LANs which should not be accessible from the
Internet, though they should be able to access the Internet.
* London and Paris have a GRE over IPSEC connection between them that should take over routing
between their LANs in case the MPLS connection fails. Additionally, the MPLS connection should take
over for DMZ sites if the Internet connection should fail.
MPLS
* The MPLS-P router should be the only one in area 0. It should be an ABR connection MPLS-PE1 (a stub
area 1) and MPLS-PE2 (a stub area 2).
* Area 1 and Area 2 should be summarized to /24′s before being injected into the OSPF backbone.
* The PE routers should communicate via BGP to the CE routers.
IP Table
General Guidelines
10.0.0.0/8 is subnetted for use as Internet IP's, considered "public".
192.168.0.0/16 is used for LANs and Private IP's, considered "private"
172.16.0.0/16 is used for MPLS, considered "public"
Router: Internet 1
Interface Description IP
Lo0 Simulated Internet Network 10.128.0.1/16
Fa0/0 Connection to Internet2 10.0.0.1/30
S1/0 Connection to London 10.1.0.1/30
S1/1 Connection to New York 10.1.1.1/30
Router: Internet 2
Interface Description IP
Lo0 Simulated Internet Network 10.129.0.1/16
Fa0/0 Connection to Internet2 10.0.0.2/30
S1/0 Connection to New York 10.2.0.1/30
S1/1 Connection to Paris 10.2.1.1/30
Router: London-I
Interface Description IP
Lo0 Simulated DMZ 10.192.0.1/24
Fa0/0 Connection to London-M 192.168.0.1/24
S1/0 Connection to Internet1 10.1.0.2/30
Tu1 IPSEC/GRE Connection to Paris-I 192.168.254.1/30
Router: NewYork-I
Interface Description IP
http://freeciscolab.com | Requirements 3
GNS3 MPLS and BGP Lab
Router:
Paris-I
Interface Description IP
Lo0 Simulated DMZ 10.192.2.1/24
Fa0/0 Connection to Paris-M 192.168.2.1/24
S1/0 Connection to Internet2 10.2.1.2/30
IPSEC/GRE Connection to
Tu1 London-I 192.168.254.2/30
Router: London-M
Interface Description IP
Lo0 Simulated Private LAN 192.168.1.1/24
Fa0/0 Connection to London-I 192.168.0.254/24
S1/0 Connection to MPLS-PE1 172.16.1.2/30
Router: NewYork-M
Interface Description IP
Lo0 Simulated LAN 192.168.1.1/24
Fa0/0 Connection to NewYork-I 192.168.0.254/24
S1/0 Connection to MPLS-PE1 172.16.1.6/30
Router: Paris-M
Interface Description IP
Lo0 Simulated LAN 192.168.4.1/24
Fa0/0 Connection to Paris-I 192.168.2.254/24
S1/0 Connection to MPLS-PE2 172.16.2.2/30
Router: Chicago-M
Interface Description IP
Lo0 Simulated LAN 192.168.5.1/24
S1/0 Connection to MPLS-PE2 172.16.2.6/30
Router: MPLS-PE1
Interface Description IP
Lo0 RID 172.16.255.1/32
S1/0 Connection to MPLS-P 172.16.0.2/30
S1/1 Connection to London-M 172.16.1.1/30
S1/2 Connection to NewYork-M 172.16.1.5/30
http://freeciscolab.com | Requirements 4
GNS3 MPLS and BGP Lab
Router: MPLS-PE2
Interface Description IP
Lo0 RID 172.16.255.2/32
S1/0 Connection to MPLS-P 172.16.0.6/30
S1/1 Connection to Paris-M 172.16.2.1/30
S1/2 Connection to Chicago-M 172.16.2.5/30
Router: MPLS-P
Interface Description IP
Lo0 RID 172.16.255.0/32
S1/0 Connection to MPLS-PE1 172.16.0.1/30
S1/1 Connection to MPLS-PE2 172.16.0.5/30
Internet1
hostname Internet1
!
interface Loopback0
ip address 10.128.0.1 255.255.0.0
!
interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.252
description TO_INTERNET2
!
interface Serial1/0
ip address 10.1.0.1 255.255.255.252
description TO_LONDON
!
interface Serial1/1
ip address 10.1.1.1 255.255.255.252
description TO_NY
!
router bgp 64512
no synchronization
bgp log-neighbor-changes
network 10.128.0.0 mask 255.255.0.0
Internet2
hostname Internet2
!
interface Loopback0
ip address 10.129.0.1 255.255.0.0
!
interface FastEthernet0/0
ip address 10.0.0.2 255.255.255.252
description TO_INTERNET1
!
interface Serial1/0
ip address 10.2.0.1 255.255.255.252
description TO_NY
!
interface Serial1/1
ip address 10.2.1.1 255.255.255.252
description TO_PARIS
!
router bgp 64513
no synchronization
bgp log-neighbor-changes
network 10.129.0.0 mask 255.255.0.0
neighbor 10.0.0.1 remote-as 64512
neighbor 10.2.0.2 remote-as 65001
neighbor 10.2.1.2 remote-as 65002
no auto-summary
So first we set the appropriate IPs. I’ve also given the interfaces descriptions which will make it easier to
troubleshoot issues that we run in to. The meat here is the BGP configuration, which is pretty basic. We
turn off synchronization and auto-summary, which is standard. Then we configure our neighbors. Going
back to the stipulation that no other autonomous systems should be used as transits, we could add
some extra configuration here to protect against that:
We would configure an as-path ACL that matches ONLY the connected neighbor’s AS, then we configure
a route-map to match this ACL and apply it to the BGP neighbor coming IN. Here’s what the
configuration would look like on Internet1:
MPLS-P
hostname MPLS-P
!
ip cef
!
interface Loopback0
ip address 172.16.255.0 255.255.255.255
!
interface Serial1/0
description Connection to MPLS-PE1
ip address 172.16.0.1 255.255.255.252
mpls ip
!
interface Serial1/1
description Connection to MPLS-PE2
ip address 172.16.0.5 255.255.255.252
mpls ip
!
!
router ospf 100
log-adjacency-changes
area 1 stub
area 2 stub
network 172.16.0.0 0.0.0.3 area 1
network 172.16.0.4 0.0.0.3 area 2
network 172.16.255.0 0.0.0.0 area 0
summary-address 172.16.0.0 255.255.255.0
!
mpls ldp router-id Loopback0
!
First we have completed the configuration for the MPLS-P router. This is the core of the MPLS cloud.
This router does not run BGP like the MPLS-PEs, just OSPF and MPLS. We have assigned IPs to the
interfaces, and we have entered the “mpls ip” command. We have statically configured the LDP
neighbor ID as well. This command enables LDP on those interfaces. We have also OSPF Areas 1 and 2 as
stubs, along with the summary address as the requirements stated.
MPLS-PE1
hostname MPLS-PE1
!
ip cef
!
interface Loopback0
ip address 172.16.255.1 255.255.255.255
!
interface Serial1/0
description Connection to MPLS-P
ip address 172.16.0.2 255.255.255.252
mpls ip
!
interface Serial1/1
description Connection to London-M
ip address 172.16.1.1 255.255.255.252
!
interface Serial1/2
description Connection to NewYork-M
ip address 172.16.1.5 255.255.255.252
!
router ospf 100
log-adjacency-changes
area 1 stub
MPLS-PE2
hostname MPLS-PE2
!
ip cef
!
interface Loopback0
ip address 172.16.255.2 255.255.255.255
!
interface Serial1/0
description Connection to MPLS-P
ip address 172.16.0.6 255.255.255.252
mpls ip
!
interface Serial1/1
description Connection to Paris-M
ip address 172.16.2.1 255.255.255.252
!
interface Serial1/2
description Connection to Chicago-M
ip address 172.16.2.5 255.255.255.252
!
router ospf 100
log-adjacency-changes
area 2 stub
network 172.16.0.4 0.0.0.3 area 2
network 172.16.255.2 0.0.0.0 area 2
summary-address 172.16.0.0 255.255.255.0
!
mpls ldp router-id Loopback0
The PE routers get mostly the same configuration (for now). Now we’ll verify that OSPF and MPLS are
working:
Up time: 00:21:01
LDP discovery sources:
Serial1/1, Src IP addr: 172.16.0.6
Addresses bound to peer LDP Ident:
172.16.0.6 172.16.255.2
Peer LDP Ident: 172.16.255.1:0; Local LDP Ident 172.16.255.0:0
TCP connection: 172.16.255.1.61758 - 172.16.255.0.646
State: Oper; Msgs sent/rcvd: 32/32; Downstream
Up time: 00:20:37
LDP discovery sources:
Serial1/0, Src IP addr: 172.16.0.2
Addresses bound to peer LDP Ident:
172.16.0.2 172.16.255.1
We see that LDP is running on our two interfaces, our LDP neighbors are up and we have two labeled
prefixes.
London-I
hostname London-I
!
interface Loopback0
ip address 10.192.0.1 255.255.255.0
!
interface FastEthernet0/0
description Connection to London-M
ip address 192.168.0.1 255.255.255.0
ip nat inside
!
interface Serial1/0
description Connection to Internet1
ip address 10.1.0.2 255.255.255.252
ip nat outside
!
interface Tunnel1
ip address 192.168.254.1 255.255.255.252
tunnel source Serial1/0
tunnel destination 10.2.1.2
!
router bgp 65000
no synchronization
bgp log-neighbor-changes
network 10.1.0.0 mask 255.255.255.252
network 10.192.0.0 mask 255.255.255.0
network 192.168.254.0 mask 255.255.255.252
neighbor 10.1.0.1 remote-as 64512
neighbor 10.1.0.1 weight 4000
neighbor 10.1.0.1 route-map INET_OUT out
neighbor 192.168.0.254 remote-as 65000
neighbor 192.168.0.254 next-hop-self
neighbor 192.168.0.254 weight 2000
neighbor 192.168.254.2 remote-as 65002
no auto-summary
!
ip as-path access-list 10 permit ^$
!
ip nat inside source list NAT interface Serial1/0 overload
!
ip access-list standard LAN_IP
deny 192.168.254.0 0.0.0.3
deny 192.168.1.0 0.0.0.255
deny 192.168.4.0 0.0.0.255
permit any
!
ip access-list standard NAT
permit 192.168.1.0 0.0.0.255
permit 192.168.4.0 0.0.0.255
!
route-map INET_OUT permit 10
match ip address LAN_IP
match as-path 10
This is a ton of configuration. First we have configured the interfaces with IPs and NAT. We are NATing
our LAN IPs to give them access to the internet. We also have the Tunnel interface configured with S1/0
as the source and Paris-I’s S1/0 as the destination.
Next we have the BGP configuration; we disable synchronization and auto-summarization. We bring up
our neighbors; we have 10.1.0.1, which is Internet1. Weight is configured for this neighbor so it is
preferred and we do not get recursive route issues with BGP. We have a route-map out to Internet1.
This route-map is filtering out the LAN IPs, as well as our Tunnel subnet, it is also only allowing routes
from our local AS out. We also have 192.168.0.254, which is our iBGP relationship with London-M, we
have changed the next hop for our routing updates to London-M, this router. The 192.168.0.254 also
has weight applied to it so the WAN is preferred over the tunnel.
Paris-I
hostname Paris-I
!
interface Tunnel1
ip address 192.168.254.2 255.255.255.252
tunnel source Serial1/0
tunnel destination 10.1.0.2
!
interface Loopback0
ip address 10.192.2.1 255.255.255.0
!
interface FastEthernet0/0
description Connection to Paris-M
ip address 192.168.2.1 255.255.255.0
ip nat inside
duplex auto
speed auto
!
interface Serial1/0
description Connection to Internet2
ip address 10.2.1.2 255.255.255.252
ip nat outside
!
router bgp 65002
no synchronization
bgp log-neighbor-changes
network 10.2.1.0 mask 255.255.255.252
network 10.192.2.0 mask 255.255.255.0
network 192.168.254.0 mask 255.255.255.252
neighbor 10.2.1.1 remote-as 64513
neighbor 10.2.1.1 weight 4000
neighbor 10.2.1.1 route-map INET_OUT out
neighbor 192.168.2.254 remote-as 65002
neighbor 192.168.2.254 next-hop-self
neighbor 192.168.2.254 weight 2000
neighbor 192.168.254.1 remote-as 65000
no auto-summary
!
ip as-path access-list 10 permit ^$
!
ip access-list standard LAN_IP
deny 192.168.254.0 0.0.0.3
deny 192.168.1.0 0.0.0.255
deny 192.168.4.0 0.0.0.255
permit any
!
ip access-list standard NAT
This is essentially a mirror of the London configuration, so it shouldn’t require any explanation.
A couple notes, some of the configuration here are not best practice, it simply accomplishing the goal
(like the weight configuration, normally I would do that with a route-map instead of a blanket neighbor
statement). Also, as I am sure you have noticed, I did not do the crypto configuration for the tunnel.
NewYork-I
hostname NewYork-I
!
interface FastEthernet0/0
description Connection to NewYork-M
ip address 192.168.0.1 255.255.255.0
ip nat inside
!
interface Serial1/0
description Connection to Internet1
ip address 10.1.1.2 255.255.255.252
ip nat outside
!
interface Serial1/1
description Connection to Internet2
ip address 10.2.0.2 255.255.255.252
ip nat outside
!
ip nat inside source route-map NAT_0 interface Serial1/0 overload
ip nat inside source route-map NAT_1 interface Serial1/1 overload
!
ip access-list standard LAN_IP
deny 192.168.1.0 0.0.0.255
deny 192.168.5.0 0.0.0.255
permit any
!
ip access-list standard NAT
permit 192.168.1.0 0.0.0.255
permit 192.168.5.0 0.0.0.255
!
route-map NAT_0 permit 10
match ip address NAT
match interface Serial1/0
!
route-map NAT_1 permit 10
match ip address NAT
match interface Serial1/1
First we do the standard IPs and NAT inside and outside. In this situation we have two internet
connections, and we want to use both. We are load balancing across our connections. In our NAT
configuration we’re using route-maps instead of a simple ACL. This is needed for the load balancing. Our
NAT_0 route-map is matching the addresses we want to NAT, and matching the interface appropriately.
Next we’ll go through the BGP configuration:
We are dual homed here, so we need to prevent this AS from becoming a transit. We do this with our
as-path ACL and route-map. The ACL forwards only our local AS; this is done by matching a blank AS
path, which is what the router sees for local prefixes. We then configure a route-map to filter out the
LAN IPs as we do not want those advertised to the internet; we also match our as-path ACL in the route-
map. The rest of the BGP configuration is pretty standard, we configure our neighbors and we set our
route-maps OUT on the Internet1 and Internet2 neighbors. Let’s verify everything with some show
commands:
We can ping the internet from our LAN subnet on Chicago-M, so we know NAT is working properly.
We see only our DMZ on the internet routers, which is what we want.
MPLS-PE1
hostname MPLS-PE1
!
ip vrf 1
rd 100:110
route-target export 100:1000
route-target import 100:1000
!
ip vrf 2
rd 100:120
route-target export 100:2000
route-target import 100:2000
!
interface Loopback0
ip address 172.16.255.1 255.255.255.255
!
interface Serial1/0
description Connection to MPLS-P
ip address 172.16.0.2 255.255.255.252
mpls ip
!
interface Serial1/1
description Connection to London-M
ip vrf forwarding 1
ip address 172.16.1.1 255.255.255.252
!
interface Serial1/2
description Connection to NewYork-M
ip vrf forwarding 2
ip address 172.16.1.5 255.255.255.252
!
router ospf 100
log-adjacency-changes
area 1 stub
summary-address 172.16.0.0 255.255.255.0
network 172.16.0.0 0.0.0.3 area 1
network 172.16.255.1 0.0.0.0 area 1
!
router bgp 65535
no synchronization
bgp log-neighbor-changes
neighbor 172.16.255.2 remote-as 65535
neighbor 172.16.255.2 update-source Loopback0
neighbor 172.16.255.2 next-hop-self
no auto-summary
!
address-family vpnv4
neighbor 172.16.255.2 activate
neighbor 172.16.255.2 send-community both
exit-address-family
!
address-family ipv4 vrf 2
redistribute connected
neighbor 172.16.1.6 remote-as 65001
neighbor 172.16.1.6 activate
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf 1
redistribute connected
neighbor 172.16.1.2 remote-as 65000
neighbor 172.16.1.2 activate
no auto-summary
no synchronization
exit-address-family
!
mpls ldp router-id Loopback0
This is a lot of configuration. We have our normal interface/IP and OSPF configs, notice “mpls ip” under
S1/0, this turns on LDP between the PE and P routers. S1/1 and S1/2 have the “ip vrf forwarding”
command, which specifies the VRF associated with that interface. We also have our VRF configuration.
“RD” is route distinguisher, which is added to the routing updates so they are unique even if the same
addressing is being used. The “route-target” command says which routers to bring into the VRF, as well
as which routes to send out of the VRF.
Now we look at the mammoth BGP configuration. It looks normal up until the “address-family vpnv4″,
this tells the router to send pass the VRF information to the neighbors we specify. Then we have two
“address-family ipv4 vrf” commands, these are almost separate BGP instances. They are still under the
main process, but they produce completely separate RIBs. The routes learned from these neighbors will
not show up in the global routing table (by default). In the VRFs we are using the “redistribute
connected” command to advertise our links. PE2′s configuration is basically the same:
MPLS-PE2
hostname MPLS-PE2
!
ip vrf 1
rd 100:110
route-target export 100:1000
route-target import 100:1000
!
ip vrf 2
rd 100:120
route-target export 100:2000
route-target import 100:2000
!
interface Loopback0
ip address 172.16.255.2 255.255.255.255
!
interface Serial1/0
description Connection to MPLS-P
ip address 172.16.0.6 255.255.255.252
mpls ip
serial restart-delay 0
!
interface Serial1/1
description Connection to Paris-M
ip vrf forwarding 1
ip address 172.16.2.1 255.255.255.252
!
interface Serial1/2
description Connection to Chicago-M
ip vrf forwarding 2
ip address 172.16.2.5 255.255.255.252
!
router ospf 100
log-adjacency-changes
area 2 stub
summary-address 172.16.0.0 255.255.255.0
network 172.16.0.4 0.0.0.3 area 2
network 172.16.255.2 0.0.0.0 area 2
!
router bgp 65535
no synchronization
bgp log-neighbor-changes
neighbor 172.16.255.1 remote-as 65535
neighbor 172.16.255.1 update-source Loopback0
neighbor 172.16.255.1 next-hop-self
no auto-summary
!
address-family vpnv4
neighbor 172.16.255.1 activate
neighbor 172.16.255.1 send-community both
exit-address-family
!
address-family ipv4 vrf 2
redistribute connected
neighbor 172.16.2.6 remote-as 65003
neighbor 172.16.2.6 activate
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf 1
redistribute connected
neighbor 172.16.2.2 remote-as 65002
neighbor 172.16.2.2 activate
no auto-summary
no synchronization
exit-address-family
!
mpls ldp router-id Loopback0
Here we see two different VRFs, both with different routing information. Our configuration has worked.
Let’s try a ping:
London-M
hostname London-M
!
interface Loopback0
ip address 192.168.1.1 255.255.255.0
!
interface FastEthernet0/0
description Connection to London-I
ip address 192.168.0.254 255.255.255.0
!
interface Serial1/0
description Connection to MPLS-PE1
ip address 172.16.1.2 255.255.255.252
!
router bgp 65000
no synchronization
bgp log-neighbor-changes
network 192.168.1.0
neighbor 172.16.1.1 remote-as 65535
neighbor 192.168.0.1 remote-as 65000
neighbor 192.168.0.1 next-hop-self
no auto-summary
We have the Loopback configured to simulate the LAN, then we have interfaces connecting to London-I
and MPLS-PE1. Our BGP configuration is not complex, we have two neighbors, one internal and one
external, and we’re advertising our LAN.
NewYork-M
hostname NewYork-M
!
interface Loopback0
ip address 192.168.1.1 255.255.255.0
!
interface FastEthernet0/0
description Conection to NewYork-I
ip address 192.168.0.254 255.255.255.0
!
interface Serial1/0
description Connection to MPLS-PE1
ip address 172.16.1.6 255.255.255.252
!
router bgp 65001
no synchronization
bgp log-neighbor-changes
network 192.168.1.0
neighbor 172.16.1.5 remote-as 65535
neighbor 192.168.0.1 remote-as 65001
neighbor 192.168.0.1 next-hop-self
no auto-summary
Paris-M
hostname Paris-M
!
interface Loopback0
ip address 192.168.4.1 255.255.255.0
!
interface FastEthernet0/0
description Connection to Paris-I
ip address 192.168.2.254 255.255.255.0
!
interface Serial1/0
description Connection to MPLS-PE2
ip address 172.16.2.2 255.255.255.252
!
router bgp 65002
no synchronization
bgp log-neighbor-changes
network 192.168.4.0
neighbor 172.16.2.1 remote-as 65535
neighbor 192.168.2.1 remote-as 65002
neighbor 192.168.2.1 next-hop-self
no auto-summary
Chicago-M
hostname Chicago-M
!
interface Loopback0
ip address 192.168.5.1 255.255.255.0
!
interface Serial1/0
description Connection to MPLS-PE2
ip address 172.16.2.6 255.255.255.252
!
router bgp 65003
no synchronization
bgp log-neighbor-changes
network 192.168.5.0
neighbor 172.16.2.5 remote-as 65535
no auto-summary
The rest of the M routers are configured similarly, so I won’t redundantly explain everything. Let’s test
things:
Chicago-M#sh ip route
...
172.16.0.0/30 is subnetted, 2 subnets
B 172.16.1.4 [20/0] via 172.16.2.5, 00:55:17
C 172.16.2.4 is directly connected, Serial1/0
http://freeciscolab.com | MPLS and BGP Lab Guide, Part 6 21
GNS3 MPLS and BGP Lab
Chicago-M#ping 10.192.1.1
Here we see that Chicago-M can ping the internet from its LAN interface, and it can communicate with
the DMZ on New York-I.