evilrouters.net

In “Configuring Frame-Relay, Part 1″, I demonstrated how to configure a basic frame-relay hub and spoke network.

In Part 2, we have the same three routers with the same physical topology, but we’ll be using point-to-point connections between each of the routers.

Here’s the topology…

…and the walkthrough…

In Part 3, we’ll add another router, R4, to the topology and use a combination of the physical interface and point-to-point subinterface on R1 to demonstrate how to use both simultaneously. We’ll follow that up in Part 4 by adding OSPF to the whole network to show the differences over various types of networks.

In this video, we show how to configure a basic frame-relay network with one hub and two spokes. The configuration is pretty straightforward and simple, and nearly identical on all three routers. As such, a lot of the video is repetitive. It does, however, go from blank configurations to a fully-configured frame-relay hub-and-spoke network with full connectivity.

Here’s the topology:

As you can see, we’re using the 172.16.123.0/24 network and physical interfaces (no sub-interfaces). The DLCI numbers are illustrated in the diagram.

Here’s the video:

Part 2 uses a similar topology but in a full-mesh configuration with point-to-point connections (and sub-interfaces, of course). Part 3 will use a combination of physical interfaces and sub-interfaces to show how to set up both simultaneously. In Part 4, we’ll be configuring OSPF over the network we set up in Part 3, to show the differences in how OSPF works over various types of networks.

A couple of quick videos to show how to configure basic (back-to-back/directly connected) serial and PPP links. Here’s the topology (as basic as it gets):

Configuring a serial connection

Configuring a PPP connection

Here’s another lab that I just made up using dynamips/dynagen. There is a download link to the .net file I used (modify it as needed) at the bottom of this post.

NOTE: See the video demonstration below!

For this lab, here’s the topology we’re working with:

Our scenario here is pretty basic. We are AS 65065 and are dual-homed to our service provider, AS 65001. We have two T-1 connections: R1 to R2 and R1 to R3. We’re running BGP with our service provider and we would like to load share our outgoing traffic over these two T-1 connections. Fortunately, Cisco provides us with an easy way to do this.

As you may already know, BGP will, by default, only install the one best path into the routing table. In our case, that means that we would only be utilizing one connection at a given time. That’s not exactly the best use of our available bandwidth. The “maximum-paths” command is our friend.

From the Cisco IOS IP Command Reference:

“To configure the maximum number of parallel routes that an IP routing protocol will install into the routing table, use the maximum-paths command in router configuration or address family configuration mode. To restore the default value, use the no form of this command.”

Here are our starting configurations for R2 and R3:

R2:

interface fastethernet 0/0
 ip address 172.16.23.2 255.255.255.0
 no shutdown
interface serial 1/1
 ip address 172.16.12.2 255.255.255.0
 no shutdown
router bgp 65001
 network 172.16.12.0 mask 255.255.255.0
 network 172.16.23.0 mask 255.255.255.0
 neighbor 172.16.12.1 remote-as 65065
 neighbor 172.16.23.3 remote-as 65001
 neighbor 172.16.23.3 next-hop-self
end

R3:

interface fastethernet 0/0
 ip address 172.16.23.3 255.255.255.0
 no shutdown
interface serial 1/0
 ip address 172.16.13.3 255.255.255.0
 no shutdown
router bgp 65001
 network 172.16.13.0 mask 255.255.255.0
 network 172.16.23.0 mask 255.255.255.0
 neighbor 172.16.13.1 remote-as 65065
 neighbor 172.16.23.2 remote-as 65001
 neighbor 172.16.23.2 next-hop-self
end

The interface configuration for R1 is pretty standard and simple, with perhaps one exception:

interface serial 1/0
 ip address 172.16.13.1 255.255.255.0
 ip load-sharing per-packet
 no shutdown
interface serial 1/1
 ip address 172.16.12.1 255.255.255.0
 ip load-sharing per-packet
 no shutdown

Note the use of “ip load-sharing per-packet”. Cisco’s default is to use per-destination load sharing. You’ll want to evaluate your network to decide which is best for you.

Now, let’s configure BGP on R1 and we’re practically done:

router bgp 65065
 maximum-paths 2
 neighbor 172.16.12.2 remote-as 65001
 neighbor 172.16.13.3 remote-as 65001

The only thing left to do is test and verify. See how I did it in the video below:

• Download the dynagen .NET file

UPDATE: I made a video demonstration of this as well. You can find it at the bottom of this post. Let me know what you think! Thanks.

Upon request, and as a sort of “continuation” of a prior post, “Using BGP communities to influence routing“, I’m going to demonstrate how to permit this to occur (and configure it!) from the service provider perspective.

Recall our topology:

For simplicity, I’m only going to deal with the configurations on R1 and R2 in this post (R3’s configuration is nearly identical to R2’s). Also, because I’m doing this on real gear in my lab at work and I’m currently at home, we’ll be using our FastEthernet 0/1 interfaces (instead of FastEthernet 0/0, as depicted in the diagram). IP addresses and such will remain the same.

Remember that R1 has four loopback interfaces (172.31.0.1/24, 172.31.1.1/24, 172.31.2.1/24, and 172.31.3.1/24). R1 and R2’s IP addresses are 172.16.12.1 and 172.16.12.2 (/24), respectively.

First, let’s go ahead and bring up R2’s FastEthernet 0/1 interface:

R2# conf t
R2(config)# interface fa0/1
R2(config-if)# ip address 172.16.12.2 255.255.255.0
R2(config-if)# no shutdown

Let’s configure the interfaces on R1:

R1# conf t
R1(config)# interface loopback 0
R1(config-if)# ip address 172.31.0.1 255.255.255.0
R1(config-if)# interface loopback 1
R1(config-if)# ip address 172.31.1.1 255.255.255.0
R1(config-if)# interface loopback 2
R1(config-if)# ip address 172.31.2.1 255.255.255.0
R1(config-if)# interface loopback 3
R1(config-if)# ip address 172.31.3.1 255.255.255.0
R1(config-if)# interface fa0/1
R1(config-if)# ip address 172.16.12.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# end

Make sure we have connectivity:

R1# ping 172.16.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Now we’ll work on setting up R2, the service provider router. Remember that we’re supporting two communities that our customers can send to us:

• 200: set local preference to 200
• 500: set local preference to 500

Any routes received without one of these communities will have the local preference set to 150 (this wasn’t in the previous post, but I’m adding it here so we can show off a few things later).

First, we’ll tell R2 that we want to display BGP communities in the “new” AA:NN format:

R2(config)# ip bgp-community new-format

We need to set up two “community lists”. These are what our route maps will match on:

R2(config)# ip community-list 1 permit 65001:200
R2(config)# ip community-list 2 permit 65001:500

Now we can configure our route-map. They should fairly self-explanatory:

R2(config)# route-map CUSTOMER_IN permit 10
R2(config-route-map)# match community 1
R2(config-route-map)# set local-preference 200
R2(config-route-map)# route-map CUSTOMER_IN permit 20
R2(config-route-map)# match community 2
R2(config-route-map)# set local-preference 500
R2(config-route-map)# route-map CUSTOMER_IN permit 30
R2(config-route-map)# set local-preference 150

Can you understand what those do? By this point, hopefully you can!

Let’s go ahead and configure R2’s BGP peering with R1 and apply the CUSTOMER_IN route map to the neighbor:

R2(config)# router bgp 65001
R2(config-router)# neighbor 172.16.12.1 remote-as 65065
R2(config-router)# neighbor 172.16.12.1 soft-reconfiguration inbound
R2(config-router)# neighbor 172.16.12.1 next-hop-self
R2(config-router)# neighbor 172.16.12.1 route-map CUSTOMER_IN in

At this point, we’re all set on the service provider (R2) side. All we need is for the BGP session to come up and R1 to start advertising routes to the service provider. Let’s configure R1 to also display BGP communities in the “new” AA:NN format:

R1(config)# ip bgp-community new-format

Now, before we go messing around with any route-maps on R1, let’s get the BGP session up first:

R1(config)# router bgp 65065
R1(config-router)# neighbor 172.16.12.2 remote-as 65001
R1(config-router)# neighbor 172.16.12.2 soft-reconfiguration inbound
R1(config-router)# neighbor 172.16.12.2 send-community

Verify that BGP is up and running:

R1# show ip bgp summary
BGP router identifier 172.31.3.1, local AS number 65065
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.16.12.2     4 65001       4       4        1    0    0 00:00:21        0

Now let’s go ahead and begin advertising our four (loopback) networks:

R1(config)# router bgp 65065
R1(config-router)# network 172.31.0.0 mask 255.255.255.0
R1(config-router)# network 172.31.1.0 mask 255.255.255.0
R1(config-router)# network 172.31.2.0 mask 255.255.255.0
R1(config-router)# network 172.31.3.0 mask 255.255.255.0

How do things look from the service provider (R2) side of things?

R2# show ip bgp
BGP table version is 5, local router ID is 172.16.12.2
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
*> 172.31.0.0/24    172.16.12.1              0    150      0 65065 i
*> 172.31.1.0/24    172.16.12.1              0    150      0 65065 i
*> 172.31.2.0/24    172.16.12.1              0    150      0 65065 i
*> 172.31.3.0/24    172.16.12.1              0    150      0 65065 i

Well, there’s our routes. They are most definitely showing up. Notice that R2 has assigned them a local preference of 150 (the default is 100). This is because the routes did not have any communities associated with them, so they “fell through” the route-map on R2 and were “caught” by the last entry (”30″), which assigned them a local preference of 150.

Let’s set up two route maps on R1:

R1(config)# route-map LOCAL_PREF_200 permit 10
R1(config-route-map)# set community 65001:200
R1(config-route-map)# route-map LOCAL_PREF_500 permit 10
R1(config-route-map)# set community 65001:500

Can you figure out what those do? By assigning one of the two route maps here to our BGP adjacency with R2, we’re setting one of the community values that R2 supports.

Let’s apply the LOCALPREF200 route-map and clear our adjacency:

R1(config)# router bgp 65065
R1(config-router)# neighbor 172.16.12.2 route-map LOCAL_PREF_200 out
R1(config-router)# do clear ip bgp 172.16.12.2

Now what do we see on R2?

R2# show ip bgp | in 172.16.12.1
*> 172.31.0.0/24    172.16.12.1              0    200      0 65065 i
*> 172.31.1.0/24    172.16.12.1              0    200      0 65065 i
*> 172.31.2.0/24    172.16.12.1              0    200      0 65065 i
*> 172.31.3.0/24    172.16.12.1              0    200      0 65065 i

Aha! Now R2 has assigned a local preference value of 200 to our routes. Can you guess what will happen if we apply the LOCALPREF500 route-map on R1?

R1(config-router)# no neighbor 172.16.12.2 route-map LOCAL_PREF_200 out
R1(config-router)# neighbor 172.16.12.2 route-map LOCAL_PREF_500 out
R1(config-router)# do clear ip bgp 172.16.12.2

I bet you know what R2’s BGP table is going to look like now, don’t you!?

R2# show ip bgp | in 172.16.12.1
*> 172.31.0.0/24    172.16.12.1              0    500      0 65065 i
*> 172.31.1.0/24    172.16.12.1              0    500      0 65065 i
*> 172.31.2.0/24    172.16.12.1              0    500      0 65065 i
*> 172.31.3.0/24    172.16.12.1              0    500      0 65065 i

Bingo! R2 has now assigned a local preference value of 500 to our advertised routes! See how easy that is? Now go out there and change how your SP routes to you!

Note: If you found this useful, please do leave me a comment below and let me know. Also, if there are specific examples or “how to’s” you’re looking for, let me know that too. I’m always looking for good ideas for things to write about!

UPDATE: Added a video demo at the bottom of the post (22-Mar-2008).

Here’s a quick demonstration on how to configure two routers to be BGP neighbors. I’m using dynamips and the same topology from yesterday’s multilink PPP lab (for simplicity):

Autonomous Systems

• R1 : 42
• R2 : 69

Networks Advertised

We’ll configure a loopback 0 interface on each of the two routers and then advertise those networks to our BGP neighbors.

• R1 Loopback0 : 42.42.42.1/24
• R2 Loopback0 : 69.69.69.1/24

Loopback Configuration

Let’s configure our loopback 0 interfaces first:

R1# configure terminal
R1(config)# interface loopback 0
R1(config-if)# ip address 42.42.42.1 255.255.255.0
R1(config-if)# end
R1#

R2# configure terminal
R2(config)# interface loopback 0
R2(config-if)# ip address 69.69.69.1 255.255.255.0
R2(config-if)# end
R2#

R1 BGP Configuration

Now we’ll configure BGP on R1 and advertise only the 42.42.42.0/24 network into BGP:

R1# configure terminal
R1(config)# router bgp 42
R1(config-router)# network 42.42.42.0 mask 255.255.255.0
R1(config-router)# neighbor 192.168.42.2 remote-as 69
R1(config-router)# end
R1#

R2 BGP Configuration

Likewise, we’ll configure BGP on R2 and advertise only the 69.69.69.0/24 network:

R2# configure terminal
R2(config)# router bgp 69
R2(config-router)# network 69.69.69.0 mask 255.255.255.0
R2(config-router)# neighbor 192.168.42.1 remote-as 42
R2(config-router)# end
R2#

Verification

After a moment we should see a syslog message (on each router) similar to the following, letting us know that an adjacency has formed:

*Mar  1 00:07:28.667: %BGP-5-ADJCHANGE: neighbor 192.168.42.2 Up

BGP is not the fastest protocol when it comes to convergence, but after a moment we should see the neighbors are exchanging routes:

R1# show ip bgp summary
BGP router identifier 42.42.42.1, local AS number 42
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
3/2 BGP path/bestpath attribute entries using 372 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 734 total 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
192.168.42.2    4    69       5       5        3    0    0 00:01:18        1
R1#

R2# show ip bgp summary
BGP router identifier 69.69.69.1, local AS number 69
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
3/2 BGP path/bestpath attribute entries using 372 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 734 total 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
192.168.42.1    4    42       6       6        3    0    0 00:02:03        1
R2#

And if we take a look at our routing tables on each router, we should see that the networks we advertised into BGP do, indeed, show up on the other side:

R1# show ip route bgp
     69.0.0.0/24 is subnetted, 1 subnets
B       69.69.69.0 [20/0] via 192.168.42.2, 00:05:00
R1#

R2# show ip route bgp
     42.0.0.0/24 is subnetted, 1 subnets
B       42.42.42.0 [20/0] via 192.168.42.1, 00:04:52
R2#

Success! Later we’ll cover multihoming and the use of weights, local preferences, and MEDs to influence routing decisions.

UPDATE: Added a video demo at the bottom of the post (22-Mar-2008).

This is just a quick lab I whipped up to demonstrate how to configure multilink PPP between a pair of routers. According to Cisco:

“Multilink PPP (also referred to as MP, MPPP, MLP, or Multilink) provides a method for spreading traffic across multiple physical WAN links while providing packet fragmentation and reassembly, proper sequencing, multivendor interoperability, and load balancing on inbound and outbound traffic.”

In other words, we can combine multiple physical connections into a single logical connection to provide increased bandwidth and/or load balancing.

Here’s what our topology looks like:

Pretty simple setup: two routers, R1 and R2, with two serial connections between their serial 0/0 and serial 0/1 interfaces. Let’s get right into it:

R1’s configuration

R1# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)# interface multilink 1
R1(config-if)#
*Mar  1 00:04:09.975: %LINEPROTO-5-UPDOWN: Line protocol on Interface Multilink1, changed state to down
R1(config-if)# ip address 192.168.42.1 255.255.255.252
R1(config-if)# ppp multilink
R1(config-if)# ppp multilink group 1
R1(config-if)# interface serial 0/0
R1(config-if)# encapsulation ppp
R1(config-if)# ppp multilink
R1(config-if)# ppp multilink group 1
R1(config-if)# no shutdown
R1(config-if)#
*Mar  1 00:05:07.467: %LINK-3-UPDOWN: Interface Serial0/0, changed state to up
R1(config-if)# interface serial 0/1
R1(config-if)# encapsulation ppp
R1(config-if)# ppp multilink
R1(config-if)# ppp multilink group 1
R1(config-if)# no shutdown
R1(config-if)# end
R1#
*Mar  1 00:05:33.679: %SYS-5-CONFIG_I: Configured from console by console
R1#
*Mar  1 00:05:35.019: %LINK-3-UPDOWN: Interface Serial0/1, changed state to up
R1#

R2’s configuration

Before starting to configure the other end of the link, I’ve started a debug so that we can see what is happening in the background:

R2# debug ppp multilink events
Multilink events debugging is on
R2#

R2# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)# interface multilink 1
*Mar  1 00:08:23.703: %LINEPROTO-5-UPDOWN: Line protocol on Interface Multilink1, changed state to down
R2(config-if)# ip address 192.168.42.2 255.255.255.252
R2(config-if)# ppp multilink
R2(config-if)# ppp multilink group 1
R2(config-if)# interface serial 0/0
R2(config-if)# encapsulation ppp
R2(config-if)# ppp multilink
R2(config-if)# ppp multilink group 1
*Mar  1 00:08:45.711: Se0/0 MLP: Added interface to multilink group Mu1
R2(config-if)# no shutdown
*Mar  1 00:08:52.231: %LINK-3-UPDOWN: Interface Serial0/0, changed state to up
*Mar  1 00:08:52.343: Se0/0 MLP: Request add link to bundle
*Mar  1 00:08:52.343: Se0/0 MLP: Adding link to bundle
*Mar  1 00:08:52.355: Mu1 MLP: Added first link Se0/0 to bundle R1
R2(config-if)#
*Mar  1 00:08:52.363: %LINK-3-UPDOWN: Interface Multilink1, changed state to up
*Mar  1 00:08:53.339: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up
*Mar  1 00:08:53.367: %LINEPROTO-5-UPDOWN: Line protocol on Interface Multilink1, changed state to up
R2(config-if)#

At this point, our multilink PPP session is up, although with only one link. It is completely usable and operational. Let’s go ahead and bring up the other serial link:

R2(config-if)# interface serial 0/1
R2(config-if)# encapsulation ppp
R2(config-if)# ppp multilink
R2(config-if)# ppp multilink group 1
R2(config-if)#
*Mar  1 00:12:22.647: Se0/1 MLP: Added interface to multilink group Mu1
R2(config-if)# no shutdown
R2(config-if)# end
R2#
*Mar  1 00:12:32.195: %SYS-5-CONFIG_I: Configured from console by console
*Mar  1 00:12:32.399: %LINK-3-UPDOWN: Interface Serial0/1, changed state to up
R2#
*Mar  1 00:12:32.447: Se0/1 MLP: Request add link to bundle
*Mar  1 00:12:32.447: Se0/1 MLP: Adding link to bundle
*Mar  1 00:12:32.459: Mu1 MLP: Added link Se0/1 to bundle R1
*Mar  1 00:12:33.447: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to up
R2#

We see that the other serial link has came up and been automatically added to the “bundle”, just as the first one was.

Verifying Multilink PPP

We can verify the proper operation of our multilink PPP configuration easily:

R1# show ppp multilink

Multilink1, bundle name is R2
  Endpoint discriminator is R2
  Bundle up for 00:06:17, total bandwidth 3088, load 1/255
  Receive buffer limit 24000 bytes, frag timeout 1000 ms
    0/0 fragments/bytes in reassembly list
    0 lost fragments, 0 reordered
    0/0 discarded fragments/bytes, 0 lost received
    0x6 received sequence, 0x6 sent sequence
  Member links: 2 active, 0 inactive (max not set, min not set)
    Se0/0, since 00:06:17
    Se0/1, since 00:02:37
No inactive multilink interfaces
R1#

From the output above, we see that our “bundle”, R2, has two links (serial 0/0 and serial 0/1), both of which are active. We also see that there are no inactive links. In addition, note that the bandwidth of this link is 3088 Kbps — twice the bandwidth of a normal T-1. Let’s ping the remote end to verify connectivity:

R1# ping 192.168.42.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.42.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/17/36 ms
R1#

Success! It works just as expected!

a parody of the mac vs. pc commercials with south park characters. created as the final project for a multimedia production class at california state university northridge (csun).