A friend that I use to work with called me the other day. He was anxious about an upcoming network installation where he would be utilizing Multi Protocol Label Switching(MPLS) to connect several branch es of his client’s offices. Welcome to the 21 century.
His anxiety was due to the fact that this was his first MPLS encounter and he didn’t have a clue what was involved. Furthermore, the MPLS service provider, AT&T, hadn’t yet provided any details about the MPLS connections. He asked me if I could bring him up to speed on MPLS.
He wasn’t asking for much, was he? He simply wanted me to condense years of training and experience on a rather convoluted and complex subject into a 5 minute phone call. The Codger gets these types of calls all the time and, believe it or not, MPLS is just a little bit more complicated than what can be explained in a 5 minute phone call. But, like I said, this was a friend so, rather than explaining how he can pound sand, I agreed to email him some details instead.
As promised, I emailed him several pages worth of brief descriptions of how MPLS worked and different possible configuration scenarios. Combined with some links to technical documentation on Cisco’s website, I felt that he was well on his way to building a MPLS network of his very own.
When he called back a few days later, after reviewing what I had sent him, I could just about hear the confused blinking stare over the phone. I explained again that it was pretty unusual for a retail service like AT&T’s MPLS offering to actually require any MPLS configuration on the customer’s end. He couldn’t get his head around the fact that the random and excessive use of the MPLS buzzword is just marketing, it’s not what the end user has to work with. Usually, MPLS service providers just give you a circuit termination point, ethernet, frame-relay, serial PPP. You dump your data into it at one end and it comes out the other. No MPLS worries for you.
When my friend gave me the (incomplete) configuration information that AT&T had provided, it was immediately clear that he needed no help with MPLS. What he actually needed was a very basic Border Gateway Protocol(BGP) configuration to connect his branch offices over AT&T’s MPLS network.
I started searching for a couple of good links to configuration examples for him but, I didn’t find any really good ones that fit his scenario and explained what was happening. Most of the tutorials and examples were for configuring BGP to connect your router to two different ISPs on the internet. This was a little different. Simple explanations of BGP are a bit lacking and the fact is that with multihomed internet connections and ever increasing use of MPLS backed Wide Area Networks(WAN), use of BGP is rapidly increasing. Where people used to use frame-relay circuits and static routes or basic routing protocols like RIP, today they are using circuits with MPLS back haul and BGP routing.
With all those BGP newbies now using “scary” BGP routing for the first time. I decided to write up a configuration example that would explain how to simply connect a few branches over AT&T’s MPLS service and also how to setup a dual ISP internet connection. That way we can see both methods for the sake of comparison.
I’m breaking up the configuration into two parts. In this first part, I’ll cover the private WAN configuration. In the second section, I’ll cover the BGP connections to the two ISPs.
Looking at the diagram below, you can see that we have three interconnected branch offices one each in New York, Chicago and Dallas. They communicate with each other over AT&T’s MPLS service and utilize BGP to handle most routing information.

Pink routers are part of AT&T’s MPLS router cloud. The PE designation means Provider Edge(PE), typical of Cisco’s vernacular. Blue routers are those owned by the end user’s company. For the purpose of this article, they are “our” routers and are under our responsibility for configuration and administration.
Dallas
We’ll start with the Dallas branch configuration. Being a stub network connected by a T1 Point-to-Point Protocol(PPP) connection, it is the most simple configuration of the three in this example.
!
! This sets the hostname of the router.
hostname Dallas
!
! Sets the password for privileged level configuration.
enable password [password]
!
! Sets the router's time zone.
clock timezone CST -6
! Turns on automatic daylight savings time adjustment. U.S. DST settings.
clock summer-time CDT recurring 2 Sunday March 2:00 1 Sunday November
! Allows the use of zero subnets when using CIDR. Preserves IP address space.
ip subnet-zero
!
!
! Prevents the router from trying to resolve DNS hostnames entered at the command prompt.
no ip domain-lookup
!
! Enters configuration mode for that interface.
interface FastEthernet0/0
! Duh?
description connected to Dallas LAN
! Clearly, the IP address of this interface.
ip address 10.3.3.1 255.255.255.0
! Enables the interface, making it active.
no shutdown
!
! Enters configuration mode for the first serial interface.
interface Serial0/0
! Duh?
description Connected to MPLS Cloud
! The IP address fro this interface.
ip address 12.87.11.77 255.255.255.252
! Indicates that we will use PPP encapsulation for traffic on this serial interface.
encapsulation ppp
! This prevents redundant directly connected routes in the routing table.
no peer neighbor-route
!
! These commands configure the integrated CSU/DSU on the T1 WAN card.
service-module t1 linecode bz8
service-module t1 framing esf
service-module t1 timeslots 1-24
service-module t1 remote-alarm-enable
service-module t1 fdl ansi ! Ironic for an AT&T service. But still the best choice.
! Turns off Cisco Discovery Protocol on this interface.
no cdp enable
! Enables the interface making it active.
no shutdown
!
! This enables the BGP routing engine and assigns this process
! the autonomous system(AS) number 65001. This AS number
! is private to our network and was arbitrarily chosen.
router bgp 65001
! Disables IGP route validation. Makes things simpler and speeds route propagation.
no synchronization
! Logs changes in the status of the peer router. Link up/down etc.
bgp log-neighbor-changes
! Advertise this network via BGP
network 10.3.3.0 mask 255.255.255.0
! Establishes a peering session with this router and its AS number.
! This AS number belongs to and is provided by the MPLS service provider.
neighbor 12.87.11.76 remote-as 99999
! This prevents classful summarization of routes. Without it, our
! various 10.x.x.0 networks would all appear as a single 10.0.0.0
! route in BGP advertisements.
no auto-summary
!
! Enables CIDR routes.
ip classless
! Sets the default route for this router.
ip route 0.0.0.0 0.0.0.0 12.87.11.76
!
! Creates five telnet terminal lines.
line vty 0 4
! Sets the telnet password.
password [password]
! Prompts telnet sessions for a password.
login
! ! Indicates the NTP time server on the network.
sntp server 10.1.1.87
! Ends the configuration. Duh?
end
!
As you can see, Dallas is rather straight forward. It has an ethernet interface for the LAN and a serial interface, running PPP, for the WAN. There are no MPLS commands to worry about. AT&T is handling all of that for you. BGP is used to propagate our routes from site to site via the MPLS network.
Chicago
Now let’s look at the configuration for the Chicago branch. It is very similar to the Dallas branch but, it’s a bit larger. As you see in the diagram this branch has two LANs, each on different floors of the building. The second floor router at Chicago uses a single default route to connect to the network. We’ll add a couple of commands to the Chicago branch router for this second LAN.
!
hostname Chicago
!
enable password [password]
!
clock timezone CST -6
clock summer-time CDT recurring 2 Sunday March 2:00 1 Sunday November
ip subnet-zero
!
!
no ip domain-lookup
!
interface FastEthernet0/0
description connected to Chicago 1st floor LAN
ip address 10.2.2.1 255.255.255.0
no shutdown
!
interface Serial0/0
description Connected to MPLS Cloud
ip address 12.80.21.13 255.255.255.252
encapsulation ppp
no peer neighbor-route
!
service-module t1 linecode bz8
service-module t1 framing esf
service-module t1 timeslots 1-24
service-module t1 remote-alarm-enable
service-module t1 fdl ansi
no cdp enable
no shutdown
!
router bgp 65001
no synchronization
bgp log-neighbor-changes
network 10.2.2.0 mask 255.255.255.0
! Tell the BPG peers that we also have a 10.4.4.0/24 subnet
! accessible through this router.
network 10.4.4.0 mask 255.255.255.0
neighbor 12.80.21.14 remote-as 88888
no auto-summary
!
ip classless
ip route 0.0.0.0 0.0.0.0 12.80.21.14
! Route to the second floor.
ip route 10.4.4.0 255.255.255.0 10.2.2.2
!
line vty 0 4
password [password]
login
!
sntp server 10.4.4.6
end
!
As you see, we added the command network 10.4.4.0 mask 255.255.255.0 to the BGP section. This causes BGP to advertise this subnet to the rest of the network. If we had multiple such networks, we could substitute the multiple network commands with a single redistribute static command in its place.
router bgp 65001
no synchronization
bgp log-neighbor-changes
network 10.2.2.0 mask 255.255.255.0
neighbor 12.80.21.14 remote-as 88888
! Tell our BGP peers that we also have routes to the networks
! that we specify static route statements to.
redistribute static
no auto-summary
Also note that the neighbor remote-as number is different from the one used in the Dallas configuration. The difference is simply due to Chicago branch entering AT&T’s network from a different point that happens to be in a different autonomous system. Again, this number is provided by the service provider and we don’t have to worry about it beyond this configuration statement that establishes the peering between our router and theirs.
New York
Finally we come to the configuration of New York’s router. It’s a little different than the other sites. It has no serial connections. Instead it utilizes a Metro Ethernet connection to the MPLS cloud. New York is also the site through which everyone connects to the internet so, it has a couple of additional commands in its configuration.
!
hostname NewYork
!
enable password [password]
!
clock timezone EST -5
clock summer-time EDT recurring 2 Sunday March 2:00 1 Sunday November
ip subnet-zero
!
!
no ip domain-lookup
!
interface FastEthernet0/0
description connected to NewYork LAN
ip address 10.1.1.1 255.255.255.0
no shutdown
!
interface FastEthernet0/1
description Connected to MPLS Cloud
ip address 12.91.117.25 255.255.255.252
no peer neighbor-route
no cdp enable
no shutdown
!
router bgp 65001
no synchronization
bgp log-neighbor-changes
! We're anouncing that this router has access to the default route.
! This is actually a default setting that has been entered here for clarity.
network 0.0.0.0
network 10.1.1.0 mask 255.255.255.0
neighbor 12.80.21.14 remote-as 99999
! Here we tell the peer that we have the default route.
! Normally BGP does not propagate this information
! even with the network 0.0.0.0 as above.
neighbor 12.80.21.14 default-originate
no auto-summary
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.1.1.254
!
line vty 0 4
password [password]
login
!
sntp server 10.1.1.87
end
!
In the New York configuration our MPLS connection is FastEthernet rather than serial PPP but, you can see that there is little difference. Regardless of what type of layer two interface we use, we only have to configure IP and a routing protocol. There are no MPLS specific settings that we have to worry about.
Somewhat like Chicago, the New York network has two LANs. One the private local LAN and the second is the internet LAN beyond the firewall. Unlike Chicago, we only have the one default route with no additional routes for a second LAN. This router learns all of the private subnets through BGP and uses the default route out to the internet and beyond.
One final note about this BGP configuration. You’ll notice that our three branch routers are all using the same AS number(65001). That means that they are all within the same AS and share their routing information with each other via interior BGP(iBGP). Meanwhile, the AT&T routers share routing information with ours via exterior BGP(eBGP) because they are different AS than ours and we simply peer with them. It’s not a critical distinction in this example but, the question did come up.
As we have demonstrated here, connecting to an MPLS service provider is dead simple and requires no MPLS configuration on our part. We do however have to use BGP for routing across the MPLS network, at least for this MPLS service provider(AT&T) because that is what they use. Other providers could use other routing protocols but, BGP seems to be the preferred method. But, even the BGP configuration is rather straight forward and easy to grasp.
In the next article we’ll tackle the internet router and it’s BGP configuration. It’s all very similar but, as you’ll see, there are some critical differences that may not be apparent to those new to BGP.