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
(You will need to modify the .net file to reflect your own IOS and path values)

Colby

Colby Glass has been in IT since 2002. He is currently a Systems Engineer (presales) with a Cisco Gold partner and holds the CCNP R/S, CCNP DC, CCDP, CCIP, JNCIA-ER.

More Posts