Aaron’s Worthless Words

Here’s a scenario I ran into long ago. We had several sites that had a frame relay link back to headquarters and a DSL line. Each link was terminated into a different router on a flat LAN with the users. The DSL was for Internet access, but also terminated a VPN as a backup to the frame circuit. The requirements were something like this.

• Corporate traffic had to go across the frame relay link during normal operations.
• Internet traffic had to go across the DSL line during normal operations.
• If the DSL circuit went down, Internet traffic should be moved over to the frame relay circuit to use the corporate Internet link.
• If the frame went down, traffic should be sent out the VPN tunnel for access to corporate stuff.

We set the default routes of the machines (via DHCP) to the frame relay router. That router’s default route sent traffic to the DSL router, which, of course, had a default route towards the provider. Both routers were participating in EIGRP with the rest of the corporate network, so they all knew where to route traffic destined for corporate traffic. If there was a frame outage, the default routes kicked in and sent traffic to the DSL router, which had the VPN tunnels. The problem came when there was a DSL outage.

At first, we were just monitoring the DSL IP and manually changing default routes when there was an outage, but you know DSL. We were lucky to have only 3 or 4 a day go down, so it was taking up a lot of our time just moving default routes around. We had to go to an automated solution, so we looked at doing object tracking but came up just short; it just didn’t do what we wanted. We had to go one more step and discovered reliable static routing (RSR).

In normal object tracking, you can track an interface or a route to an IP. With RSR, you can track reachability to an IP via ICMP (or a whole list of other things). This is just what we needed. We figured Yahoo was a site that would always be up, so we went about tracking one of Yahoo’s IPs from the frame routers, and, if it went down, we could send traffic back across the frame relay cloud.

To set up RSR, you have to set up an IP SLA entry, build a tracking object, then have the default route track the object. First, the IP SLA entry that we made.

ip sla monitor 1
type echo protocol ipIcmpEcho 66.94.234.13
frequency 10


This built IP SLA entry 1 to ping 66.94.234.13 every 10 seconds. With IP SLA, you also have to set a schedule for it to run. We wanted it to start ASAP and run forever, so we just did one of these.

ip sla monitor schedule 1 start-time now

This schedules entry 1 to start now, so every time the box came up, the IP SLA process started pinging away. You then combine the entry with a tracking object like this.

track 100 rtr 1 reachability

We built object 100 to monitor the reachability of SLA entry 1, so now we have an object to track if a host is unreachable. Sweet. How about the static part of the route? We set the default route of the frame router as the LAN IP of the DSL router tracking object 100. We also set a weighted default route pointing out the frame relay circuit to use when the object fails. Assume 10.0.0.0/24 for the frame cloud and 192.168.0.0/30 for the LAN.

ip route 0.0.0.0 0.0.0.0 192.168.0.1 track 100
ip route 0.0.0.0 0.0.0.0 10.0.0.254 250

In this setup, the default route is the DSL router, and, if the tracking object fails, it rolls to the frame cloud. Can you spot the flaw, though? When the route changes over, the object has recovered since it can reach Yahoo through the corporate Internet, and the default route get moved back to the DSL router…which then fails again…and rolls back…and…ack! An easy fix is to set a static route for the tracked IP to the DSL router.

ip route 66.94.234.13 255.255.255.255 192.168.0.1

This route also lets the frame monitor monitor the DSL service, so, when it comes back up, the tracking object recovers. Of couse, if someone at the site tried to get to Yahoo on that IP during a DSL outage, they would time out (shouldn’t they be working?), but, when the DSL recovered, the router would know.

• Leave a comment... (2)

If you’re running iBGP, you may have run across this. What if you had three routers — R0, R1, R2 — that were running BGP under the same ASN, but R1 and R2 weren’t peered? Any routes coming from R1 would not show up on R2 and vice versa. iBGP, by standard, does not pass on routes it learned via the same ASN. That is, if a router learns a route from another router in the same autonomous system, the route does not get forwarded. I guess it just assumes that all iBGP routers are fully meshed…I don’t really know.

That sucks, right? One of several fixes for this is the route-reflector-client directive under the BGP neighbor configuration. A route-reflector literally reflects the routes from one client to the others just as if you’ve got a fully meshed network. Here’s a sample config for the reflector, R0.

router bgp 65000
neighbor 10.0.0.11 remote-as 65000
neighbor 10.0.0.11 route-reflector-client
neighbor 10.0.0.12 remote-as 65000
neighbor 10.0.0.12 route-reflector-client

There’s actually no additional config on R1 and R2 at all; the router reflection is transparent to them. They actually see the route just as though they got the update directly from the originating router, so any routes received from the reflector appear as though they came from the originator. In that same breath, you have to realize that R1 and R2 must have routes to each other since the untouched BGP routes will have a next-hop address as the originating router.

Edit: Here’s a crayon drawing I did to show an example of where you would use route-reflectors. R0 is connected to R1 and R2 via different WANs, but R1 and R2 aren’t connected at all.

• Leave a comment... (0)

I realized the other day that I haven’t mentioned EIGRP once. As a Cisco guy, I think I’m required to do at least one article on it, so here it goes.

Enhanced Interior Gateway Routing Protocol (EIGRP) is a Cisco-proprietary routing protocol. Routing protocols share routes, right, but “interior” is the keyword here; it’s used to distribute routes on your internal network (Contrast that with BGP, which is allows you to share your routes with others). In a nutshell, each router in the EIGRP cloud tells everyone what subnets it has connected to him.  A receiving router then combines that information with everything that it already knows and passes on any new information.  Do that recursively for a while, and, eventually, every routers knows all the subnets in the network.

When you configure EIGRP, you have to tell it some stuff to get it moving.  First, you have to configure a AS number, which is very similar to the AS number is BGP.  When two routers talk EIGRP, they always include their AS numbers, so, if one router receives an update for an AS it isn’t configured for, it ignores it.  Besides the AS, the only other thing you need to configure is what networks you want advertised via that EIGRP AS.  It’s simple and easy, but there are thousands of combinations of commands that you can use.

Basic config time!  The scenario is that you have two routers, R0 and R1, that share a LAN segment 192.168.0.0/24 off their F0/0 interfaces.   R0 has the network 192.168.100.0/24 off F0/1, and R1 has 192.168.101.0/24 off F0/1.  You want both routers to know where every subnet on the network is, and we’ll use AS 1 for simplicity.

On R0:

router eigrp 1
network 192.168.0.0
network 192.168.100.0

Every interface to falls into these network ranges will now participate in EIGRP AS 1.  If you had another interface on another subnet, that interface would not participate.  On the flip side, if your F0/0 as 192.168.0.0/25 and F0/1 was 192.168.0.128/25, then you would only need the one network line to cover both interfaces.  Notice that there’s no subnet or wildcard mask in these lines.  EIGRP is very classful, so it summarizes routes to network boundaries before inserting the more-specific route from EIGRP, so keep an eye out for that to be sure it doesn’t bite you.

On R1:

router eigrp 1
network 192.168.0.0
network 192.168.101.0

Almost immediately, you should see some lines talking about new adjacencies or neighbor changes.

If you do a show ip route on each router, you should see some routes from EIGRP.  Here’s the output from R0.

C    192.168.0.0/24 is directly connected, FastEthernet0/0
C    192.168.100.0/24 is directly connected, FastEthernet0/1
D    192.168.101.0/24 [90/30720] via 192.168.0.2, 00:00:47, FastEthernet0/0

The big ol’ D at the beginning of the line tells you that this is an EIGRP route, so you know it’s working.

Check out one of Cisco’s pages for more info.

• Leave a comment... (0)

HSRP (Hot Standby Router Protocol) is a Cisco-proprietary method for supplying a highly-available gateway for hosts to use. GLBP (Gateway Load Balancing Protocol) does the same thing. So, what’s the difference?

HSRP works on layer 3 and provides a standby IP address for hosts on that network to use as their gateway (or other routers to use as a next-hop for a route). Two or more routers are configured with the standby IP on a broadcast interface (usually an Ethernet of some kind), and a passive election is held to determine the active router. This router answers ARP requests for the standby IP with a virtual MAC address, so every host that sends packets to the standby IP winds up sending it to the active router. If the active router dies, another election is held, and a new king is crowned who answers for the virtual MAC; the hosts never know anything happened.

GLBP is a little different and runs on layer 2. Instead of one router taking all the traffic all the time, GLBP provides a mechanism to load-balance the standby IP. I’m sure you figured that out by the name, though. When configured, GLBP provides a standby IP just as HSRP does, but it also provides multiple virtual MAC addresses. When a host on the connected network sends an ARP request, one of the routers answers with the virtual MAC address. The next time a host ARPs, a different router answers with a different virtual MAC address. After all is said and done in our perfect world, you have an equal number of hosts sending traffic to each router doing GLBP via the virtual MACs (this never pans out due to the way machines ARP). If a router dies, one of the other participating routers takes over for that virtual MAC, and the host is none-the-wiser.

If you’re having problems deciding on which one to use, it really all boils down to how many hosts you have on that particular network that you want to be HA. For example, if I had a network that only had two routers as the gateway and a single firewall, I’d use HSRP; there will only be the one firewall ARPing and sending packets the standby IP any traffic so you wind up only using one anyway. If you have a network with a thousand hosts on it (say a web farm), then go with GLBP to balance the traffic across your routers.

• Leave a comment... (0)

It looks like there was another bad BGP announcement over the weekend.  This time, a 24-bit network belonging to the country of Kenya was being advertised by Above.net.  The heart of the problem is the same as it was with the YouTube problem a few weeks ago:  someone who wasn’t authoritative for a network began advertising routes to that network.

While this issue didn’t have nearly the impact that the YouTube incident had, just ask the people in Kenya who were offline for several hours while things were broken.  It’s just another item to add to your list of reasons that BGP needs to be fixed.

• Leave a comment... (0)

BGP has issues; the main one being transitive [tag]trust[/tag]. [tag]BGP[/tag] works by having networks (companies, providers, etc.) advertise [tag]routes[/tag] that it owns to its peers. These peers pass those routes on to their peers, ad nauseum, until everyone knows what networks everyone has. The big assumption here is that you are advertising only networks for which you are responsible. The word “assumption” should be emphasized.

The Pakistani government decided that a video on [tag]YouTube[/tag] was bashing Islam, so they ordered the Pakistani Internet services to block it. Instead of filtering from their network out, they decided to advertise via BGP that they were YouTube. To make things worse, they used a more-specific, 24-bit route; since YouTube advertises a 22-bit route, the new Pakistani route is preferred since its more specific. The transitive trust of the BGP cloud allowed them to tell the world that YouTube was on their network, effectively taking YouTube completely off the Internet for few hours. YouTube finally changed their advertising to a bunch of 25-bit networks, which restored connectivity, and, eventually, the Pakistani ASN withdrew the route. Here’s a timetable from Martin Brown of [tag]Renesys[/tag].

Obviously something needs to be done about this. This is not the first time time that someone has (un)intentionally advertised someone else’s routes and took stuff down (The Yahoo! outage from July 2007 comes to mind). I have no solution, but TPTB might want to prioritize finding a more-secure method for controlling an IP space advertisements. Certificate-based peering? More filtering on the transit networks? There’s no good solution, really.

• Leave a comment... (1)