Archive for the ‘bgp’ tag
Cisco Lab: Router Redundancy with BGP and HSRP
Introduction:
From what I have learned there are at least two typical scenarios for WAN level redundancy with BGP that you would use in a co-location environment. The first is when you get an AS from ARIN, and advertise your IP block to two different providers so you become an edge (aka border) router on the Internet receiving full BGP Internet routing tables. The other scenario is when you get a private AS from your hosting provider, and the hosting provider is the actual edge router that is multi-homed to different ISPs. This lab is about the second scenario.
A Brief Introduction to BGP:
BGP stands for Border Gateway Protocol. If there is a key concept to understand, it is that with BGP the goal is no longer to build the routing table based on each single IP network and hop (at least with eBGP), but rather between Autonomous Systems (AS). An autonomous system is a network, or a group of networks, under the control of a single organization. An example of an autonomous system might be an entire ISP, or the northeast region of an ISP, and each AS on the Internet is given a number called an ASN. So the Border in BGP is the border between these autonomous systems (Between ISPs for example). So with BGP, routing tables are built based on the number of AS hops (or in real life, many other factors), not IP hops so BGP in effect provides a macro view of the entire network (ie the Internet) leaving out the details of all the hops within an AS. The routers that live on these borders are called border or edge routers, and they speak BGP to each other.
What I just described is external BGP (eBGP), there is also internal BGP (iBGP) which is used to communicate between routers within an AS. Routers that speak BGP to each other are neighbors, and these neighbors are manually entered on each router. If the neighbors have the same AS number (ASN) then it is iBGP, if they are different, then it is eBGP.
The way that Autonomous Systems and IP networks work together is that an AS has a summary of all the networks under it’s control. Border routers announce the networks in their AS to their neighbors and then those neighbors pass it on so it reaches every border router on the Internet. As the routing information passes through a neighbor to another neighbor , the neighbor appends its AS number to the route in the AS_PATH attribute. This resulting list of AS numbers ends up being a possible route that router can use to build its routing table. It is important to understand that the the BGP table and the routing table are different, the BGP table is used to build the routing table. This attribute also prevent routing loops because by not allowing information to enter into the BGP tables that has its own AS in the AS_PATH. So BGP does need to know the next hop IP address, but only the next hop ip for the next hop AS.
Two last things I should mention are that BGP routes have attributes attached to them, and that a router attached to only one AS is called a stub. Example attributes are AS Path, Next Hop, and Local Preference.
Exploring BGP:
If you like to get to ‘touch’ the things that you learn, there are a couple of things I recommend with BGP. With traceroute, you can display the ASN numbers (at least with the one that comes with Ubuntu) by using the -A switch. So you can see where there border routers are and how the packets travel with an ASN. Some major ISPs also operator “Looking glass routers” that you can telnet into and use some show commands. For example:
$ telnet route-server.ip.att.net
...
User Access Verification
Username: rviews
route-server>show ip bgp 24.61.0.0/15
BGP routing table entry for 24.60.0.0/15, version 5701270
Paths: (18 available, best #14, table Default-IP-Routing-Table)
Not advertised to any peer
7018 7922 7015, (received & used)
12.123.25.245 from 12.123.25.245 (12.123.25.245)
Origin IGP, localpref 100, valid, external
Community: 7018:5000 7018:34011You can find a list of these routers that you can log into here.
Introduction to HSRP:
HSRP stands for Hot Standby Router Protocol and it is designed to provide LAN redundancy by providing a backup of the default gateway that each machine on the LAN has set. The typical setup is that you have two routers and each has an interface on the LAN. On each of these interfaces, they get an ip that is on the lan, but they get an additional virtual IP that will be the gateway for machines on the LAN. This IP is held by one of the routers at a time, the routers send messages to each other, and if one of the routers goes down and that router had the gateway IP, the other router will pickup the gateway IP.
The Dynamips/Dynagen Lab:
You know the cliche about pictures, so let me start with this diagram:
So in this lab, Provider1 and Provider2 are the two routers by the same provider. Mine1 and Mine2 are the routers that a client would own. The two Autonomous Systems are 1500 and 64512. 64512 falls into the range of Private ASNs, so true edge routers don’t worry about them, they know how to get to 1500, so it is loosely analogous to NAT. There were two main objectives to this lab. My first objective was to make it so that any one router or switch in the lab can fail, and traffic would still continue to route. The second objective was to make it so Mine1 is always preferred as long is it is up and running. The configuration on the provider routers are probably an over simplification of what is going on, but the configuration is functional for the purpose of this lab. The final thing I need to point out before going into the configuration was that the switches and the bonded nics are not actually part of the lab because they are beyond the capability of dynamips.
The Router and Lab Configurations:
I am going to assume that you already know how to use Dyanagen and Dynamips and how to assign ip addresses to interfaces. If you don’t know how to use Dynagen you can go through a tutorial here. I have posted the Dynagen configuration for this lab here , and the complete configurations for all the routers in the lab are posted here.
The BGP Configuration:
Neighbor Relationships:
The first step after creating the lab and setting up the ip addresses is to set up the neighbor relationships. These are created by manually entering in each side of a neighbor relationship on the routers. There are 4 of these neighbor relationships, two iBGP sessions with one between Mine1 and Mine2 and the other between Provider1 and Provider2, and two eBGP sessions with one between Mine1 and Provider1, and the other between Mine2 and Provider2. So For example, to configure the iBGP session between Mine1 and Mine2 we do the following:
Mine1(config)#router bgp 64512
Mine1(config-router)#neighbor 192.168.8.2 remote-as 64512Mine2(config)#router bgp 64512
Mine2(config-router)#neighbor 192.168.8.1 remote-as 64512Notice that on each router the bgp AS number, 64512, is the same as the configured router, so this is iBGP. When we set up these neighbor relationships, the ip of the other side is specified. Also, 64512 falls in the range of 64512-65534 which means it is a private autonomous system number. In order to verify the relashionship is established do the following:
Mine1#show bgp sum
BGP router identifier 192.168.8.1, local AS number 64512
BGP table version is 4, main routing table version 4
2 network entries using 234 bytes of memory
3 path entries using 156 bytes of memory
5/2 BGP path/bestpath attribute entries using 620 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 1034 total bytes of memory
BGP activity 2/0 prefixes, 5/2 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.16.8.1 4 1500 2775 2777 4 0 0 1d22h 1
192.168.8.2 4 64512 2800 2798 4 0 0 1d22h 1The last line should an up time for the 192.168.8.2 neighbor relationship (In this I had already set up the eBGP neighbor relationship as well). BGP isn’t the fastest routing protocol, so if it isn’t up you may want to wait about 30 seconds. Also, if you haven’t edited the logging at all, you should see a message printed to the console when it is established. If it still isn’t working, double check your ASN and IP numbers, that you can ping the neighbor ip from both routers, and also that you are not filtering TCP port 179 with an ACL because this is what BGP uses.
Setting up a eBGP session is essentially the same:
Mine1(config)#router bgp 64512
Mine1(config-router)#neighbor 172.16.8.1 remote-as 1500Provider1(config)#router bgp 1500
Provider1(config-router)#neighbor 172.16.8.2 remote-as 64512This time and the neighbor remote AS is different, so it is eBGP.
Injecting Routes:
The main point of BGP is to advertise your IP range to the Internet, to do this you inject the routes into BGP. In this lab the Provider has given us a range of 12.12.12.0/27. This range doesn’t appear on any of the router interfaces because all of those IP addresses are NAT’d to the 192.168.1.1/30 network. Since 192.168.1.1/30 is accessible from both routers we want 12.12.12.0/27 to be available from both routers, so we announce the route from both Mine1 and Mine2. The BGP configuration to announce a route is straight forward:
Mine1(config)#router bgp 64512
Mine1(config-router)#network 12.12.12.0 mask 255.255.255.224The one caveat is that a route will not be announced unless the it is in the routing table and since we don’t have a directly connected route because no interface has that route we need to add a null route:
Mine1(config)#ip route 12.12.12.0 255.255.255.224 Null0When traffic destined for the 12.12.12.0 arrives from the Provider network, it doesn’t go to NULL because NAT happens before routing (There might be a better explanation for this however, this is just how I think of it, either way, it works). After doing this, you can verify that the provider network sees the network with the following:
Provider1#show ip bgp
BGP table version is 2, local router ID is 172.16.8.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
*> 12.12.12.0/27 172.16.8.2 0 0 64512 iThis same configuration is then repeated on Mine2 changing the neighbor accordingly.
Achieving WAN Redundancy:
The steps we have taken so far fail to provide redundancy for the WAN. An example of why this is can be seen by shutting down Mine 1. Before we do this, let us look at the BGP table and the routing table on Provider 1.
Provider1#show ip bgp
...
Network Next Hop Metric LocPrf Weight Path
* i12.12.12.0/27 172.16.8.6 0 100 0 64512 64512 i
*> 172.16.8.2 0 0 64512 i
Provider1#show ip route
....
172.16.0.0/30 is subnetted, 1 subnets
C 172.16.8.0 is directly connected, FastEthernet0/0
10.0.0.0/30 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, FastEthernet1/0
12.0.0.0/27 is subnetted, 1 subnets
B 12.12.12.0 [20/0] via 172.16.8.2, 1d23hWith BGP, only one route to a destination will be entered into the routing table from the BGP table. The current route to 12.12.12.0/27 is via 172.16.8.2. If we look at the second route in BGP it is via 172.16.8.6. However there is a problem with this, if you look at the routing table there is no route to 172.16.8.6 in the routing table. So lets look at the tables after we shutdown Mine 1.
Provider1#
*Mar 3 00:22:42.223: %BGP-5-ADJCHANGE: neighbor 172.16.8.2 Down BGP Notification sent
*Mar 3 00:22:42.223: %BGP-3-NOTIFICATION: sent to ...
... neighbor 172.16.8.2 4/0 (hold time expired) 0 bytes
Provider1#show ip bgp
...
Network Next Hop Metric LocPrf Weight Path
* i12.12.12.0/27 172.16.8.6 0 100 0 64512 64512 i
Provider1#show ip route
...
Gateway of last resort is not set
172.16.0.0/30 is subnetted, 1 subnets
C 172.16.8.0 is directly connected, FastEthernet0/0
10.0.0.0/30 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, FastEthernet1/0There is now no route on Provider 1 to the 12.12.12.0 network even though there is an entry in the BGP table. The reason for this is that routes will not go from the BGP table into the routing table if the next hop can not be reached. The solution to this problem is to use the next-hop-self command. What this does is change the next-hop attribute to be the router that shares this information. To set this up on the provider side we do the following:
Provider1(config)#router bgp 1500
Provider1(config-router)#neighbor 10.0.0.2 next-hop-selfProvider2(config)#router bgp 1500
Provider2(config-router)#neighbor 10.0.0.1 next-hop-selfThen if you clear the iBGP session with you can see that the next hop has changed on Provider 1:
Provider1#clear bgp all 1500
Provider1#show ip bgp
...
Network Next Hop Metric LocPrf Weight Path
*>i12.12.12.0/27 10.0.0.2 0 100 0 64512 64512 iBecause the next hop is now reachable, there is now a route in route table for Provider 1 for the 12.12.12.0/27 network. The same thing should be done for the iBGP session between Mine1 and Mine2 as well. This problem could also be solved by using an Interior Routing Protocol as well. At this point if you are following along you can start Mine 1 again.
Configuring the Default Gateway:
Since the Mine 1 and Mine 2 routers are not getting full Internet tables from the provider, they will need a default gateway. BGP can supply a default gateway to its neighbors. To configure this is easy, you just use the default-originate command on each of the Provider routers.
Provider1(config)#router bgp 1500
Provider1(config-router)#neighbor 172.16.8.2 default-originateProvider2(config)#router bgp 1500
Provider2(config-router)#neighbor 172.16.8.6 default-originateSetting the Preferred Route:
The other objective I stated is that I want Mine 1 to be the preferred router as long as it is up and running. To accomplish this I use two tools, local-preference to set the preferred egress path from network, and AS_PATH appending to tell AS 1500 the preferred ingress route to use.
A higher local preference means the path is more favorable. For this portion, I have Mine 1 tell Mine 2 that Mine 1 is best way to go. This is done with a route map:
Mine1(config)#route-map LOCALPREF permit 10
Mine1(config-route-map)#set local-preference 200
Mine1(config-route-map)#exit
Mine1(config)#router bgp 64512
Mine1(config-router)#neighbor 172.16.8.1 route-map LOCALPREF inThis sets it so Mine1 will mark any routes it has learned about with a higher local preference when sending them to Mine 2:
Mine2#show ip bgp
...
Network Next Hop Metric LocPrf Weight Path
*>i0.0.0.0 192.168.8.1 0 200 0 1500 i
* 172.16.8.5 0 0 1500 i
* i12.12.12.0/27 192.168.8.1 0 100 0 i
*> 0.0.0.0 0 32768 iSo now if any egress traffic ends up Mine 2 that would be use the default route, it will go through Mine 1.
To tell the Provider routers that Mine 1 is preferred, we have Mine 2 prepend the AS number again so routes coming from it have a longer AS_PATH and therefore will be less preferred. Again this is done with a route map:
Mine2(config)#route-map AS_PATH_APPEND permit 10
Mine2(config-route-map)#set as-path prepend 64512
Mine2(config-route-map)#exit
Mine2(config)#router bgp 64512
Mine2(config-router)# neighbor 172.16.8.5 route-map AS_PATH_APPEND outNow on Provider 2, the routes that Mine 2 announced will seem longer than the route to Mine 1 from Provider 2 so the route to 12.12.12.0/27 via Provider 1 is preferred:
Provider2#show ip bgp
...
Network Next Hop Metric LocPrf Weight Path
*>i12.12.12.0/27 10.0.0.1 0 100 0 64512 i
* 172.16.8.6 0 0 64512 64512 iTo get a feel for all of this, I recommend taking down the routes and/or interfaces, and then running traceroutes to see how all the traffic then goes once the BGP updates have been received by neighboring routers (BGP isn’t that fast, so wait for the log messages to show up).
The HSRP Configuration:
A basic HSRP set up is actually pretty simple. Each LAN interface gets its own IP and they share a Virtual IP that computers on the LAN use as their gateway. The virtual IP is held by one router at a time only as long as both routers can still send broadcasts to each other over the LAN. In this lab, the virtual gateway IP address is 192.168.1.1:
Mine1(config)#int FastEthernet2/0
Mine1(config-if)#ip address 192.168.1.2 255.255.255.0
Mine1(config-if)#standby ip 192.168.1.1
Mine1(config-if)#standby priority 110
Mine1(config-if)#standby preempt delay reload 20
Mine1(config-if)#standby track FastEthernet0/0Mine2(config)#int F2/0
Mine2(config-if)#ip address 192.168.1.3 255.255.255.0
Mine2(config-if)#standby ip 192.168.1.1
Mine2(config-if)#standby priority 109
Mine2(config-if)#standby track FastEthernet0/0So each interfaces does get it’s own IP, but the virtual IP is shared by both. The track command makes it so that if the WAN side of either of the Mine routers goes down the gateway will follow. I have set it up so this doesn’t need to happen because traffic can enter Mine 1 on the LAN side, and leave Mine 2 on the WAN side, but I figure it makes more sense to have them stay together. The preempt command makes it so that if Mine 1 has failed, but comes back up, it will become primary again. The higher priority also makes sure that it is primary.
Conclusion:
The parts that are left out of the lab are a server with bonded nics, and the switches. The switches should be connected together with a couple of connections and be running some version of Spanning Tree Protocol (STP). The simplest set up for the bonded NICs if you are using Linux would be Active-Backup mode as it doesn’t require special configuration on the switches. I included the basic NAT configuration in the complete router configurations, however, stateful NAT would be an option for more rapid fail over because both routers would share the NAT table. With this setup there is no longer a single point of failure on the network at the device, port, or cable level. A router, switch, or network card can fail and the network should recover on its own.