Cisco | IPNET - Part 10

Cisco: How to configure HSRP for load-balancing traffic

I believe many of you are already familiar with the Hot Standby Router Protocol (HSRP), but just for the one that are not I will make a short review of this protocol.
Hot Standby Router Protocol (HSRP) is a Cisco proprietary redundancy protocol for establishing a fault-tolerant default gateway, and has been described in detail in RFC 2281. The Virtual Router Redundancy Protocol (VRRP) is a standards-based alternative to HSRP defined in IETF standard RFC 3768. The two technologies are similar in concept, but not compatible.

The protocol establishes a framework between network routers in order to achieve default gateway failover if the primary gateway should become inaccessible, in close association with a rapid-converging routing protocol like EIGRP or OSPF. HSRP sends its hello messages to the multicast address 224.0.0.2 (all routers) using UDP port 1985, to other HSRP-enabled routers, defining priority between the routers. The primary router with the highest configured priority will act as a virtual router with a pre-defined gateway IP and will respond to the ARP request from machines connected to the LAN with the mac address 0000.0c07.acXX where XX is the group ID. By sharing an IP address and a MAC (Layer 2) address, two or more routers can act as a single “virtual” router. The members of the virtual router group continually exchange status messages. This way, one router can assume the routing responsibility of another, should it go out of commission for either planned or unplanned reasons. Hosts continue to forward IP packets to a consistent IP and MAC address, and the changeover of devices doing the routing is transparent. If the primary router should fail, the router with the next-highest priority would take over the gateway IP and answer ARP requests with the same mac address, thus achieving transparent default gateway fail-over.

HSRP and VRRP on some routers have the ability to trigger a failover if one or more interfaces on the router go down. This can be useful for dual branch routers each with a single serial link back to the head end. If the serial link of the primary router goes down, you would want the backup router to take over the primary functionality and thus retain connectivity to the head end.

Now, as you probably know already, HSRP is not supporting by default load-balancing, meaning that only one router can be active in the virtual router group, and only that path is used for traffic leaving the other paths unused. In this way there is a waste on bandwidth, as only one router is used to forward traffic. In normal cases, I would recommend to use another protocol named Gateway Load Balancing Protocol (GLBP), that perform the same operation as HSRP with the additional load balance feature. Anyway since we are not talking about GLBP here, and load balance with HSRP can be a subject for some Cisco exams, read below how you can achieve this feature.

First please have a look at the topology used for this example. This will make things more clear for you. As you can see R1 and R2 are connected to the same network segment, so they can share the same subnet. Let configure R1 and R2 for a basic HSRP (without load balancing):

R1
interface FastEthernet0/0
ip address 10.10.12.1 255.255.255.0
standby 1 preempt
standby 1 ip 10.10.12.3
standby 1 priority 110

R2
interface FastEthernet0/0
ip address 10.10.12.2 255.255.255.0
standby 1 preempt
standby 1 ip 10.10.12.3

R1 is the active router for group 1 (priority 110, default 100), so all the traffic will flow through R1’s path. Following I will apply the configuration to migrate this default HSRP to Multigroup HSRP (MHSRP) which is load balance aware:

R1
interface FastEthernet0/0
ip address 10.10.12.1 255.255.255.0
standby 1 preempt
standby 1 ip 10.10.12.3
standby 1 priority 110
standby 2 preempt
standby 2 ip 10.10.12.4

R2
interface FastEthernet0/0
ip address 10.10.12.2 255.255.255.0
standby 1 preempt
standby 1 ip 10.10.12.3
standby 2 preempt
standby 2 ip 10.10.12.4
standby 2 priority 110

Now we have group 1 with R1 active (10.10.12.3) and group 2 with R2 active (10.10.12.4). Of course you will have to find a way to push to the clients the 2 gateways (10.10.12.3 and 10.10.12.4) or to configure them manually on your users machines, to really achieve the load balance feature with HSRP.

To see the live presentation of how MHSRP works please click on the image below:

Files needed for this tutorial: The topology

Cisco: How to achieve network redundancy with 2 interfaces

Sometime ago, during my preparation for Cisco CCIE certification, I encountered a task that I had to admit made me think a little bit, even I should see the solution from the first minute. The idea, at least as I see it, is that as much as you learn for some certification you start to see only the complex and painful part of the networking and this made me skip over the simplest solution. Something like, I learn to fly to the moon but I forget how to step on earth…

Before I start please have a look to this network topology. The task was having some statement that due to the monthly cost, R1 should use only one line (Frame-Relay) to communicate to the networks behind R2 (I took in this example Loopback0: 2.2.2.2 /32) and in case that the R1’s protocol interface to Frame-Relay cloud is going, the connection to R3 should become active and traffic should flow through there. The scope was to achive some redundancy from R1 to the rest of the network. As I said before the solution was much more simplest that I start initially to think of and you can see it immediately.

Regarding the routing since this is not the main point discussed here, I just add 2 static routes on R1 to 2.2.2.2; one route through R2 and another one through R3 (with higher distance metric). Of course I put the necessary static routes and tracking on R2 and R3.

One advice if you want to try this on your own with this topology. Do not manually shutdown the main interface to enable the backup one, as it will not work. For testing you have to find a way that the main interface is down, but not administratively down. This is just not to get angry that this method is not working.

Cisco: How to shape traffic on Frame-Relay connection

In some previous article, I explained how to configure a Frame-Relay Hub and Spoke network environment. Based on that example, I will show you today how you can implement traffic shaping over the Frame-Relay Hub and Spoke.You can have a look at the topology that we will use here.

A note from the beginning. Since I do not have a traffic generator, I cannot really prove that the traffic is shaped, you’ll just have to believe me or to try on your own.

Let’s assume that we have an excessive amount of packet loss between R1 and R2 from the topology and the R1 is overwhelming the Frame-Relay connection to R2. R1 has a port speed of 512Kbps and we have to assure that R1 is sending traffic at 384Kbps. In case that the connection get congested R1 should throttle down the CIR to 256Kbps. R1 should be permitted to burst in case it accumulate credit and to minimize the delay due to serialization the interval (Tc) should be 10ms.

To summarize:
-we have a CIR of 384Kbps; CIR = 384Kbps
-when congested CIR throttle down to 256Kbps; minCIR = 256 Kbps
-time interval is 10ms; Tc = 10ms
-burst size, based on the date above is 3840 bps; Bc=CIR*Tc=384000*0.01=3840; (note that CIR has to be in bps and time in seconds)
-also R1 is allowed to send burst in excess in case of accumulated credit, so excess burst is 1280 bps; Be=(AR-CIR)*Tc=(512000 – 384000) * 0.01=1280 (AR is the port speed 512Kbps)

After we have gathered all this data let’s proceed to the Cisco device configuration. Please see the presentation below:

Cisco: How to selective drop packets without using an access-list

The title actually was a request that I encounter during my CCIE RS preparation. Of course, that in the real world, I would go straight forward and implement an access-list do drop selected packets. But since the lab environment is different for the real one, you might get a task like the above one.

Let’s assume that we have a network topology with a central router (R1) that connects 2 routers (R2 and R3), like in a hub and spoke diagram. Communication between R2 and R3 is done through R1. In this environment routing is already functional, implemented by dynamic or static routing (actually doesn’t matter this is not a topic for this presentation) and R2 can reach R3. We will drop all packets from R2 to R3, but telnet related packets (just to do things a little bit more interesting). As I specified before all this has to be achieved without access-list implementation.

Please have a look to this topology, to have a clear picture of the network environment. After you have checked the topology, watch the video presentation below:

Cisco: How to use kron to automate tasks

Now and then everybody in IT network industry has to stay awake over the night to accomplish some tasks that cannot be performed during the work hours because will disturb regular activity. Some of this task usually need your presence in field (virtually or in place), to assure that everything is working fine and you don’t have any unwanted surprise the next day.Skipping this tasks, there are other ones with less impact in case of a failure, which I believe you rather prefer to do it automatically and to check the results when you can. I’m talking here usually about configuration save or archive, IP addresses being renew by DHCP or data backup

All this stuff can be achieved by using the Cisco “kron” present in the IOS. I think that everybody who’s ready this post heard about cron jobs, so I will issue just a small explanation. Cron jobs are tasks definite to run at one certain moment or to be recursive over a period of time. In human terms, cron jobs can help us sleep well why they are doing the job over the night.

Speaking now about Cisco “kron” command, you should know that it appear starting with IOS version 12.3(1), so don’t try to find it if you have a previous version installed. Also, The EXEC CLI specified in a Command Scheduler policy list must not generate a prompt or have the ability to be terminated using keystrokes. Command Scheduler is designed as a fully automated facility and no manual intervention is permitted. Command Scheduler allows you to schedule fully-qualified EXEC mode CLI commands to run once, at specified intervals, or at specified calendar dates and times.
Command Scheduler has two basic processes. A policy list is configured containing lines of fully-qualified EXEC CLI to be run at the same time or interval. One or more policy lists are then scheduled to run after a specified interval of time or at a specified calendar date and time. Each scheduled occurrence can be set to run once only or on a recurring basis. Policy lists can be configured after the policy list has been scheduled, but each policy list must be configured before it is scheduled to run. Policy lists consist of one or more lines of fully-qualified EXEC CLI commands. All commands in a policy list are executed when the policy list is run by Command Scheduler using the kron occurrence command. Use separate policy lists for CLI commands to be run at different times.

One mandatory tasks is that before you try to run “kron”, your Cisco device has to know the time. Either manully set or through NTP server. If the device does not know the time, than a warning message will appear when you’ll try to configure kron tasks.

Please see below some brief examples about how you can configure kron tasks.