GATEWAY REDUNDANCY

Introduction to Gateway RedundancyIn this lesson we’ll take a look at different protocols for gateway redundancy. So what is gateway redundancy and why do we need it? Let’s start with an example!

The network in the picture above is fairly simple. I have one computer connected to a switch. In the middle you’ll find two multilayer switches (SW1 and SW2) that both have an IP address that could be used as the default gateway for the computer. Behind SW1 and SW2 there’s a router that is connected to the Internet.

Which gateway should we configure on the computer? SW1 or SW2? You can only configure a one gateway after all…

If we pick SW1 and it crashes, the computer won’t be able to get out of its own subnet because it only knows about one default gateway. To solve this problem we will create a virtual gateway:

Between SW1 and SW2 we’ll create a virtual gateway with its own IP address, in my example this is 192.168.1.3.

The computer will use 192.168.1.3 as its default gateway. One of the switches will be the active gateway and in case it fails the other one will take over.

There are three different protocols than can create a virtual gateway:

HSRP (Hot Standby Routing Protocol) VRRP (Virtual Router Redundancy Protocol) GLBP (Gateway Load Balancing Protocol)In other lessons I will explain each of these protocols and show you how to configure them. For now, I hope this lesson has helped to understand why we need a virtual gateway in the network.

HSRP (Hot Standby Routing Protocol)In this lesson I will explain how HSRP (Hot Standby Routing Protocol) works and how to configure it. If you have no idea what virtual gateways are about then make sure to read my introduction lesson first.Here’s the topology I will use:

Here’s what we have:

SW1 and SW2 are multilayer switches. The 192.168.1.0/24 subnet belongs to VLAN 1 and there is one host device.

IP address 192.168.1.254 will be used for the virtual gateway address.

The multilayer switches are connected with layer three interfaces to an upstream router called R3.

The first thing we’ll do is enable HSRP. We will do this on the VLAN 1 interfaces of SW1 and SW2:

SW1 & SW2(config)#interface Vlan 1(config-if)#standby 1 ip 192.168.1.254

Use the standby command to configure HSRP. 192.168.1.254 will be the virtual gateway IP address. The “1” is the group number for HSRP. It doesn’t matter what you pick just make sure it’s the same on both devices. On your console you’ll see something like this:

SW1#%HSRP-5-STATECHANGE: Vlan1 Grp 1 state Standby -> Listen%HSRP-5-STATECHANGE: Vlan1 Grp 1 state Speak -> StandbySW2#%HSRP-5-STATECHANGE: Vlan1 Grp 1 state Standby -> Active

Depending on which switch you configured first you’ll see these messages. One of the switches will be the active gateway, the other one goes in standby mode. Let’s see if we can reach this virtual gateway from our host:

R1#ping 192.168.1.254Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 192.168.1.254, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 6/206/1007 ms

As you can see we can successfully reach the virtual gateway IP address.

That wasn’t too bad right? Only one command and HSRP works! There are a couple of other things we have to look at though. We use 192.168.1.254 as the virtual IP address but what MAC address will it use?

R1#show ip arp | include 1.254Internet 192.168.1.254 1 0000.0c07.ac01 ARPA GigabitEthernet0/1

You can see the MAC address of 192.168.1.254 in the ARP table, where did this MAC address come from?

0000.0c07.ac01 is the MAC address that we have. HSRP uses the 0000.0c07.acXX MAC address where XX is the HSRP group number. In my example I configured HSRP group number 1. There are a couple of other interesting things to check, take a look below:

SW1#show standby Vlan1 - Group 1 State is Standby 3 state changes, last state change 00:03:33 Virtual IP address is 192.168.1.254 Active virtual MAC address is 0000.0c07.ac01 (MAC Not In Use) Local virtual MAC address is 0000.0c07.ac01 (v1 default) Hello time 3 sec, hold time 10 sec Next hello sent in 0.144 secs Preemption disabled Active router is 192.168.1.2, priority 100 (expires in 7.776 sec) Standby router is local Priority 100 (default 100) Group name is "hsrp-Vl1-1" (default)SW2#show standby Vlan1 - Group 1 State is Active 2 state changes, last state change 00:04:25 Virtual IP address is 192.168.1.254 Active virtual MAC address is 0000.0c07.ac01 (MAC In Use) Local virtual MAC address is 0000.0c07.ac01 (v1 default) Hello time 3 sec, hold time 10 sec Next hello sent in 0.992 secs Preemption disabled Active router is local Standby router is 192.168.1.1, priority 100 (expires in 10.640 sec) Priority 100 (default 100) Group name is "hsrp-Vl1-1" (default)

Use the show standby command to verify your configuration. There’s a couple of interesting things here: We can see the virtual IP address here (192.168.1.254). It also shows the virtual MAC address (0000.0c07.ac01). You can see which router is active or in standby mode. The hello time is 3 seconds and the hold time is 10 seconds. Preemption is disabled.

The active router will respond to ARP requests from computers and it will be actively forwarding packets from them. It will send hello messages to the routers that are in standby mode. Routers in standby mode will listen to the hello messages, if they don’t receive anything from the active router they will wait for the hold time to expire before taking over. The hold time is 10 seconds by default which is pretty slow; we’ll see how to speed this up in a bit.Each HSRP router will go through a number of states before it ends up as an active or standby router, this is what will happen:

State Explanation

InitialThis is the first state when HSRP starts. You’ll see this just after you configured HSRP or when the interface just got enabled.

ListenThe router knows the virtual IP address and will listen for hello messages from other HSRP routers.

SpeakThe router will send hello messages and will join the election to see which router will become active or standby.

StandbyThe router didn’t become the active router but will keep sending hello messages. If the active router fails it will take over.

Active The router will actively forward packets from clients and sends hello messages.

We can see all these steps with a debug command. Let’s shut the VLAN 1 interfaces first so that we can restart HSRP:

SW1 & SW2(config)#interface Vlan 1(config-if)#shutdown

Now use the debug standby events command:

SW1 & SW2#debug standby events HSRP Events debugging is on

Now we will enable the VLAN 1 interface on SW1 first:

SW1(config)#interface Vlan 1(config-if)#no shutdown

Here’s what you will see on SW1:

SW1#HSRP: Vl1 Interface UP HSRP: Vl1 Starting minimum intf delay (1 secs) - uptime 997HSRP: Vl1 Intf min delay expired - uptime 998HSRP: Vl1 Grp 1 Init: a/HSRP enabledHSRP: Vl1 Grp 1 Init -> ListenHSRP: Vl1 Grp 1 Redundancy "hsrp-Vl1-1" state Init -> BackupHSRP: Vl1 IP Redundancy "hsrp-Vl1-1" update, Init -> BackupHSRP: Vl1 Grp 1 Listen: d/Standby timer expired (unknown)HSRP: Vl1 Grp 1 Listen -> SpeakHSRP: Vl1 Grp 1 Redundancy "hsrp-Vl1-1" state Backup -> SpeakHSRP: Vl1 IP Redundancy "hsrp-Vl1-1" update, Backup -> SpeakHSRP: Vl1 Grp 1 Speak: d/Standby timer expired (unknown)HSRP: Vl1 Grp 1 Standby router is localHSRP: Vl1 Grp 1 Speak -> StandbyHSRP: Vl1 Grp 1 Redundancy "hsrp-Vl1-1" state Speak -> StandbyHSRP: Vl1 IP Redundancy "hsrp-Vl1-1" standby, unknown -> localHSRP: Vl1 IP Redundancy "hsrp-Vl1-1" update, Speak -> StandbyHSRP: Vl1 Grp 1 Standby: c/Active timer expired (unknown)HSRP: Vl1 Grp 1 Active router is localHSRP: Vl1 Grp 1 Standby router is unknown, was localHSRP: Vl1 Grp 1 Standby -> ActiveHSRP: Vl1 Grp 1 Redundancy "hsrp-Vl1-1" state Standby -> ActiveHSRP: Vl1 Grp 1 Added 192.168.1.254 to ARP (0000.0c07.ac01)HSRP: Vl1 Grp 1 Activating MAC 0000.0c07.ac01HSRP: Vl1 Grp 1 Adding 0000.0c07.ac01 to MAC address filter - resetting the interfaceHSRP: Vl1 IP Redundancy "hsrp-Vl1-1" standby, local -> unknownHSRP: Vl1 IP Redundancy "hsrp-Vl1-1" update, Standby -> ActiveHSRP: Vl1 IP Redundancy "hsrp-Vl1-1" update, Active -> Active

Above you can clearly see the different states we go through before we end up in the active state. Right now SW1 is the only switch that is running HSRP so let’s enable the VLAN 1 interface of SW2 as well:

SW2(config)#interface Vlan 1SW2(config-if)#no shutdown

Here’s the debug output:

SW2#HSRP: Vl1 Grp 1 Active router is 192.168.1.1HSRP: Vl1 Nbr 192.168.1.1 createdHSRP: Vl1 Nbr 192.168.1.1 active for group 1HSRP: Vl1 Interface UP HSRP: Vl1 Starting minimum intf delay (1 secs) - uptime 1089HSRP: Vl1 Intf min delay expired - uptime 1090HSRP: Vl1 Grp 1 Init: a/HSRP enabledHSRP: Vl1 Grp 1 Init -> ListenHSRP: Vl1 Grp 1 Redundancy "hsrp-Vl1-1" state Init -> BackupHSRP: Vl1 IP Redundancy "hsrp-Vl1-1" update, Init -> BackupHSRP: Vl1 Grp 1 Listen: d/Standby timer expired (unknown)HSRP: Vl1 Grp 1 Listen -> SpeakHSRP: Vl1 Grp 1 Redundancy "hsrp-Vl1-1" state Backup -> SpeakHSRP: Vl1 IP Redundancy "hsrp-Vl1-1" update, Backup -> SpeakHSRP: Vl1 Grp 1 Speak: d/Standby timer expired (unknown)HSRP: Vl1 Grp 1 Standby router is localHSRP: Vl1 Grp 1 Speak -> StandbyHSRP: Vl1 Grp 1 Redundancy "hsrp-Vl1-1" state Speak -> StandbyHSRP: Vl1 IP Redundancy "hsrp-Vl1-1" standby, unknown -> localHSRP: Vl1 IP Redundancy "hsrp-Vl1-1" update, Speak -> Standby

Above we can see that SW2 is seeing 192.168.1.1 (SW1) as the active router. Eventually it ends up in the standby state.

Active Gateway Election

Why did SW2 go in standby mode instead of SW1?

By default the switch with the highest priority will become the active HSRP device. If the priority is the same then the highest IP address will be the tie-breaker. Let’s take a look at the priorities:

SW1#show standby | include Priority Priority 100 (default 100)SW2#show standby | include Priority Priority 100 (default 100)

The priority is the same on both switches, SW2 has a higher IP address so it should become the active router but it’s not. Let’s try increasing its priority:

SW2(config)#interface Vlan 1SW2(config-if)#standby 1 priority 150

Here’s how we can verify the new priority:

SW2#show standby | include Priority Priority 150 (configured 150)SW2#show standby | include Active Active virtual MAC address is 0000.0c07.ac01 (MAC Not In Use) Active router is 192.168.1.1, priority 100 (expires in 9.232 sec)

Even though SW2 has a higher priority, SW1 remains the active router. Another useful command to verify which router is active or standby is the show standby brief command:

SW1#show standby brief P indicates configured to preempt. |Interface Grp Pri P State Active Standby Virtual IPVl1 1 100 Active local 192.168.1.2 192.168.1.254SW2#show standby brief P indicates configured to preempt. |Interface Grp Pri P State Active Standby Virtual IPVl1 1 150 Standby 192.168.1.1 local 192.168.1.254

We can confirm SW2 has a higher priority but SW1 is still active. Once HSRP has decided which device should be active it will stay active until it goes down. We can overrule this if we want though…

Preemption

When we enable preemption the switch with the highest priority (or IP address in case the priority is the same) will always become the new active device. Here’s how to enable this:

SW1 & SW2(config)#interface Vlan 1(config-if)#standby 1 preempt

Let’s see if it makes any difference:

SW1#show standby brief P indicates configured to preempt. |Interface Grp Pri P State Active Standby Virtual IPVl1 1 100 P Standby 192.168.1.2 local 192.168.1.254SW2#show standby brief P indicates configured to preempt. |Interface Grp Pri P State Active Standby Virtual IPVl1 1 150 P Active local 192.168.1.1 192.168.1.254

There goes…SW2 is now active and SW1 goes to standby!

By default preemption will take effect immediately but it might be a good idea to use a delay. If a router or reboots it might need some time to “converge”. Maybe OSPF or EIGRP need to form neighbor adjacencies or spanning-tree isn’t ready yet unblocking ports. If you want to add a delay then you can do it like this:

SW1 & SW2(config)#interface Vlan 1(config-if)#standby 1 preempt delay minimum 60

This will delay the preemption by 60 seconds.

Authentication

HSRP also supports authentication. You can choose between plaintext or MD5 authentication. Here’s how to configure MD5:

SW1 & SW2(config)#interface Vlan 1(config-if)#standby 1 authentication md5 key-string MY_SECRET_KEY

This ensures that all packets sent between the two switches are authenticated. This prevents someone on the 192.168.1.0/24 subnet from joining our HSRP setup.

HSRP Timers

By default HSRP is pretty slow. SW1 is my standby router and it will wait for 10 seconds (hold time) before it will become active once SW2 fails. That means we’ll have 10 seconds of downtime…let’s see if we can speed that up:

SW1(config-if)#standby 1 timers ? <1-254> Hello interval in seconds msec Specify hello interval in milliseconds

We can speed things up by changing the timers with the standby timers command. We can even use millisecond values, let’s try that:

SW1 & SW2(config)#interface Vlan 1(config-if)#standby 1 timers msec 100 msec 300

I’ve set the hello time to 100 milliseconds and the hold timer to 300 milliseconds. Make sure your hold time is at least three times the hello timer. Let’s verify our work:

SW1#show standby | include time Hello time 100 msec, hold time 300 msecSW2#show standby | include time Hello time 100 msec, hold time 300 msec

HSRP Version 1 and 2

There are two versions of HSRP and depending on the router or switch model you might have the option to use HSRP version 2. You can change the version by using the standby version command.

HSRPv1 HSRPv2

Group Numbers 0 – 255 0 – 4095

Virtual MAC address

0000.0c07.acXX (XX = group number)

0000.0c9f.fxxx (XXX = group number)

Multicast Address 224.0.0.2 224.0.0.102

Let’s try switching our devices to HSRP version 2:

SW1 & SW2(config)#interface Vlan 1 (config-if)#standby version 2SW1#show standby | include versionVlan1 - Group 1 (version 2)

That’s all there is to it.

Interface Tracking

There is one more thing we need to look at and it’s called interface tracking. Take a look at the following picture:

In the picture above SW2 is the active router because we changed the priority to 150. That’s great but what if the interface on SW2 to R3 fails? It will be the active router but it doesn’t have a direct path to R3 anymore.

When this happens it will send an ICMP redirect to the computer. It would be better if SW1 becomes the active HSRP router in case this happens.

HSRP offers a feature called interface tracking. We can select an interface to track and if it fails we will give it a penalty. This way your priority will decrease and another device can become the active router.Make sure you have enabled preemption if you want to use interface tracking. Here’s an example:

SW2(config)track 1 interface GigabitEthernet 0/2 line-protocol

First we configure object tracking for the GigabitEthernet 0/2 interface. When the line-protocol changes (goes down) then the object state will change.

We can now use this object with HSRP:

SW2(config)#interface Vlan 1SW2(config-if)#standby 1 track 1 ? decrement Priority decrement shutdown Shutdown group

We can choose to decrement the priority or you can decide to shut the entire HSRP group in case the interface is down. Let’s try decrementing the priority:

SW2(config-if)#standby 1 track 1 decrement 60

Let’s try this out:

SW2(config)#interface GigabitEthernet 0/2SW2(config-if)#shutdown

Here’s what we will see on SW2:

SW2#%TRACK-6-STATE: 1 interface Gi0/2 line-protocol Up -> Down

The interface goes down so the state of our object changes. Let’s see if the priority has decreased:

SW2#show standby | include Priority

Priority 90 (configured 150)SW2#show standby | include Active Active virtual MAC address is 0000.0c9f.f001 (MAC Not In Use) Active router is 192.168.1.1, priority 100 (expires in 0.352 sec)

You can see the priority is now 90  instead of the 150 that we configured.You can see the priority is now 90 which is lower than SW1 (100). As a result SW2 will go to the standby state and SW1 will move to the active state. Interface tracking is useful but it will only check the state of the interface. It’s possible that the interface remains in the up state but that we are unable to reach R3. It might be a better idea to use IP SLA instead since it can check end-to-end connectivity.Let’s remove the current object tracking configuration:

SW2(config)#interface GigabitEthernet 0/2SW2(config-if)#no shutdownSW2(config-if)#no standby 1 track 1 decrement 60

And configure IP SLA to ping the IP address of R3:

SW2(config)#ip sla 1SW2(config-ip-sla)#icmp-echo 192.168.23.3SW2(config-ip-sla-echo)#frequency 10

SW2(config)#ip sla schedule 1 start-time now life forever

We can now combine IP SLA with object tracking:

SW2(config)#no track 1 SW2(config)#track 1 ip sla 1

And we’ll configure SW2 once again that the priority will decrease by 60 when the object is down:

SW2(config)#interface Vlan 1SW2(config-if)#standby 1 track 1 decrement 60

Let’s test our configuration. First we want to make sure that IP SLA is working:

SW2#show ip sla statistics

IPSLAs Latest Operation Statistics

IPSLA operation id: 1 Latest RTT: 3 millisecondsLatest operation start time: 13:31:57 UTC Thu Feb 18 2016Latest operation return code: OKNumber of successes: 7Number of failures: 0Operation time to live: Forever

IP SLA is up and running. Let’s shut the GigabitEthernet 0/2 interface on SW2 again so that IP SLA will fail:

SW2(config)#interface GigabitEthernet 0/2SW2(config-if)#shutdown

Let’s check the current priority:

SW2#show standby | include Priority Priority 90 (configured 150)

The priority has decreased which will cause SW1 to become the active router:

SW2#show standby | include Active Active virtual MAC address is 0000.0c9f.f001 (MAC Not In Use) Active router is 192.168.1.1, priority 100 (expires in 0.288 sec)

That’s all there is to it.

 

VRRP (Virtual Router Redundancy Protocol)VRRP (Virtual Router Redundancy Protocol) is very similar to HSRP (Hot Standby Routing Protocol) and can be used to create a virtual gateway. If you don’t know why we use virtual gateways then I suggest to read my Introduction to virtual gateways first. Also make sure you check the HSRP lesson first since many of the things I describe there also apply to VRRP.

VRRP is very similar to HSRP; if you understood HSRP you’ll have no trouble with VRRP which is a standard protocol defined by the IETF in RFC 3768. Configuration-wise it’s pretty much the same but there are a couple of differences.Let’s start with an overview:

  HSRP VRRP

Protocol Cisco proprietary IETF – RFC 3768

Number of groups 16 groups maximum 255 groups maximum

Active/Standby 1 active, 1 standby and multiple candidates.

1 active and several backups.

Virtual IP Address

Different from real IP addresses on interfaces

Can be the same as the real IP address on an interface.

Multicast address 224.0.0.2 224.0.0.18

Tracking Interfaces or Objects Objects

Timers Hello timer 3 seconds, hold time 10 seconds.

Hello timer 1 second, hold time 3 seconds.

Authentication Supported Not supported in RFC 3768

As you can see there are a number of differences between HSRP and VRRP. Nothing too fancy however. HSRP is a cisco proprietary protocol so you can only use it between Cisco devices.

Let’s see if we can configure it…

Configuration

This is the topology that I will use:

SW1 and SW2 are multilayer switches and their interfaces are configured as routed ports. We will create a virtual gateway using VRRP on the interfaces facing SW3:

SW1(config)#interface fa0/17SW1(config-if)#vrrp 1 ip 192.168.1.3SW1(config-if)#vrrp 1 priority 150SW1(config-if)#vrrp 1 authentication md5 key-string mykeySW2(config-if)#interface fa0/19SW2(config-if)#vrrp 1 ip 192.168.1.3SW2(config-if)#vrrp 1 authentication md5 key-string mykey

Here’s an example how to configure VRRP. You can see the commands are pretty much the same but I didn’t type “standby” but vrrp. I have changed the priority on SW1 to 150 and I’ve enabled MD5 authentication on both switches.

SW1#%VRRP-6-STATECHANGE: Fa0/17 Grp 1 state Init -> Backup%VRRP-6-STATECHANGE: Fa0/17 Grp 1 state Backup -> MasterSW2#%VRRP-6-STATECHANGE: Fa0/19 Grp 1 state Init -> Backup %VRRP-6-STATECHANGE: Fa0/19 Grp 1 state Backup -> Master %VRRP-6-STATECHANGE: Fa0/19 Grp 1 state Master -> Backup

You will see these messages pop-up in your console. VRRP uses different terminology than HSRP. SW1 has the best priority and will become the master router. SW2 will become a standby router. Let’s see what else we have:

SW1#show vrrp FastEthernet0/17 - Group 1 State is Master Virtual IP address is 192.168.1.3 Secondary Virtual IP address is 192.168.1.4 Virtual MAC address is 0000.5e00.0101 Advertisement interval is 1.000 sec Preemption enabled Priority is 150 Authentication MD5, key-string "mykey" Master Router is 192.168.1.1 (local), priority is 150 Master Advertisement interval is 1.000 sec Master Down interval is 3.414 secSW2#show vrrp FastEthernet0/19 - Group 1 State is Backup Virtual IP address is 192.168.1.3 Virtual MAC address is 0000.5e00.0101 Advertisement interval is 1.000 sec Preemption enabled

Priority is 100 Authentication MD5, key-string "mykey" Master Router is 192.168.1.1, priority is 150 Master Advertisement interval is 1.000 sec Master Down interval is 3.609 sec (expires in 3.065 sec)

Use show vrrp to verify your configuration. The output looks similar to HSRP; one of the differences is that VRRP uses another virtual MAC address:

0000.5e00.01XX (where X = group number)

SW1(config)#interface fa0/17SW1(config-if)#shutdown

We can shut the interface on SW1 so we can see that SW2 will take over.

SW1#%VRRP-6-STATECHANGE: Fa0/17 Grp 1 state Master -> InitSW2#%VRRP-6-STATECHANGE: Fa0/19 Grp 1 state Backup -> Master

Same principle…different terminology!

It is possible to configure load balancing for VRRP (or HSRP) but it doesn't work on a "per packet" schedule or something. Instead, we have to use multiple group numbers. Let me show what I'm talking about:

SW1(config)#interface fa0/17SW1(config-if)#vrrp 1 ip 192.168.1.3SW1(config-if)#vrrp 1 priority 150SW1(config-if)#vrrp 2 ip 192.168.1.4SW2(config-if)#interface fa0/19SW2(config-if)#vrrp 1 ip 192.168.1.3SW2(config-if)#vrrp 2 ip 192.168.1.4SW2(config-if)#vrrp 2 priority 150

I created two groups so we have two virtual IP addresses:

• 192.168.1.3 and 192.168.1.4 are both virtual IP addresses we can use as a gateway.• SW1 has the highest priority (150) for virtual IP address 192.168.1.3.• SW2 has the highest priority (150) for virtual IP address 192.168.1.4.

You can now use 192.168.1.3 and 192.168.1.4 as default gateways for your computers and SW1 and SW2 will share the load. You can use this like I did to have load balancing within a VLAN or you can do this on a per VLAN basis.

This is all I have on VRRP for now. I hope you enjoyed this lesson!

GLBP (Gateway Load Balancing Protocol)GLBP stands for Gateway Load Balancing Protocol and just like HSRP / VRRP it is used to create a virtual gateway that you can use for hosts. If you have no idea what a virtual gateway is then read my  Introduction to Gateway Redundancy  first. Also I would recommend to look at the HSRP   and VRRP   lessons before you continue with GLBP.One of the key differences of GLBP is that it can do load balancing without the group configuration that HSRP/VRRP use (what’s in a name right?).

Let’s take a closer look:

All devices running GLBP will elect an AVG (Active Virtual Gateway). There will be only one AVG for a single group running GLBP but other devices can take over this rule if the AVG fails. The role of the AVG is to assign a virtual MAC address to all other devices running GLBP. All devices will become an AVF (Active Virtual Forwarder) including the AVG. Whenever a computer sends an ARP Request the AVG will respond with one of the virtual MAC addresses of the available AVFs. Because of this mechanism all devices running GLBP will be used to forward IP packets.

There are multiple methods for load balancing:

Round-robin: the AVG will hand out the virtual MAC address of AVF1, then AVF2, AVF3 and gets back to AVF1 etc.

Host-dependent: A host will be able to use the same virtual MAC address of an AVF as long as it is reachable.

Weighted: If you want some AVFs to forward more traffic than others you can assign them a different weight.

Let’s take a look at a configuration example so you can see how this works.

Configuration

I will use the following topology to configure GLBP:

SW1 and SW2 are multilayer switches and their interfaces are routed ports. We will configure SW1 and SW2 so they create a virtual gateway for the hosts in the 192.168.1.0 /24 subnet. Let’s enable GLBP:

SW1(config)#interface f0/17SW1(config-if)#glbp 1 ip 192.168.1.3SW1(config-if)#glbp 1 priority 150SW2(config-if)#interface f0/19SW2(config-if)#glbp 1 ip 192.168.1.3

I’ll enable GLBP on SW1 and Sw2 using the same group number (1). I changed the priority on SW1 because I want it to be the AVG. Let’s see if this is working:

SW1#show glbp brief Interface Grp Fwd Pri State Address Active router Standby routerFa0/17 1 - 150 Active 192.168.1.3 local 192.168.1.2Fa0/17 1 1 - Active 0007.b400.0101 local -Fa0/17 1 2 - Listen 0007.b400.0102 192.168.1.2 -SW2#show glbp brief Interface Grp Fwd Pri State Address Active router Standby routerFa0/19 1 - 100 Standby 192.168.1.3 192.168.1.1 localFa0/19 1 1 - Listen 0007.b400.0101 192.168.1.1 -Fa0/19 1 2 - Active 0007.b400.0102 local -

Use the show glbp brief command to verify your configuration. There are a couple of things we can see here:• SW1 has become the AVG for group 1. SW2 (192.168.1.2) is standby for the AVG role and will take over in case SW1 fails and group1 has two AVFs:

1: SW1: Virtual MAC address 0007.b400.0101. 2: SW2: Virtual MAC address 0007.b400.0102.

The virtual MAC address that GLBP uses is 0007.b400.XXYY (where X = GLBP group number and Y = AVF number). Let’s take a look at the computers, I configured both to use the same IP address for the default gateway:

C:Documents and SettingsH1>ipconfig

Windows IP Configuration

Ethernet adapter Local Area Connection:

IP Address. . . . . . . . . . . . : 192.168.1.200 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.1.3

C:Documents and SettingsH2>ipconfig

Windows IP Configuration

Ethernet adapter Local Area Connection:

IP Address. . . . . . . . . . . . : 192.168.1.201 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.1.3

We can use our computers to check which virtual MAC address they use for their gateway:

C:Documents and SettingsH1>arp -a

Interface: 192.168.1.200--- 0x2 Internet Address Physical Address Type 192.168.1.3 00-07-b4-00-01-01 dynamicC:Documents and SettingsH2>arp -a

Interface: 192.168.1.201--- 0x2 Internet Address Physical Address Type 192.168.1.3 00-07-b4-00-01-02 dynamic

You can see H1 uses the virtual MAC address of SW1 (00-07-b4-00-01-01) while H2 uses the virtual MAC address of SW2 (00-07-b4-00-01-02) for the same IP address (192.168.1.3). This is how GLBP will load balance traffic from hosts. If you want you can configure things like preemption and authentication just like HSRP or VRRP :

SW1(config)#interface fa0/17SW1(config-if)#glbp 1 preempt SW1(config-if)#glbp 1 authentication md5 key-string mypassSW2(config)#interface fa0/19SW2(config-if)#glbp 1 preempt SW2(config-if)#glbp 1 authentication md5 key-string mypass

The configuration is the same but now you use the “glbp” command.

Interface tracking works differently for GLBP compared to HSRP or VRRP. HSRP/VRRP use a single threshold to determine which router is active/master. If you priority decreases and becomes lower than another device you’ll lose the active/master state and someone else takes over. GLBP works differently and has

a weighting mechanism. Weighting will be used to determine if a device can be AVF or not. Let's take a closer look at this:

In the picture above I have added another interface between R1 and SW2. Here’s what I want to do:

When one of the links fails it there is no problem so SW2 can remain as an AVF. When both links fails we have a problem and SW2 shouldn’t be an AVF anymore. I only want SW2 to become an AVF again once both links are operational again.

This is something we can do with GLBP, let me show you how:

SW2#show glbp | include Weighting Weighting 100 (default 100)

This is the default weighting of SW2 (100).

SW2(config)#track 16 interface fastEthernet 0/16 line-protocolSW2(config)#track 17 interface fastEthernet 0/17 line-protocol

First I will configure object tracking for interface FastEthernet 0/16 and 0/17.

SW2(config)#interface fa0/19SW2(config-if)#glbp 1 weighting track 16 decrement 20 SW2(config-if)#glbp 1 weighting track 17 decrement 20

Here’s how I configure tracking for GLBP. Whenever interface fa0/16 or fa0/17 goes down it should decrement the weight by 20.

SW2(config-if)#glbp 1 weighting 100 lower 70 upper 90

This is how we configure weighting; this is what it will do:

• The default weighting has a value of 100.• Once we fall below a weighting value of 70 SW2 will no longer be an AVF.• Once the weighting gets above 90 we will become an AVF once again.

Let’s see it in action!

SW2#show glbp | include Weighting Weighting 100 (configured 100), thresholds: lower 70, upper 90

Here are the values I just configured.

SW2(config)#interface fa0/16SW2(config-if)#shutdown

Let’s shut the fa0/16 interface.

SW2#show glbp | include Weighting

Weighting 80 (configured 100), thresholds: lower 70, upper 90

Our weighting is now down to 80 but still nothing has changed, we need to get below 70 before anything happens.

SW2(config)#interface fa0/17SW2(config-if)#shutdown

This will decrement our weighting once more with 20 which should get our weighting to a value of 60.

SW2#%GLBP-6-FWDSTATECHANGE: FastEthernet0/19 Grp 1 Fwd 2 state Active -> ListenSW2#show glbp | include Weighting Weighting 60, low (configured 100), thresholds: lower 70, upper 90

Our weighting is now 60 which lower than the “lower” value that we configured at 70. SW2 is no longer an AVF.

SW2(config)#interface fa0/16SW2(config-if)#no shutdown

Let’s bring one of the interfaces back to the land of the living…

SW2#show glbp | include Weighting Weighting 80, low (configured 100), thresholds: lower 70, upper 90

Nothing will change at this moment. Our weighting is 80 but we need to climb above the “upper” value of 90.

SW2(config)#interface fa0/17SW2(config-if)#no shutdown SW2#show glbp | include Weighting Weighting 100, low (configured 100), thresholds: lower 70, upper 90

Now our weighting is back to 100 and we exceeded the upper value of 90. We are back in the game!

SW2#%GLBP-6-FWDSTATECHANGE: FastEthernet0/19 Grp 1 Fwd 2 state Listen -> Active

You can see on the console that SW2 is once again an AVF. That's all we have on GLBP for now. I hope this lesson has been useful.

IP SLA (Service-Level Agreement) on Cisco IOSIP SLA (Service-Level Agreement) is a great feature on Cisco IOS devices that can be used to “measure” network performance.

This can be something simple like a ping where we check the round-trip time or something more advanced like a VoIP RTP packet where we check the delay, jitter and calculate a MOS score that gives you an indication what the voice quality will be like.

Measuring network performance is pretty cool but what makes IP SLA even more powerful is that you can combine it with static routes, policy based routing and routing protocols like OSPF or EIGRP.

Let me give you an example why this is a great feature to use. Take a look at the image below:

Above we have a customer router connected to two ISPs. Somewhere on the Internet there’s a server we’d like to reach. In a scenario like this, typically we use two default routes with different ADs. Whenever ISP1 fails, we switch over to ISP2.

The problem with this setup is that it’s not very reliable. The default route will be in the routing table as long as the interface is up and/or the next hop is reachable. It’s possible that ISP1 is having connectivity issues and unable to reach that remote server but we still use them for all our traffic.

To prevent this from happening we can combine default routes with IP SLA. Here’s an example:

Our customer router is now using IP SLA to ping the remote server. As long as we get a reply, we will keep using ISP1 as our main route. When the ping fails, we switch over to ISP2. This method is far more reliable as we check end-to-end connectivity.

Here’s another example where IP SLA might be useful:

Above we have two ISPs that we can use to reach a remote branch router. Instead of a simple ping, we can send RTP packets and check these for a certain delay, jitter and calculate a MOS score. When we get below a certain threshold we will switch from ISP1 to ISP2.

Each measurement that we do with IP SLA is called an operation. For each operation we have to configure the type of traffic, source IP, destination IP, port numbers, etc. We can then configure when to run the operation…24/7, 9-to-5, etc.When you use IP SLA for a simple ping then you only have to configure your local router. However when you want to use it for some more advanced things like sending RTP packets then you have to configure the remote router to respond to your IP SLA traffic.Besides pings and RTP, there are a lot of different operations we can use:

TCP Connections UDP DNS

DHCP HTTP FTP

Now you have an idea what IP SLA is about, let’s take a look how we can configure an operation.

Configuration

I will show you two examples so you will learn how to configure IP SLA operations. We’ll try an example with pings and an example with UDP jitter.

ICMP echo Operation

We will use the following topology:

All I need is two routers, R1 will send ICMP echo requests and R2 will reply to them. Here’s how to configure IP SLA:

R1(config)#ip sla 1R1(config-ip-sla)#?IP SLAs entry configuration commands: dhcp DHCP Operation dns DNS Query Operation ethernet Ethernet Operations exit Exit Operation Configuration ftp FTP Operation http HTTP Operation icmp-echo ICMP Echo Operation icmp-jitter ICMP Jitter Operation mpls MPLS Operation path-echo Path Discovered ICMP Echo Operation path-jitter Path Discovered ICMP Jitter Operation tcp-connect TCP Connect Operation udp-echo UDP Echo Operation udp-jitter UDP Jitter Operation

voip Voice Over IP Operation

First we have to choose an operation number, let’s pick number 1. You can see that there are a lot of different operations we can choose from. Let’s start with the icmp echo:

R1(config-ip-sla)#icmp-echo 192.168.12.2 R1(config-ip-sla-echo)#? IP SLAs Icmp Echo Configuration Commands: default Set a command to its defaults exit Exit operation configuration frequency Frequency of an operation history History and Distribution Data no Negate a command or set its defaults owner Owner of Entry request-data-size Request data size tag User defined tag threshold Operation threshold in milliseconds timeout Timeout of an operation tos Type Of Service verify-data Verify data vrf Configure IP SLAs for a VPN Routing/Forwarding instance

Let’s send ICMP echos to 192.168.12.2. There are a lot of optional parameters you can configure for an operation, for example let’s change the frequency:

R1(config-ip-sla-echo)#frequency 10

We’ll send an ICMP echo every 10 seconds. The only thing left to do is to start our IP SLA operation. This is how you do it:

R1(config)#ip sla schedule 1 ? ageout How long to keep this Entry when inactive life Length of time to execute in seconds recurring Probe to be scheduled automatically every day start-time When to start this entry <cr>

You have to use the ip sla schedule command to start your operation. You can schedule it but we will start our operation right now and let it run forever:

R1(config)#ip sla schedule 1 start-time ?

after Start after a certain amount of time from now hh:mm Start time (hh:mm) hh:mm:ss Start time (hh:mm:ss) now Start now pending Start pendingR1(config)#ip sla schedule 1 start-time now ? ageout How long to keep this Entry when inactive life Length of time to execute in seconds recurring Probe to be scheduled automatically every dayR1(config)#ip sla schedule 1 start-time now life ? <0-2147483647> Life seconds (default 3600) forever continue running foreverR1(config)#ip sla schedule 1 start-time now life forever

It should now be up and running. You can check your IP SLA configuration like this:

R1#show ip sla configuration IP SLAs Infrastructure Engine-IIIEntry number: 1Owner: Tag: Operation timeout (milliseconds): 5000Type of operation to perform: icmp-echoTarget address/Source address: 192.168.12.2/0.0.0.0Type Of Service parameter: 0x0Request size (ARR data portion): 28Verify data: NoVrf Name: Schedule: Operation frequency (seconds): 10 (not considered if randomly scheduled) Next Scheduled Start Time: Start Time already passed Group Scheduled : FALSE Randomly Scheduled : FALSE Life (seconds): Forever Entry Ageout (seconds): never Recurring (Starting Everyday): FALSE Status of entry (SNMP RowStatus): ActiveThreshold (milliseconds): 5000Distribution Statistics: Number of statistic hours kept: 2 Number of statistic distribution buckets kept: 1 Statistic distribution interval (milliseconds): 20Enhanced History:History Statistics: Number of history Lives kept: 0 Number of history Buckets kept: 15

History Filter Type: None

Above you can see the details of our IP SLA operation. A lot of parameters are configured by default. This is how you can check if it's running or not:

R1#show ip sla statistics IPSLAs Latest Operation Statistics

IPSLA operation id: 1Latest RTT: 1 milliseconds

Latest operation start time: 13:51:18 UTC Tue Jul 7 2015Latest operation return code: OKNumber of successes: 5Number of failures: 1Operation time to live: Forever

Use the show ip sla statistics command to see the results. You can see my pings are successful and our round trip time is only 1 ms.

Let's try another example!

UDP Jitter Operation

We'll use the same topology:

This time we'll use UDP packets to simulate G711 VoIP traffic. Let's start another operation:

R1(config)#ip sla 2R1(config-ip-sla)#udp-jitter 192.168.12.2 16384 codec g711alaw R1(config-ip-sla-jitter)#frequency 60R1(config-ip-sla-jitter)#tos 184

For this operation I used destination 192.168.12.2 and source port 16384. The codec is G711alaw. We'll send a probe every 60 seconds and the TOS byte is 184 (equals DSCP 46 or EF). Let's start it:

R1(config)#ip sla schedule 2 life forever start-time now

This finishes our configuration on R1 but we still have something to do on R2:

R2(config)#ip sla responder

The ip sla responder command is required on R2 otherwise it will drop our UDP packets. Let's verify our work:

R1#show ip sla configuration 2IP SLAs Infrastructure Engine-IIIEntry number: 2Owner: Tag: Operation timeout (milliseconds): 5000Type of operation to perform: udp-jitterTarget address/Source address: 192.168.12.2/0.0.0.0Target port/Source port: 16384/0Type Of Service parameter: 0xB8Codec Type: g711alawCodec Number Of Packets: 1000Codec Packet Size: 172Codec Interval (milliseconds): 20Advantage Factor: 0Verify data: NoVrf Name: Control Packets: enabledSchedule: Operation frequency (seconds): 60 (not considered if randomly scheduled) Next Scheduled Start Time: Start Time already passed Group Scheduled : FALSE Randomly Scheduled : FALSE Life (seconds): Forever Entry Ageout (seconds): never Recurring (Starting Everyday): FALSE Status of entry (SNMP RowStatus): ActiveThreshold (milliseconds): 5000Distribution Statistics: Number of statistic hours kept: 2 Number of statistic distribution buckets kept: 1

Statistic distribution interval (milliseconds): 20Enhanced History:

Above you can see the complete configuration for this operation. If you want to see the statistics, take a look below:

R1#show ip sla statistics 2IPSLAs Latest Operation Statistics

IPSLA operation id: 2Type of operation: udp-jitter

Latest RTT: 2 millisecondsLatest operation start time: 14:21:27 UTC Tue Jul 7 2015Latest operation return code: OKRTT Values:

Number Of RTT: 1000 RTT Min/Avg/Max: 2/2/3 millisecondsLatency one-way time:

Number of Latency one-way Samples: 0Source to Destination Latency one way Min/Avg/Max: 0/0/0

millisecondsDestination to Source Latency one way Min/Avg/Max: 0/0/0

millisecondsJitter Time:

Number of SD Jitter Samples: 999Number of DS Jitter Samples: 999Source to Destination Jitter Min/Avg/Max: 0/1/1 millisecondsDestination to Source Jitter Min/Avg/Max: 0/1/1 milliseconds

Packet Loss Values:Loss Source to Destination: 0Source to Destination Loss Periods Number: 0Source to Destination Loss Period Length Min/Max: 0/0Source to Destination Inter Loss Period Length Min/Max: 0/0

Loss Destination to Source: 0Destination to Source Loss Periods Number: 0Destination to Source Loss Period Length Min/Max: 0/0Destination to Source Inter Loss Period Length Min/Max: 0/0Out Of Sequence: 0 Tail Drop: 0Packet Late Arrival: 0 Packet Skipped: 0

Voice Score Values:Calculated Planning Impairment Factor (ICPIF): 1MOS score: 4.34

Number of successes: 2Number of failures: 1Operation time to live: Forever

Above you can see our results, how often these probes have been sent and at the bottom you can see the MOS score which was calculated. This is based on a scale from 1 - 5 so 4.34 is pretty good.

.

Conclusion

You have now seen how you can use IP SLA operations to measure your network performance. In other lessons I will show you how you can combine IP SLA with static routes, PBR and a routing protocol.

IP SLA with static routes IP SLA with RIP IP SLA with PBR

If you have any questions, feel free to leave a comment!

Reliable Static Routing with IP SLA

IP SLA is a great tool on Cisco routers that allows us to generate traffic which can be used to check delay/latency, jitter but can also be combined with object tracking. This allows us to check the reachability of a certain IP address (by pinging) or a certain service by connecting to it (using TCP). If the IP address/service is unreachable we can apply a certain action. A simple example to demonstrate IP SLA is when you have a single router that is connected to two ISPs:

Above we have a router (R1) that is connected to two ISPs. We want to use ISP1 as the primary and ISP2 as the backup link. All traffic will be sent towards ISP1 but when it’s unreachable we’ll switch over to ISP2. You can achieve this by using two default routes:

R1(config)#ip route 0.0.0.0 0.0.0.0 192.168.12.2R1(config)#ip route 0.0.0.0 0.0.0.0 192.168.13.3 2

By default a static route has an AD (Administrative Distance) of 1, that’s why I configured the second static route towards ISP2 to have an AD of 2. Having a static route with a higher administrative distance is also called a floating static route. When we look at the routing table of R1 this is what you’ll see:

R1#show ip route static S* 0.0.0.0/0 [1/0] via 192.168.12.2

Above you will only see the route towards ISP1 because it has a lower AD. Now let’s shut the interface towards ISP1 to see what will happen with the routing table:

R1(config)#interface fa0/0R1(config-if)#shutdownR1(config-if)#exit

This is what you will find:

R1#show ip route static S* 0.0.0.0/0 [2/0] via 192.168.13.3

Now everything will be sent towards ISP2 which is great. This solution is quick and simple but it has some potential problems…a static route will always remain in the routing table unless the interface goes down. It’s possible that the link towards ISP1 is up and running but that the ISP1 router itself is unreachable or that ISP1 has problems on their network that prevents us from reaching the Internet through them. This is why we’ll use IP SLA to make our default route more reliable. First let’s unshut the interface:

R1(config)#interface fa0/0R1(config-if)#no shutdown

I will create an IP SLA instance that pings the IP address of the ISP1 router:

R1(config)#ip sla 1R1(config-ip-sla)#icmp-echo 192.168.12.2 R1(config-ip-sla-echo)#timeout 100R1(config-ip-sla-echo)#frequency 1R1(config-ip-sla-echo)#exitR1(config)#ip sla schedule 1 start-time now life forever

We will ping IP address 192.168.12.2 each second and when we don’t get a response within 100 Ms we will believe it’s unreachable. You might want to play with these values a bit on a production network. Let’s see if IP SLA works:

R1#show ip sla statistics

Round Trip Time (RTT) for Index 1Latest RTT: 4 milliseconds

Latest operation start time: *00:09:07.235 UTC Fri Mar 1 2002Latest operation return code: OKNumber of successes: 43Number of failures: 1Operation time to live: Forever

It seems to be working, right now it only takes 4 milliseconds to get a response. As long as it stays below 100 milliseconds we’ll be fine. Let’s configure the default route to use IP SLA:

R1(config)#no ip route 0.0.0.0 0.0.0.0 192.168.12.2R1(config)#ip route 0.0.0.0 0.0.0.0 192.168.12.2 track 1

First I’ll remove the old default route and replace it with one that says “track 1”. I can’t connect IP SLA directly with the static route, I have to do this with object tracking. This is how you combine object tracking with IP SLA:

R1(config)#track 1 rtr 1

The command above combines object tracking instance 1 with the IP SLA instance that I configured. Let's see if this will work...

R1#show ip route static S* 0.0.0.0/0 [1/0] via 192.168.12.2

Right now everything is working as it should, we use ISP1 for the default route. Curious what happens once ISP1 becomes unreachable?

ISP1(config)#interface fastEthernet 0/0ISP1(config-if)#shutdown

We'll shut the interface on ISP1 and this is what you will find on R1:

R1#%TRACKING-5-STATE: 1 rtr 1 state Up->Down

Object tracking will kick in because we are no longer able to ping the IP address of ISP1. This is what you'll see in the routing table:

R1#show ip route static S* 0.0.0.0/0 [2/0] via 192.168.13.3

We now send all traffic towards ISP2. What will happen once ISP1 is reachable again?

ISP1(config)#interface fastEthernet 0/0ISP1(config-if)#no shutdown

Bring back the interface to the land of the living and this is what you'll discover on R1:

R1#%TRACKING-5-STATE: 1 rtr 1 state Down->Up

Object tracking tells us that we can reach ISP1 again and the routing table will be updated:

R1#show ip route static S* 0.0.0.0/0 [1/0] via 192.168.12.2

There we go, ISP1 is being used again as the primary ISP.

Instead of pinging the ISP's router IP address it might be a better idea to ping something on the Internet or to configure IP SLA to connect to a device using TCP. Pinging the ISP proves that we can reach the ISP but doesn't necessarily mean that we can reach the Internet.