Aaron’s Worthless Words

Here’s a handy list of ACL entries to allow your devices to speak routing protocols, availability protocols, and some other stuff. We’ll assume you have ACL 101 applied to your Ethernet inbound; your Ethernet has an IP of 192.168.0.1.

• BGP : Runs on TCP/179 between the neighbors

access-list 101 permit tcp any host 192.168.0.1 eq 179

• EIGRP : Runs on its own protocol number from the source interface IP to the multicast address of 224.0.0.10

access-list 101 permit eigrp any host 224.0.0.10

• OSPF : Runs on its own protocol number from the source interface IP to the multicast address of 224.0.0.5; also talks to 224.0.0.6 for DR/BDR routers

access-list 101 permit ospf any host 224.0.0.5
access-list 101 permit ospf any host 224.0.0.6

• HSRP : Runs on UDP from the source interface IP to the multicast address of 224.0.0.2. I’ve seen in the past that it runs on UDP/1985, but I didn’t find any evidence of that in a quick Google for it. Can someone verify?

access-list 101 permit udp any host 224.0.0.2

• RIP : Runs on UDP/520 from the source interface IP to the multicast address of 224.0.0.9

access-list 101 permit udp any host 224.0.0.9 eq 520

• VRRP : Runs on its own protocol number from the source interface IP to the multicast address of 224.0.0.18

access-list 101 permit 112 any host 224.0.0.18

• GLBP : Runs on UDP from the source interface IP to the multicast address of 224.0.0.102

access-list 101 permit udp any host 224.0.0.102

• DHCPD (or bootps) : Runs on UDP/67 from 0.0.0.0 (since the client doesn’t have an address yet) to 255.255.255.255 (the broadcast).

access-list 101 permit udp any host 255.255.255.255 eq 67
If anyone else has one to add, do so in the comments.

• Leave a comment... (14)

My friend Josh over at blindhog.net has found a collection of cheat sheet gems for the network dude(tte).  There’s sheets on BGP, OSPF, Subnetting, QoS, connector types, and more.  Check it out.

Cheat Sheets - Packetlife.net

• Leave a comment... (1)

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... (1)