Applying a route map to a neighborDefining a route mapDefining an access listBGP weight attributeVerifying BGPBGP ConfigurationVerification of initial configurationInitial configurationsIP AddressesDynagen topologyDynagen topology
Today I’m expanding on to our previous BGP lab, “Configuring Basic BGP“. We’re going to demonstrate how we can use BGP’s weight attribute to influence routing out of an autonomous system (AS). We’ve got a new network topology consisting of four routers arranged in a “square”:
Dynagen topology
Here’s what our .net file for Dynagen looks like for this lab:
autostart = False
[localhost:7200]
workingdir = /home/jlgaddis/dynamips/working/bgp
[[3640]]
image = /home/jlgaddis/dynamips/ios/c3640-js-mz.124-17.img
idlepc = 0x604c37fc
ram = 128
disk0 = 8
disk1 = 0
mmap = true
ghostios = true
[[router R1]]
model = 3640
console = 2000
slot0 = NM-4T
s0/0 = R2 s0/0
s0/1 = R4 s0/1
[[router R2]]
model = 3640
console = 2001
slot0 = NM-4T
s0/1 = R3 s0/1
[[router R3]]
model = 3640
console = 2002
slot0 = NM-4T
s0/0 = R4 s0/0
[[router R4]]
model = 3640
console = 2003
slot0 = NM-4T
IP Addresses
To better illustrate the IP addressing used within the lab, here’s a handy dandy table for you as well:
| Device | Interface | IP Address | Subnet Mask |
|---|---|---|---|
| R1 | Loopback 0 | 192.168.1.1 | 255.255.255.0 |
| Serial 0/0 | 192.168.0.1 | 255.255.255.252 | |
| Serial 0/1 | 192.168.0.14 | 255.255.255.252 | |
| R2 | Loopback 0 | 192.168.2.2 | 255.255.255.0 |
| Serial 0/0 | 192.168.0.2 | 255.255.255.252 | |
| Serial 0/1 | 192.168.0.5 | 255.255.255.252 | |
| R3 | Loopback 0 | 192.168.3.3 | 255.255.255.0 |
| Serial 0/0 | 192.168.0.9 | 255.255.255.252 | |
| Serial 0/1 | 192.168.0.6 | 255.255.255.252 | |
| R4 | Loopback 0 | 192.168.4.4 | 255.255.255.0 |
| Serial 0/0 | 192.168.0.10 | 255.255.255.252 | |
| Serial 0/1 | 192.168.0.13 | 255.255.255.252 |
Initial configurations
Using the IP addressing schema from the table above, let’s go ahead and configure the loopback0, serial0/0, and serial0/1 interfaces on each router:
R1# configure terminal R1(config)# interface loopback 0 R1(config-if)# ip address 192.168.1.1 255.255.255.0 R1(config-if)# interface serial 0/0 R1(config-if)# ip address 192.168.0.1 255.255.255.252 R1(config-if)# no shutdown R1(config-if)# interface serial 0/1 R1(config-if)# ip address 192.168.0.14 255.255.255.252 R1(config-if)# no shutdown R1(config-if)# end R1#
R2# configure terminal R2(config)# interface loopback 0 R2(config-if)# ip address 192.168.2.2 255.255.255.0 R2(config-if)# interface serial 0/0 R2(config-if)# ip address 192.168.0.2 255.255.255.252 R2(config-if)# no shutdown R2(config-if)# interface serial 0/1 R2(config-if)# ip address 192.168.0.5 255.255.255.252 R2(config-if)# no shutdown R2(config-if)# end R2#
R3# configure terminal R3(config)# interface loopback 0 R3(config-if)# ip address 192.168.3.3 255.255.255.0 R3(config-if)# interface serial 0/0 R3(config-if)# ip address 192.168.0.9 255.255.255.252 R3(config-if)# no shutdown R3(config-if)# interface serial 0/1 R3(config-if)# ip address 192.168.0.6 255.255.255.252 R3(config-if)# no shutdown R3(config-if)# end R3#
R4# configure terminal R4(config)# interface loopback 0 R4(config-if)# ip address 192.168.4.4 255.255.255.0 R4(config-if)# interface serial 0/0 R4(config-if)# ip address 192.168.0.10 255.255.255.252 R4(config-if)# no shutdown R4(config-if)# interface serial 0/1 R4(config-if)# ip address 192.168.0.13 255.255.255.252 R4(config-if)# no shutdown R4(config-if)# end R4#
Verification of initial configuration
Let’s verify that we have full connectivity between our devices:
R1# ping 192.168.0.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/47/96 ms R1# ping 192.168.0.13 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.0.13, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/42/112 ms R1#
R2# ping 192.168.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/21/28 ms R2# ping 192.168.0.6 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.0.6, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/37/100 ms R2#
R3# ping 192.168.0.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.0.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/19/24 ms R3# ping 192.168.0.10 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.0.10, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/20/36 ms R3#
R4# ping 192.168.0.9 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.0.9, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/20/36 ms R4# ping 192.168.0.14 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.0.14, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/24 ms R4#
Alright, looks like we’re good to go!
BGP Configuration
Now we can get started on configuring BGP. Each router has two BGP neighbors that are directly connected via the serial 0/0 and serial 0/1 interfaces. On each router, we’re going to advertise into BGP the network of the loopback 0 interface (“192.168.x.0/24″):
R1# configure terminal R1(config)# router bgp 65001 R1(config-router)# network 192.168.1.0 mask 255.255.255.0 R1(config-router)# neighbor 192.168.0.2 remote-as 65002 R1(config-router)# neighbor 192.168.0.13 remote-as 65004 R1(config-router)# end R1#
R2# configure terminal R2(config)# router bgp 65002 R2(config-router)# network 192.168.2.0 mask 255.255.255.0 R2(config-router)# neighbor 192.168.0.1 remote-as 65001 R2(config-router)# neighbor 192.168.0.6 remote-as 65003 R2(config-router)# end R2#
R3# configure terminal R3(config)# router bgp 65003 R3(config-router)# network 192.168.3.0 mask 255.255.255.0 R3(config-router)# neighbor 192.168.0.5 remote-as 65002 R3(config-router)# neighbor 192.168.0.10 remote-as 65004 R3(config-router)# end R3#
R4# configure terminal R4(config)# router bgp 65004 R4(config-router)# network 192.168.4.0 mask 255.255.255.0 R4(config-router)# neighbor 192.168.0.9 remote-as 65003 R4(config-router)# neighbor 192.168.0.14 remote-as 65001 R4(config-router)# end R4#
Shortly after configuring BGP (above), we should see syslog messages letting us know that the adjacencies have formed. For example:
R1# *Mar 1 00:15:03.791: %BGP-5-ADJCHANGE: neighbor 192.168.0.2 Up R1# *Mar 1 00:19:50.823: %BGP-5-ADJCHANGE: neighbor 192.168.0.13 Up R1#
Verifying BGP
Let’s take a look at our BGP table on R1:
R1# show ip bgp
BGP table version is 5, local router ID is 192.168.1.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
*> 192.168.1.0 0.0.0.0 0 32768 i
* 192.168.2.0 192.168.0.13 0 65004 65003 65002 i
*> 192.168.0.2 0 0 65002 i
* 192.168.3.0 192.168.0.13 0 65004 65003 i
*> 192.168.0.2 0 65002 65003 i
* 192.168.4.0 192.168.0.2 0 65002 65003 65004 i
*> 192.168.0.13 0 0 65004 i
R1#
We can see that we have two routes to each of: 192.168.2.0/24, 192.168.3.0/24, and 192.168.4.0/24. All things being equal, BGP will choose the shortest path to each network. We can see this evidenced by the fact that BGP has chosen to send traffic for 192.168.2.0/24 to AS 65002 (R2) and traffic for 192.168.4.0/24 to AS 65004 (R4). Notice, however, that while there are two routes to 192.168.3.0/24 (AS 65003), BGP has chosen to send traffic for that network through AS 65002 (R2). The path through R2 was chosen because it is the “more stable” route (R1′s adjacency with R2 was formed before R1′s adjacency with R4).
Let’s assume, however, that (for whatever reason) we want to route traffic for 192.168.3.0/24 through AS 65004 (R4). The easiest (but not always best) way to do this is by using BGP’s weight attribute.
BGP weight attribute
Note that in the output of “show ip bgp” above, the weights assigned to each route to 192.168.3.0 are 0:
* 192.168.3.0 192.168.0.13 0 65004 65003 i *> 192.168.0.2 0 65002 65003 i
Zero is the default value. When multiple routes to the same destination exist, BGP will prefer the route with the highest weight. To influence traffic to 192.168.3.0 to take the path through AS 65004 (R4), we need to modify the weight assigned to the route received from R4. There are a few ways of doing this, but we’re going to use a route map (probably the most common method).
Just for verification, let’s look at what is currently in our routing table for 192.168.3.0/24:
R1# show ip route | include 192.168.3.0 B 192.168.3.0/24 [20/0] via 192.168.0.2, 00:17:31 R1#
We are, indeed, routing traffic to 192.168.3.0/24 via R2 (192.168.0.2).
Defining an access list
We are actually receiving multiple routes from R4, but only want to influence routing for one route so we are going to use route maps in conjunction with an IP access list to achieve our desired outcome. First, we need to define an access list that matches 192.168.3.0/24:
R1# configure terminal R1(config)# access-list 3 permit 192.168.3.0 0.0.0.255 R1(config)# end R1#
Defining a route map
With our access list now matching the networks we want to manipulate, we can now create our route map (which we’ll call “NET3″). Our route map will be configured to match traffic defined by access list 3 and will set the weight to 100:
R1# configure terminal R1(config)# route-map NET3 permit 10 R1(config-route-map)# match ip address 3 R1(config-route-map)# set weight 100 R1(config-route-map)# route-map NET3 permit 20 R1(config-route-map)# end R1#
You may be wondering about the “route-map NET3 permit 20″ statement, since it doesn’t appear to do anything. From Cisco:
“It is proper behavior to not accept any autonomous system path not matching the match clause of the route map. This means that you will not set the metric and the Cisco IOS software will not accept the route. However, you can configure the software to accept autonomous system paths not matched in the match clause of the route map command by using multiple maps of the same name, some without accompanying set commands.”
That’s exactly what we did in this case. If we had left out the “route-map NET3 permit 20″ statement, any other routes from R4 would not be accepted. Although we are only going to be manipulating the route to 192.168.3.0/24 from R4, we still need to accept all other routes from R4 into our BGP table.
Applying a route map to a neighbor
With our route map configured, we now need to instruct R1 to apply the route-map to any updates received from our neighbor, R4. Easy enough:
R1# configure terminal R1(config)# router bgp 65001 R1(config-router)# neighbor 192.168.0.13 route-map NET3 in R1(config-router)# end R1#
We’re pretty much set at this point. The changes won’t take effect immediately, however. We need to restart the BGP process in order for our changes to take effect. Let’s restart:
R1# clear ip bgp 65004
If we take a look at our BGP table, we should see that the route for 192.168.3.0/24 that came from R4 (AS 65004) should now have a weight of 100 assigned to it, and it does:
R1# show ip bgp
BGP table version is 13, local router ID is 192.168.1.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
*> 192.168.1.0 0.0.0.0 0 32768 i
* 192.168.2.0 192.168.0.13 0 65004 65003 65002 i
*> 192.168.0.2 0 0 65002 i
*> 192.168.3.0 192.168.0.13 100 65004 65003 i
* 192.168.0.2 0 65002 65003 i
*> 192.168.4.0 192.168.0.13 0 0 65004 i
* 192.168.0.2 0 65002 65003 65004 i
R1#
Subsequently, we should see that the “new” route to 192.168.3.0/24 (via 192.168.0.13 in AS 65004) was installed into our routing table:
R1# show ip route | include 192.168.3.0 B 192.168.3.0/24 [20/0] via 192.168.0.13, 00:01:56 R1#
And that’s all there it is to it!
http://evilrouters.net/2008/11/30/using-weights-to-influence-bgp-routing/
