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)

We just talked about tagging traffic and policing traffic, but we haven’t talked about prioritizing traffic. Tagging just sets a value in the header. Policing sets a “bandwidth ceiling” that can’t be crossed. Prioritization guarantees a certain amount of bandwidth for a flow/app/etc. no matter what’s going on.

Prioritization offers you a certain amount of bandwidth; it doesn’t carve it out and hand it over. If you’re using less than the priority value, you only get as much as you need and the rest of the reserved bandwidth goes into the pot for everyone to use. As priority traffic grows, though, you’re given as much as you need up to the configured value. When you go over that, your extra traffic just goes into the best-effort queue with everything else (Note: Don’t go over the limit with VOIP traffic. Echoes and artifacts suck). For example, if you give your VOIP traffic 70% of the bandwidth of an interface but are only using 40%, the other 30% can be used by the other apps on the line. If you’re using 80%, that 10% over is competing with everything else for bandwidth.

Let’s get on with it, shall we? To configure prioritization, you go through the same steps as we did with policing, but, instead of setting the policy-map for police, you set it up for…wait…wait…priority. Here’s the scenario, then. You have a router that has a VOIP system behind it. That router tags all VOIP packets as AF41, so we want to give any AF41 packets 70% of the bandwidth on the interface. The tagging router is directly attached to your F0/0 network, and your users are out F0/1.

We don’t use an access list this time since we’re looking for DSCP values in the packets. We’ll start with the class-map.

class-map VOIP
match dscp af41

Remember that class-maps define what traffic you’re interested in, so this line says that we want to do something with any packet that’s tagged AF41. Let’s tell the router what we want to do with it, then.

policy-map PMAP
class VOIP
priority percent 70

With this configuration, any packet with a DSCP value of AF41 is given priority and is guaranteed up to 70% of the total bandwidth available. So, what is 70% of the total bandwidth available? That depends on where we apply the policy-map. If it’s on a T1, that’s 1.08Mbps. On our FastEthernet, that’s 70Mbps.

Let’s apply it to the interface to finish up.

interface F0/1
policy-map output PMAP

Since we’re worried about squashing VOIP traffic on F0/1, we apply it outbound there (towards the users). We could apply it inbound on F0/0, right? Not really. Once the packets hit the interface, it’s too late to do any prioritization on them; they’re already on the router in the order that the switch is delivering them to us. Prioritization really only works outbound.

So, if nothing’s going on, VOIP can use up to 100Mbps, but, if the link is saturated, it’s guaranteed 70% of the bandwidth or 70Mbps. Of course these numbers should be tweaked to suit your needs, but you can see how useful prioritizing is.

• Leave a comment... (0)

I’ve been trying to get some experience on Cisco VOIP, and, as you probably know, Quality of Service (QoS) is quite important in that realm. Since VOIP is very time-sensitive, you have to be sure your gear delivers the voice packets first. A packet in an HTTP transaction can wait another 200ms without any problems. A voice packet with another 200ms on it means static and digital artifact on the line. Not good. There are lots of things you can do in the world of QoS, but I’ll talk about tagging this time (I may get to some of the other topics later, though).

What is tagging, though? There is a header in an IP packet that, paraphrased from the standard, set the importance and drop-sensitivity of the packet in regard to the flow/application/data stream. A ping packet is quite unimportant in the grand scheme of things, and dropping the packet will have very little impact on the stuff going on in the network. Voice, however, needs every packet to arrive in order, so each packet’s importance is high and a drop hurts. To differentiate between these two, we set the Differentiated Service Code Point (DSCP) value in the pakcet. This is just the packet header thing I was talking about earlier.

Let me pause for a second to discuss something, though. Just tagging the packet does nothing to prioritize the packet. I can tag a packet with whatever I want, but, if a router or switch isn’t configured to use the tag, my packet just goes into the FIFO queue like everything else. Actually doing something different to a tagged packet is one of the many other parts of QoS that I may get to later.

Time to configure? Of course. Like everything in the Cisco world, it always usually starts with an access-list to define interesting traffic. You then create a class-map that defines what traffic you want to tag (usually with the ACL you created), then you create a policy-map that defines what to do with that traffic. Finally, you apply the policy-map to the interface.

Let’s try one. Let’s say we just put in a new VOIP system and want to tag the packets appropriately. The IP of the system is 10.0.0.10, and you want the gateway on that network to tag the packets as AF41 as they come into it (Google up DSCP if you want to learn about the AF41 thing). What comes first? The ACL…duh!. I like named ACLs, so we’ll create one called VOIP.

ip access-list extended VOIP
permit ip host 10.0.0.10 any

Time for the class-map. All that a class-map is used for is to create a list of values that are interesting to you, but a list can have an or or an and associated it. Basically, do you want to match all the items or just any of them. In our case, we just want to match the ACL we created (a single item), so it’s no big deal, but keep in mind that you can use the match-all or match-any keywords if you want. Here’s the class-map to match our ACL.

class-map match-any MYCLASSMAP
match access-group name VOIP

Next is what we want to do to the traffic, which is tag it to AF41. In the policy-map, you actually reference the class-map you made, so keep that in mind when you’re configuring.

policy-map MYPOLMAP
class MYCLASSMAP
set dscp af41

That says that anything that matches the class-map MYCLASSMAP gets tagged to AF41. Now we have to apply it to the gateway. Assuming that’s F0/0 of your router, give this a shot.

interface F0/0
service-policy input MYPOLMAP

That’s pretty much it. Now, when a packet lands on F0/0 that matches the ACL, it will be tagged as AF41 and sent on. I say again that this just tags packets. If you want to actually prioritize those packets, you have to do more, but I’m too sleepy to get into that right now.

• Leave a comment... (5)

I’ve had my ASA 5505 in place at home on my Comcast cable for a few weeks now, and, let me tell you, this thing rocks. I did, however, have a few problems finding a clear answer on how I could set up my VLANs. It turns out that the base license on the ASA 5505 comes with a few restrictions with regards to VLANning — in particular the number of VLANs and the number of trunks.

When you have the base license and the ASA is in routed mode (you have IPs on interfaces), you can have three VLANs configured. One of them, however, has to be configured to not forward to one of the other VLANs. I had to go over that a few times before I got what the doc was saying. Basically, you have two VLANs that are fully functional and one that can only initiate traffic to one of the others. At home, I consolidated my network down to three VLAN — outside (I’net), inside (Users), and a DMZ (Guests). The inside interface can initiate connections to both outside and the DMZ, but the DMZ can only talk to the outside VLAN. This is probably not a very big deal to an average user, but I’m a network guy and will add networks just to say I’ve got one more subnet than you do.

I also had some confusion over the number of trunks available on this guy. My Aironet 1231 is set up to tag multiple bridged VLANs to the Ethernet so that I could have multiple SSIDs on it with each in their own VLAN. I did this by making the switch port on the 2950 into a tagged trunk. With the base license on the 5505, you don’t get any trunks. I didn’t find any docs that said you couldn’t, but it’s pretty obvious from the “show version” info.

VLAN Trunk Ports : 0

This really puts a damper on my AP setup. I had to reconfigure it to just use a single, untagged bridged interface with a single SSID. If I wanted to implement the Aironet 1231 the way I had it beforehand, I would have to upgrade my license on the 5505. I’m not paying any more money for this thing, so I’ll have to get one of my lab APs in place for guests. Thank God for eBay.

So, how do you configure this thing? First, let decide on our VLANs — say VLANs 11, 12, and 13. The configuration is just like any PIX 7.X

interface Vlan11
description OUTSIDE
nameif outside
security-level 0
ip address dhcp setroute
!
interface Vlan12
description GUESTS
no forward interface Vlan13
nameif guests
security-level 10
ip address 192.168.13.1 255.255.255.0
!
interface Vlan13
description USER
nameif inside
security-level 100
ip address 192.168.14.1 255.255.255.0

The interface VLANs are what handles the IP addresses. We’ll put specific ports in the VLANs in a minute, so hold tight. The configuration is pretty self-explanatory with VLAN11 being the outside (I’net), VLAN 12 being the DMZ (guests), and VLAN13 being the inside (users).  There is, however, the one line that reads no forward interface Vlan13. This is the line  that makes dictates which VLAN is a DMZ with respect to the base license and that this VLAN (VLAN12) can’t initiate connections to VLAN13. You also might have noticed the line ip address dhcp setroute. You can read one of the earlier articles on that guy.

The last thing you do is to put ports in VLANs. The ports on the 5505 are labeled Ethernet0/0 - 7, and you treat them just like an IOS switch with the switchport access vlan X command. At home, you would plug your cable modem (or whatever) into one of the interfaces (say, Ethernet0/0) and put that port into VLAN11.

interface Ethernet0/0
switchport access vlan 11

Plug all your stuff in, put the ports in the right VLAN, and enjoy.

• Leave a comment... (1)

Believe it or not, I got a request for an article on how to configure GLBP. I’m as shocked as you are, so here it goes.

The Gateway Load Balancing Protocol (GLBP) is another Cisco-proprietary protocol for providing highly-available gateways on a network…but there’s a twist. GLBP, as you can figure out from the name, load-balances the traffic going through the participating routers. With HSRP and VRRP, one host is the active peer and handles all the traffic until it dies, then another peer takes over. With GLBP, all the routers accept traffic.

The key is the virtual MAC address. When you configure a router to use GLBP, it discovers all the other routers configured for GLBP, and an election is held. The winner is called the Active Virtual Gateway (AVG) and assigns virtual MAC addresses to all the members in the group (called Active Virtual Forwarders or AVFs). When a host on the network ARPs for the virtual IP, the AVG answers the request with one of the virtual MAC addresses of the AVFs. The next ARP request gets another virtual MAC, etc. Do this a few times, and the hosts are the network are splitting their traffic among all the AVFs.

Config time!

GLBP0(config)#interface f0/0
GLBP0(config-if)#ip address 192.168.0.10 255.255.255.0
GLBP0(config-if)#glbp 0 ip 192.168.0.1

GLBP1(config)#interface f0/0
GLBP1(config-if)#ip address 192.168.0.11 255.255.255.0
GLBP1(config-if)#glbp 0 ip 192.168.0.1

GLBP2(config)#interface f0/0
GLBP2(config-if)#ip address 192.168.0.12 255.255.255.0
GLBP2(config-if)#glbp 0 ip 192.168.0.1

Very simple. This sets the IP on f0/0 of three routers and enables GLBP group 0 for the IP 192.168.0.1. The group number, 0 in this case, is the same as in HSRP; you can have more than one instance of GLBP on an interface, so you have to tell it what settings go with what group.

After a few seconds of yelling at each other, the routers will have decided who the active and backup AVGs are, who the AVFs are, and what the virtual MACs for the AVFs are. After convergence, you can run the show glbp brief command to see what the status is.

GLBP0#sh glbp brief
Interface   Grp  Fwd Pri State    Address         Active router   Standby router
Fa0/0       0    -   100 Listen   192.168.0.1     192.168.0.12    192.168.0.11
Fa0/0       0    1   -   Listen   0007.b400.0001  192.168.0.12    -
Fa0/0       0    2   -   Active   0007.b400.0002  local           -
Fa0/0       0    3   -   Listen   0007.b400.0003  192.168.0.11    -

In our example, the IP 192.168.0.12 is the AVG (GLBP2) with 192.168.0.11 being the backup AVG (GLBP1). You can also see that three virtual MACs have been assigned — 0007.b400.001 - 3.

Those are the basics, but there are a few more things worth mentioning that you should look at on your own.

• By default, the load-balancing method is round robin, but you can set the GLBP balancing method to weighted, which uses configured weights on each router to determine who’s next in line for ARP replies. Use the load-balancing and weighting directives.
• You can set priorities for each router to better control which one becomes the AVG and backup AVG with the priority directive.
• You can have GLBP track objects just as you do with HSRP. Use the weighting track configuration to do so.
• You can put passwords on the GLBP group to protect yourself from random routers trying to participate and hose things up. Look at authentication.
• By default, a higher priority router won’t overthrow a lower one to become the AVG. You can turn this feature on with the preempt directive.

• Leave a comment... (1)

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)

GRE tunnels rock.  They are interfaces on a router that are used to “connect” to another router somewhere on your LAN, your WAN, the Internet, wherever.  The most popular use for them is for router-to-router VPNs.

I’ll let my friend Josh from blindhog.net show you how to do it.  He’s got a video on how to configure the tunnels, and another on how to set it up for VPN.

• Leave a comment... (0)

I was configuring a switch the other day and realized I had configured a trunk on the wrong port. God, I hate that. Instead of dumping the configuration for the port and doing a “no” on each line, I used the default command.

Switch(config)#default interface G0/1

This resets the configuration on interface G0/1 to how it was when Cisco shipped it to you. Much better than killing all the lines of the configuration one-at-a-time, eh?

Default can be used for all sorts of stuff, too. You can reset the configuration for CDP, AAA, NTP…pretty much anything. It can come in handy if you want to reset just one part of the config without touching everything else you’ve configured on the box.

• Leave a comment... (0)