Just another Cisco blog
MPLS and BGP Lab Guide, Part 4
This is the fourth 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:
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 is going to be a short one. We’ll go through the config for NewYork-I. It’s a multi-homed BGP config, which is why I didn’t include it with the other internet edge routers. Here’s the config:
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 config 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 config:
ip as-path access-list 10 permit ^$ ! route-map INET_OUT permit 10 match ip address LAN_IP match as-path 10 ! router bgp 65001 no synchronization bgp log-neighbor-changes network 10.192.1.0 mask 255.255.255.0 neighbor 10.1.1.1 remote-as 64512 neighbor 10.1.1.1 route-map INET_OUT out neighbor 10.2.0.1 remote-as 64513 neighbor 10.2.0.1 route-map INET_OUT out neighbor 192.168.0.254 remote-as 65001 neighbor 192.168.0.254 next-hop-self no auto-summary |
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 don’t want those advertised to the internet, we also match our as-path ACL in the route-map. The rest of the BGP config 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:
Chicago-M#ping 10.128.0.1 source 192.168.5.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.128.0.1, timeout is 2 seconds: Packet sent with a source address of 192.168.5.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/40/96 ms Chicago-M#ping 10.129.0.1 source 192.168.5.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.129.0.1, timeout is 2 seconds: Packet sent with a source address of 192.168.5.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/31/56 ms |
We can ping the internet from our LAN subnet on Chicago-M, so we know NAT is working properly.
Internet1#sh ip bgp neighbors 10.1.1.2 routes BGP table version is 11, local router ID is 10.128.0.1 Network Next Hop Metric LocPrf Weight Path *> 10.192.1.0/24 10.1.1.2 0 0 65001 i Total number of prefixes 1 Internet2#sh ip bgp neighbors 10.2.0.2 routes BGP table version is 10, local router ID is 10.129.0.1 Network Next Hop Metric LocPrf Weight Path *> 10.192.1.0/24 10.2.0.2 0 0 65001 i Total number of prefixes 1 |
We see only our DMZ on the internet routers, which is what we want.
That’s it for this one, part five will be coming 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)
Related Posts:
| Print article | This entry was posted by Colby on December 16, 2009 at 7:23 am, and is filed under Labs, Tutorials. Follow any responses to this post through RSS 2.0. You can leave a response or trackback from your own site. |








about 1 year ago
This is a real good series of posts and has helped me greatly in my studies!
There is just one thing I don’t get…You are usually very complete with your descriptions, or you say when you omit stuff….but I just worked through the configs on this part (4) of the Lab, and you go from configuring New-York_I to testing using Chicago_M as a ping source. At this point you haven’t configured (or even mentioned) Chigago_M, and if it’s going to communicate with 10.128.0.1, the Internet_1 Lo0 range, from its own loopback range 192.168.5.1, then it has to go through the (MPLS) network in AS65535…But so far we have not configured the VPNs in that AS, nor even got BGP running in AS 65535, so getting the VPNs running is still some way away. We have OSPF running, but trying to ping from Chcago assumes we have already done some (at least basic) configuration on Chicago_M.
I will be creating my own configuration where I need to, to complete the LAB, and I have to say that its only because of your work that I could even think of putting such a complex config together, but can you clarify for me: did I miss a bit of your write-up, did you miss a bit of your writeup, or did I completely miss the point? I don’t want to criticise your work, but I’m puzzled….
Regardless of all that, this is one fine Lab, and has been a great learnng tool! Thanks!
Jim
about 1 year ago
Jim,
Thanks for the post and kind words!
I’ll admit, I did jump around quite a bit when doing these guides. I probably could have made them flow better. In this one using Chicago-M as the ping source was probably a bad choice as, like you said, we hadn’t touched that router yet nor had we configured the MPLS VPNs. I probably should have used NY-I as the source, sorry about that.
I do believe we covered the MPLS VPNs and Chicago-M in the later posts. Here is a summary of the guides:
Part 1 – Configured Internet1 and Internet2
Part 2 – Configured WAN MPLS cloud
Part 3 – Configured London and Paris Internet routers
Part 4 – Configured New York-I
Part 5 – Configured MPLS VPNs in the WAN
Part 6 – Configured M routers
Again, sorry for the confusion in this one, choosing Chicago to run the ping from wasn’t the best idea on my part.
about 1 year ago
Hey, don’t apologise, this Lab is superb! I’ll bear your words in mind while I complete the rest of build… thanks for a quick response.
Just to amuse you, it took me about an hour to find where I had gone wrong with the initial MPLS config, earlier in the Lab…couldn’t get the right response to “sh mpls ldp neigh” for MPLS-PE2…you would think I could tell the difference between 255 and 225, wouldn’t you???
Many Thanks
Jim Blake
about 1 year ago
Hey, thanks again! And lol @ the 255/225 thing.
Here’s a good one for you: last week I had to add a new allowed SNMP IP to around 50 ASAs. A bunch of them weren’t showing up in Orion, it took me awhile to realize that I specified the wrong interface (outside instead of inside) on a bunch of them. Doh.
about 1 year ago
Excellent and fun lab. I added the IPSec to the GRE tunnels and everything is working great. I disconnected the Paris-M router from the MPLS cloud to test redundancy through the GRE tunnel. I only lost 2 pings during the failover, so that’s less than 4 seconds, that’s great.
The only thing of concern is when I reconnect the Paris-M router and after the BGP is re-established, the route to London-M from Paris-M remains through the GRE tunnel. The only way I can get it corrected is to reset the iBGP connection to Paris-I. Have you experienced this before and were you able to find a solution?
Thanks for the great lab,
Jerry
about 1 year ago
Jerry, that’s odd. When the link comes back up the route should go back into the BGP table with a higher weight and then into the RIB. Are you using Dynamips? I’ve seen goofy stuff like that in Mips before.
about 1 year ago
Hey Colby, no I’m not using Dynamips, I’m using real routers. I use 3640s for the Internet and MPLS cloud, 2620s for the Internet facing routers and 2610s for the MPLS facing routers. I’ve seen this issue before at work, but I can’t remember what we did to resolve it.
In the normal state, both routes show in the BGP table with only the MPLS route in the RIB. During failover and after failover, only the GRE route shows in the BGP table and the RIB. After I clear the iBGP peer, it returns to normal state.
Well, I’ll play with it more tomorrow to see if I can figure out the issue and then post the results. Thanks for the prompt reply.
about 1 year ago
Hey Colby, let me retract my statements. I forgot how slow BGP is. After waiting about 5 to 8 minutes, I saw the BGP table correctly install the right route. So to recap…
When first bringing the routers online, both routes show in the BGP table. The route that’s first in the BGP table (based on how long it takes the devices to come online) will be inserted into RIB. After about 5 to 8 minutes, only one route shows in the BGP table and in RIB, and it’s the proper one based on the BGP selection process.
During failover, the GRE route takes over in about 4 seconds. After failover, once BGP has re-established, both routes show in the BGP table and the GRE route remains as best route for 5 to 8 minutes before the BGP process switches to the MPLS route, which is the inserted into RIB.
Sorry for the confusion but it’s been a while since I played in the lab and my impatience got the best of me. Once again, thanks for the great lab.