MPLS and BGP Lab Guide, Part 1

This is the first post in the series, the goal of the series is to provide a guide for the MPLS and BGP Lab I posted awhile back. The labs consists of MPLS VPNs and BGP along with some OSPF, NAT, IPSEC and GRE exposure. I will be posting the files needed for this lab at the bottom. Here’s the topology and the requirements:

(click image for fullsize)

Requirements:
Internet
* The two Internet routers should serve as transit ASes. No other routers should permit transit traffic.
* Internet sites (modeled by loopbacks) should be accessible by all lan IPs.

Clients
* London, Paris, and New York have Internet connections to their respective ISPs. New York is dual-homed.
* 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 data centers 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.

Today we will go over the Internet requirements. First we see that BGP will be needed on both Internet routers. The stipulation also states that these should be the only transits ASes, which foreshadows some work we will be doing later. The requirements also say that all the simulated Internet sites need to be accessible by the LAN devices, which will be a concern for later as well. For now we will configure the two routers with IPs and BGP:

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 neighbor 10.0.0.2 remote-as 64513 neighbor 10.1.0.2 remote-as 65000 neighbor 10.1.1.2 remote-as 65001 no auto-summary

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 ASes should be used as transits, we could add some extra config 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 config would look like on Internet1:

ip as-path access-list 20 permit ^65000$ ! route-map NY_IN permit 10 match as-path 20 ! router bgp 64512 neighbor 10.1.0.2 remote-as 65000 neighbor 10.1.0.2 route-map NY_IN in

When I completed this lab I decided to be lazy and only do the filtering on the the client side as opposed to doing both client and provider. It seemed worth mentioning here though.

Now for some show commands to verify our work:

Internet1#sh ip bgp summ BGP router identifier 10.128.0.1, local AS number 64512 BGP table version is 3, main routing table version 3 2 network entries using 234 bytes of memory 2 path entries using 104 bytes of memory ... BGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secs   Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.0.0.2 4 64513 31 31 3 0 0 00:26:46 1 10.1.0.2 4 65000 2 2 0 0 0 00:00:17 0 10.1.1.2 4 65001 2 6 3 0 0 00:00:27 0 --------------------------------------------------------------------------------- Internet1#sh ip bgp BGP table version is 6, local router ID is 10.128.0.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete   Network Next Hop Metric LocPrf Weight Path *> 10.128.0.0/16 0.0.0.0 0 32768 i *> 10.129.0.0/16 10.0.0.2 0 0 64513 i * 10.192.1.0/24 10.0.0.2 0 64513 65001 i *> 10.1.1.2 0 0 65001 i

That’s it for this one. I will be doing Part 2 of this series very soon. Here are the files needed for the lab:
The Dynagen/GNS3 .net file
The IP Address Allocations
The Visio Diagram for the Lab