Cisconinja’s Blog

HSRP/VRRP/GLBP Misconfigurations

Posted by Andy on February 24, 2009

In this post, we will look at what happens when HSRP, VRRP, and GLBP are misconfigured (or attacked) in different ways.  The three different misconfigurations we will look at for each protocol are mismatched virtual IP address, mismatched group numbers, and mismatched authentication.  The topology is shown below:

hsrp-misconfiguration-topology1

SW3 is a router with NM-16ESW acting as a layer-2 switch.  Host4 and Host5 are both routers acting as hosts on the network.  Each device will be configured with IP 10.1.1.X and MAC address 0000.0000.000X where X is the device number for the sake of clarity:

R1:
interface FastEthernet0/0
 mac-address 0000.0000.0001
 ip address 10.1.1.1 255.255.255.0

R2:
interface FastEthernet0/0
 mac-address 0000.0000.0002
 ip address 10.1.1.2 255.255.255.0

R4:
interface FastEthernet0/0
 mac-address 0000.0000.0004
 ip address 10.1.1.4 255.255.255.0
!
no ip routing
ip default-gateway 10.1.1.101

R5:
interface FastEthernet0/0
 mac-address 0000.0000.0005
 ip address 10.1.1.5 255.255.255.0
!
no ip routing
ip default-gateway 10.1.1.101

The MAC address table after generating some traffic from each device and prior to enabling any first hop redundancy protocols is shown below:

1-mac-table

Now we will look at each of the different scenarios, starting with HSRP.

 

 

HSRP IP Mismatch

 

Virtual IP

Group #

Virtual MAC

Authentication

R1

10.1.1.101

1

0000.0c07.ac01

R2

10.1.1.102

1

0000.0c07.ac01

 

R1:
interface FastEthernet0/0
 standby 1 ip 10.1.1.101

R2:
interface FastEthernet0/0
 standby 1 ip 10.1.1.102

If both routers are configured at approximately the same time, R2 becomes active because of it’s higher IP address and R1 becomes standby:

1-hsrp-brief-r1

1-hsrp-brief-r2

R1 generates the following log message, but still continues to accept R2 as the active router:

R1:
*Mar 1 03:31:16.919: %HSRP-4-DIFFVIP1: FastEthernet0/0 Grp 1 active routers virtual IP address 10.1.1.102 is different to the locally configured address 10.1.1.101

SW3 learns the HSRP virtual MAC address on F1/2 since only R2 sources traffic from that address:

1-mac-table2

10.1.1.102 is reachable to any hosts on the network, however 10.1.1.101 is not because R1 does not respond to it while in standby.

1-hsrp-ping-r2

1-hsrp-ping-r11

If 10.1.1.101 had been the correct gateway address for hosts to use, it would no longer be reachable.

 

 

HSRP Group Number Mismatch:

 

Virtual IP

Group #

Virtual MAC

Authentication

R1

10.1.1.101

1

0000.0c07.ac01

R2

10.1.1.101

2

0000.0c07.ac02

 

R1:
interface FastEthernet0/0
 standby 1 ip 10.1.1.101

R2:
interface FastEthernet0/0
 standby 2 ip 10.1.1.101

This time R1 and R2 ignore each other’s hellos and both routers become active:

2-hsrp-brief-r1

2-hsrp-brief-r2

When transitioning to active, HSRP broadcasts gratuitous ARP messages:

R2#debug arp
*Mar 1 03:53:30.955: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 2 state Standby -> Active
*Mar 1 03:53:30.955: IP ARP: sent rep src 10.1.1.101 0000.0c07.ac02,
dst 10.1.1.101 ffff.ffff.ffff FastEthernet0/0
*Mar 1 03:53:30.959: IP ARP: sent rep src 10.1.1.101 0000.0c07.ac02,
dst 10.1.1.101 0100.0ccd.cdcd FastEthernet0/0

After hearing each other’s gratuitous ARPs, each router generates a log message reporting a duplicate IP address and broadcasts another gratuitous ARP in an attempt to fix the ARP cache of other devices on the network which may have been changed by the other router’s gratuitous ARP:

R1#debug arp
*Mar 1 03:53:31.035: IP ARP: rcvd rep src 10.1.1.101 0000.0c07.ac02, dst 10.1.1.101 FastEthernet0/0
*Mar 1 03:53:31.039: %IP-4-DUPADDR: Duplicate address 10.1.1.101 on FastEthernet0/0, sourced by 0000.0c07.ac02
*Mar 1 03:53:31.039: IP ARP: sent rep src 10.1.1.101 0000.0c07.ac01,
dst 10.1.1.101 ffff.ffff.ffff FastEthernet0/0
*Mar 1 03:53:31.043: IP ARP: sent rep src 10.1.1.101 0000.0c07.ac01,
dst 10.1.1.101 0100.0ccd.cdcd FastEthernet0/0

This results in gratuitous ARP broadcasts continually being sent by R1 and R2 in response to receiving each other’s gratuitous ARPs.  It appears that IOS limits gratuitous ARPs to 1 per second based on the ARP debug messages shown below.  R2 receives a gratuitous ARP from R1 at 47.631.  At the same time, a message is shown immediately after it that a gratuitous ARP was throttled and 10.1.1.101 was added to arp_defense_Q.  At 48.207, another debug message shows that 10.1.1.101 was removed from arp_defense_Q and the gratuitous ARP is broadcast using R2’s virtual MAC as the source.  Another gratuitous ARP is received from R1 shortly after that, and R2 again throttles it and waits to send it’s own gratuitous ARP until 49.207 – exactly 1 second after it sent the previous one.  This pattern continues on each router:

R2:
*Mar 1 03:53:47.631: IP ARP: rcvd rep src 10.1.1.101 0000.0c07.ac01, dst 10.1.1.101 FastEthernet0/0
*Mar 1 03:53:47.631: IP ARP: Gratuitous ARP throttled.
*Mar 1 03:53:47.635: IP ARP: 10.1.1.101 added to arp_defense_Q
*Mar 1 03:53:48.207: IP ARP: 10.1.1.101 removed from arp_defense_Q
*Mar 1 03:53:48.207: IP ARP: sent rep src 10.1.1.101 0000.0c07.ac02,
dst 10.1.1.101 ffff.ffff.ffff FastEthernet0/0
*Mar 1 03:53:48.211: IP ARP: sent rep src 10.1.1.101 0000.0c07.ac02,
dst 10.1.1.101 0100.0ccd.cdcd FastEthernet0/0
*Mar 1 03:53:48.371: IP ARP: rcvd rep src 10.1.1.101 0000.0c07.ac01, dst 10.1.1.101 FastEthernet0/0
*Mar 1 03:53:48.375: IP ARP: Gratuitous ARP throttled.
*Mar 1 03:53:48.375: IP ARP: 10.1.1.101 added to arp_defense_Q
*Mar 1 03:53:49.207: IP ARP: 10.1.1.101 removed from arp_defense_Q
*Mar 1 03:53:49.207: IP ARP: sent rep src 10.1.1.101 0000.0c07.ac02,
dst 10.1.1.101 ffff.ffff.ffff FastEthernet0/0
*Mar 1 03:53:49.211: IP ARP: sent rep src 10.1.1.101 0000.0c07.ac02,
dst 10.1.1.101 0100.0ccd.cdcd FastEthernet0/0
*Mar 1 03:53:49.739: IP ARP: rcvd rep src 10.1.1.101 0000.0c07.ac01, dst 10.1.1.101 FastEthernet0/0
*Mar 1 03:53:49.739: IP ARP: Gratuitous ARP throttled.
*Mar 1 03:53:49.739: IP ARP: 10.1.1.101 added to arp_defense_Q
*Mar 1 03:53:50.207: IP ARP: 10.1.1.101 removed from arp_defense_Q
*Mar 1 03:53:50.207: IP ARP: sent rep src 10.1.1.101 0000.0c0c7.ac02,
dst 10.1.1.101 ffff.ffff.ffff FastEthernet0/0
*Mar 1 03:53:50.211: IP ARP: sent rep src 10.1.1.101 0000.0c07.ac02,
dst 10.1.1.101 0100.0ccd.cdcd FastEthernet0/0

As a result, hosts on the network continually update their ARP cache twice per second:

Host4#debug arp
*Mar 1 03:58:35.426: IP ARP: rcvd rep src 10.1.1.101 0000.0c07.ac01, dst 10.1.1.101 FastEthernet0/0
*Mar 1 03:58:36.338: IP ARP: rcvd rep src 10.1.1.101 0000.0c07.ac02, dst 10.1.1.101 FastEthernet0/0
*Mar 1 03:58:36.402: IP ARP: rcvd rep src 10.1.1.101 0000.0c07.ac01, dst 10.1.1.101 FastEthernet0/0
*Mar 1 03:58:37.314: IP ARP: rcvd rep src 10.1.1.101 0000.0c07.ac02, dst 10.1.1.101 FastEthernet0/0
*Mar 1 03:58:37.462: IP ARP: rcvd rep src 10.1.1.101 0000.0c07.ac01, dst 10.1.1.101 FastEthernet0/0

2-hsrp-host4-sharp1

SW3 learns each of the virtual MACs on the interfaces they are received and the table stays the same over time since R1 and R2 use separate virtual MACs:

2-mac-table

Any traffic that hosts send to a remote network with the virtual IP configured as their gateway will end up being split between the 2 routers (whichever router’s virtual MAC is currently in the hosts ARP cache at that moment will receive the frame).

 

 

HSRP Authentication Mismatch:

 

Virtual IP

Group #

Virtual MAC

Authentication

R1

10.1.1.101

1

0000.0c07.ac01

cisco1

R2

10.1.1.101

1

0000.0c07.ac01

cisco2

 

R1:
interface FastEthernet0/0
 standby 1 ip 10.1.1.101
 standby 1 authentication cisco1

R2:
interface FastEthernet0/0
 standby 1 ip 10.1.1.101
 standby 1 authentication cisco2

Again R1 and R2 both become active and do not recognize a standby router for the group:

3-hsrp-brief-r1

3-hsrp-brief-r2

Also the following log message shows up on each router:

R1:
*Mar 1 04:07:03.226: %HSRP-4-BADAUTH: Bad authentication from 10.1.1.2, group 1, remote state Active

Since both routers use the same virtual IP and virtual MAC, they do not generate gratuitous ARPs in response to receiving a gratuitous ARP from the other router.  However, since SW3 receives HSRP hellos sourced from the virtual MAC by both routers, the MAC address flaps back and forth between interfaces as often as R1 and R2 send HSRP hellos (or more if they send other traffic):

3-mac-table

Again, any traffic that hosts send to a remote network with the virtual IP configured as their gateway ends up being split between the 2 routers depending on which interface the virtual MAC address was last learned out of by the switch at the moment a frame is received from a host.

 

 

VRRP IP Mismatch

 

Virtual IP

Group #

Virtual MAC

Authentication

R1

10.1.1.101

1

0000.5e00.0101

R2

10.1.1.102

1

0000.5e00.0101

 

R1:
interface FastEthernet0/0
 vrrp 1 ip 10.1.1.101

R2:
interface FastEthernet0/0
 vrrp 1 ip 10.1.1.102

Unlike when HSRP was configured with different virtual IPs and only 1 became active, both VRRP routers think that they are the master:

4-vrrp-brief-r1

4-vrrp-brief-r2

Since both use the same group number and therefore the same virtual MAC, the MAC flaps back and forth between interfaces on SW3:

4-mac-table

If a host attempts to send traffic to a remote network, all traffic makes it to the destination and back (as long as both routers have a route to it) even though the host is unknowingly sending half of the traffic to a router that is using a different IP than it’s configured gateway address:

4-vrrp-ping-remote

However if the host attempts to send traffic to the gateway address itself, some of the traffic will be dropped:

4-vrrp-ping-gateway

Some of the traffic will be sent to R2 because of the virtual MAC address flapping between interfaces on SW3.  R2 knows that the destination address (10.1.1.101) is on the same subnet where it was received, so R2 sends an ICMP redirect to Host4.  It also thinks that the MAC address being used for 10.1.1.101 by Host4 is incorrect since it is R2’s virtual MAC address, so it sends an ARP request for the destination address:


R2#debug ip icmp
R2#debug arp

*Mar 1 05:58:47.966: ICMP: redirect sent to 10.1.1.4 for dest 10.1.1.101, use gw 10.1.1.101
*Mar 1 05:58:47.966: IP ARP: sent req src 10.1.1.2 0000.0000.0002,
dst 10.1.1.101 0000.0000.0000 FastEthernet0/0

The ICMP redirect tells Host4 to use gateway 10.1.1.101 to reach 10.1.1.101 – not very helpful to Host4, but R2 doesn’t realize that Host4 already thought it was sending directly to 10.1.1.101.  After receiving the ICMP redirect from R2, Host4 also sends out an ARP request for 10.1.1.101.  R1 replies to both ARP requests:


R1#debug arp
*Mar 1 05:58:48.002: IP ARP: rcvd req src 10.1.1.2 0000.0000.0002, dst 10.1.1.101 FastEthernet0/0
*Mar 1 05:58:48.002: IP ARP: sent rep src 10.1.1.101 0000.5e00.0101,
dst 10.1.1.2 0000.0000.0002 FastEthernet0/0
*Mar 1 05:58:49.934: IP ARP: rcvd req src 10.1.1.4 0000.0000.0004, dst 10.1.1.101 FastEthernet0/0
*Mar 1 05:58:49.938: IP ARP: sent rep src 10.1.1.101 0000.5e00.0101,
dst 10.1.1.4 0000.0000.0004 FastEthernet0/0

Neither of the ARP replies are helpful.  R2 uses the same MAC for it’s virtual MAC, so it does not add the entry to it’s ARP cache.  R1 receives the same destination MAC address that it already was using for 10.1.1.101.  Host4 continues trying to use the same MAC to reach 10.1.1.101, and the cycle will continue with only some of the traffic making it to R1 because some of it is switched incorrectly at SW3.

 

 

VRRP Group Number Mismatch

 

Virtual IP

Group #

Virtual MAC

Authentication

R1

10.1.1.101

1

0000.5e00.0101

R2

10.1.1.101

2

0000.5e00.0102

 

R1:
interface FastEthernet0/0
 vrrp 1 ip 10.1.1.101

R2:
interface FastEthernet0/0
 vrrp 2 ip 10.1.1.101

A group number mismatch in VRRP behaves identically to a group number mismatch in HSRP.  R1 and R2 ignore each other’s hellos and both routers become master:

 5-vrrp-brief-r1

5-vrrp-brief-r2

When transitioning to master, VRRP broadcasts gratuitous ARP messages:

R2#debug arp
*Mar 1 06:28:37.346: %VRRP-6-STATECHANGE: Fa0/0 Grp 2 state Backup -> Master
*Mar 1 06:28:37.346: IP ARP: sent rep src 10.1.1.101 0000.5e00.0102,
dst 10.1.1.101 ffff.ffff.ffff FastEthernet0/0
*Mar 1 06:28:37.350: IP ARP: sent rep src 10.1.1.101 0000.5e00.0102,
dst 10.1.1.101 0100.0ccd.cdcd FastEthernet0/0

After hearing each other’s gratuitous ARPs, each router generates a log message reporting a duplicate IP address and broadcasts another gratuitous ARP in an attempt to fix the ARP cache of other devices on the network which may have been changed by the other router’s gratuitous ARP:

R1#debug arp
*Mar 1 06:28:37.366: IP ARP: rcvd rep src 10.1.1.101 0000.5e00.0102, dst 10.1.1.101 FastEthernet0/0
*Mar 1 06:28:37.366: %IP-4-DUPADDR: Duplicate address 10.1.1.101 on FastEthernet0/0, sourced by 0000.5e00.0102
*Mar 1 06:28:37.370: IP ARP: sent rep src 10.1.1.101 0000.5e00.0101,
dst 10.1.1.101 ffff.ffff.ffff FastEthernet0/0
*Mar 1 06:28:37.370: IP ARP: sent rep src 10.1.1.101 0000.5e00.0101,
dst 10.1.1.101 0100.0ccd.cdcd FastEthernet0/0

This results in gratuitous ARP broadcasts continually being sent by R1 and R2 in response to receiving each other’s gratuitous ARPs.  It appears that IOS limits gratuitous ARPs to 1 per second based on the ARP debug messages shown below.  R1 receives a gratuitous ARP from R2 at 39.290.  At the same time, a message is shown immediately after it that a gratuitous ARP was throttled and 10.1.1.101 was added to arp_defense_Q.  At 39.350, another debug message shows that 10.1.1.101 was removed from arp_defense_Q and the gratuitous ARP is broadcast using R1’s virtual MAC as the source.  Another gratuitous ARP is received from R2 shortly after that, and R1 again throttles it and waits to send it’s own gratuitous ARP until 40.350 – exactly 1 second after it sent the previous one.  This pattern continues on each router:

 
R1:
*Mar  1 06:28:39.290: IP ARP: rcvd rep src 10.1.1.101 0000.5e00.0102, dst 10.1.1.101 FastEthernet0/0
*Mar  1 06:28:39.290: IP ARP: Gratuitous ARP throttled.
*Mar  1 06:28:39.350: IP ARP: 10.1.1.101 removed from arp_defense_Q
*Mar  1 06:28:39.350: IP ARP: sent rep src 10.1.1.101 0000.5e00.0101,
                 dst 10.1.1.101 ffff.ffff.ffff FastEthernet0/0
*Mar  1 06:28:39.354: IP ARP: sent rep src 10.1.1.101 0000.5e00.0101,
                 dst 10.1.1.101 0100.0ccd.cdcd FastEthernet0/0
*Mar  1 06:28:39.450: IP ARP: rcvd rep src 10.1.1.101 0000.5e00.0102,
dst 10.1.1.101 FastEthernet0/0
*Mar  1 06:28:39.454: IP ARP: Gratuitous ARP throttled.
*Mar  1 06:28:39.454: IP ARP: 10.1.1.101 added to arp_defense_Q
*Mar  1 06:28:40.278: IP ARP: rcvd rep src 10.1.1.101 0000.5e00.0102, dst 10.1.1.101 FastEthernet0/0
*Mar  1 06:28:40.278: IP ARP: Gratuitous ARP throttled.
*Mar  1 06:28:40.350: IP ARP: 10.1.1.101 removed from arp_defense_Q
*Mar  1 06:28:40.350: IP ARP: sent rep src 10.1.1.101 0000.5e00.0101,
                 dst 10.1.1.101 ffff.ffff.ffff FastEthernet0/0
*Mar  1 06:28:40.354: IP ARP: sent rep src 10.1.1.101 0000.5e00.0101,
                 dst 10.1.1.101 0100.0ccd.cdcd FastEthernet0/0
*Mar  1 06:28:41.210: IP ARP: rcvd rep src 10.1.1.101 0000.5e00.0102, dst 10.1.1.101 FastEthernet0/0
*Mar  1 06:28:41.210: IP ARP: Gratuitous ARP throttled.
*Mar  1 06:28:41.210: IP ARP: 10.1.1.101 added to arp_defense_Q
*Mar  1 06:28:41.350: IP ARP: 10.1.1.101 removed from arp_defense_Q
*Mar  1 06:28:41.350: IP ARP: sent rep src 10.1.1.101 0000.5e00.0101,
                 dst 10.1.1.101 ffff.ffff.ffff FastEthernet0/0
*Mar  1 06:28:41.354: IP ARP: sent rep src 10.1.1.101 0000.5e00.0101,
                 dst 10.1.1.101 0100.0ccd.cdcd FastEthernet0/0

As a result, hosts on the network continually update their ARP cache twice per second:


Host4#debug arp
*Mar 1 07:01:47.518: IP ARP: rcvd rep src 10.1.1.101 0000.5e00.0101, dst 10.1.1.101 FastEthernet0/0
*Mar 1 07:01:48.262: IP ARP: rcvd rep src 10.1.1.101 0000.5e00.0102, dst 10.1.1.101 FastEthernet0/0
*Mar 1 07:01:48.482: IP ARP: rcvd rep src 10.1.1.101 0000.5e00.0101, dst 10.1.1.101 FastEthernet0/0
*Mar 1 07:01:49.258: IP ARP: rcvd rep src 10.1.1.101 0000.5e00.0102, dst 10.1.1.101 FastEthernet0/0
*Mar 1 07:01:49.402: IP ARP: rcvd rep src 10.1.1.101 0000.5e00.0101, dst 10.1.1.101 FastEthernet0/0

5-hsrp-host4-sharp

SW3 learns each of the virtual MACs on the interfaces they are received and the table stays the same over time since R1 and R2 use separate virtual MACs:

 5-mac-table

Any traffic that hosts send to a remote network with the virtual IP configured as their gateway will end up being split between the 2 routers (whichever router’s virtual MAC is currently in the hosts ARP cache at that moment will receive the frame).

 

 

VRRP Authentication Mismatch:

 

Virtual IP

Group #

Virtual MAC

Authentication

R1

10.1.1.101

1

0000.5e00.0101

cisco1

R2

10.1.1.101

1

0000.5e00.0101

cisco2

 

R1:
interface FastEthernet0/0
 vrrp 1 ip 10.1.1.101
 vrrp 1 authentication cisco1

R2:
interface FastEthernet0/0
 vrrp 1 ip 10.1.1.101
 vrrp 1 authentication cisco2

VRRP authentication mismatch also behaves like HSRP authentication mismatch.  R1 and R2 both think that they are the master for the group:

6-vrrp-brief-r14

6-vrrp-brief-r2

Debugs show that the authentication has failed:


R1#debug vrrp errors
*Mar 1 07:25:34.542: VRRP: Grp 1 Advertisement from 10.1.1.2 has FAILED TEXT authentication

Since both routers use the same virtual IP and virtual MAC, they do not generate gratuitous ARPs in response to receiving a gratuitous ARP from the other router.  However, since SW3 receives VRRP hellos sourced from the virtual MAC by both routers, the MAC address flaps back and forth between interfaces as often as R1 and R2 send VRRP hellos (or more if they send other traffic):

6-mac-table

Any traffic that hosts send to a remote network with the virtual IP configured as their gateway ends up being split between the 2 routers depending on which interface the virtual MAC address was last learned out of by the switch at the moment a frame is received from a host.

 

 

GLBP IP Mismatch

 

Virtual IP

Group #

Virtual MAC

Authentication

R1

10.1.1.101

1

0007.b400.0101

R2

10.1.1.102

1

0007.b400.0102

 

R1:
interface FastEthernet0/0
 glbp 1 ip 10.1.1.101

R2:
interface FastEthernet0/0
 glbp 1 ip 10.1.1.102

Like HSRP, GLBP accepts a router as active even though the virtual IP differs.  R1 was configured before R2, so it becomes active for the AVG and AVF #1.  R2 becomes standby for the AVG and active for AVF #2:

7-glbp-brief-r1

7-glbp-brief-r21

R2 generates the following log message, but still continues to accept R1 as the AVG:

R2:
*Mar 1 07:57:22.906: %GLBP-4-DIFFVIP1: FastEthernet0/0 Grp 1 active routers virtual
IP address 10.1.1.101 is different to the locally configured
address 10.1.1.102

SW3 learns the AVF #1 virtual MAC address on F1/1 and AVF #2 virtual MAC on F1/2 since R1 and R2 both source hellos from those MAC addresses:

7-mac-table1

Like HSRP, the configured virtual IP of the router that is in standby is not reachable because the standby router does not respond to it.  If this was supposed to be the correct gateway address, hosts on the subnet would no longer be able to reach it or remote destinations:

7-glbp-ping-r2

7-glbp-host5-ping-r2

Additionally, because of the way that GLBP load balances ARP replies, even if the router with the correct virtual IP becomes the AVG hosts may still receive the virtual MAC of the router configured with the wrong virtual IP.  In this case, Host4 performs an ARP request first and receives the virtual MAC of R1.  Host5 performs an ARP request next and receives the virtual MAC of R2:

7-glbp-host4-sharp

7-glbp-host5-sharp

As we saw when VRRP was configured with an IP mismatch, this did not cause a problem for reaching remote networks because the host still uses the correct MAC address to reach one of the two routers.  Both Host4 and Host5 are able to reach an address on a different subnet:

7-glbp-host4-ping-remote1

7-glbp-host5-ping-remote

With mismatched IPs in VRRP, when hosts attempted to reach the gateway address itself, some traffic would make it and some would not due to the address flapping between interfaces, with all hosts being affected equally.  With mismatched IPs in GLBP, only some of the hosts are affected when trying to reach the gateway address.  Those that obtain the virtual MAC of a router that is configured with the same virtual IP as the AVG will always be able to reach the gateway, and those that obtain the virtual MAC of a router that is configured with a different virtual IP than the AVG will not be able to reach the gateway address at all:

7-glbp-host4-ping-gateway

7-glbp-host5-ping-gateway

 

 

GLBP Group Number Mismatch

 

Virtual IP

Group #

Virtual MAC

Authentication

R1

10.1.1.101

1

0007.b400.0101

R2

10.1.1.101

2

0007.b400.0201

 

R1:
interface FastEthernet0/0
 glbp 1 ip 10.1.1.101

R2:
interface FastEthernet0/0
 glbp 2 ip 10.1.1.101

Like HSRP and VRRP, when 2 GLBP routers are configured with mismatched group numbers both become active:

8-glbp-brief-r1

8-glbp-brief-r2

Each router also uses a different virtual MAC.  GLBP virtual MACs by default are in the form of 0007.b40X.XXYY, where XXX is the group number in hexadecimal and YY is the forwarder number in hexadecimal.  The group numbers for R1 and R2 were set to 1 and 2 respectively, and since each router thinks that it is the only router in the group, they have both assigned themselves AVF #1.  This results in a virtual MAC of 0007.b400.0101 for R1 and 0007.b400.0201 for R2.  Unlike HSRP and VRRP, GLBP does not send gratuitous ARPs when becoming active so gratuitous ARPs are not sent back and forth constantly.  When a host ARPs for it’s gateway, both R1 and R2 reply with their virtual MAC.  The first reply creates an entry in ARP cache, and the second overwrites it, so the host will use the last ARP reply to arrive as it’s gateway.  In this case, the reply from R1 comes last so Host4 uses R1’s virtual MAC:


Host4#debug arp
Host4#ping 10.1.1.101

*Mar 1 08:12:54.489: IP ARP: creating incomplete entry for IP address: 10.1.1.101 interface FastEthernet0/0
*Mar 1 08:12:54.489: IP ARP: sent req src 10.1.1.4 0000.0000.0004,
dst 10.1.1.101 0000.0000.0000 FastEthernet0/0
*Mar 1 08:12:54.573: IP ARP: rcvd rep src 10.1.1.101 0007.b400.0201, dst 10.1.1.4 FastEthernet0/0
*Mar 1 08:12:54.621: IP ARP: rcvd rep src 10.1.1.101 0007.b400.0101, dst 10.1.1.4 FastEthernet0/0

8-glbp-host4-sharp

Hosts will use either one gateway or the other, depending on which ARP reply they receive last.  As long as both routers have full connectivity to other networks, hosts should still be able to reach any address both local and remote.

 

 

GLBP Authentication Mismatch

 

Virtual IP

Group #

Virtual MAC

Authentication

R1

10.1.1.101

1

0007.b400.0101

cisco1

R2

10.1.1.101

1

0007.b400.0101

cisco2

 

R1:
interface FastEthernet0/0
 glbp 1 ip 10.1.1.101
 glbp 1 authentication text cisco1

R2:
interface FastEthernet0/0
 glbp 1 ip 10.1.1.101
 glbp 1 authentication text cisco2

A GLBP authentication mismatch behaves just like HSRP and VRRP with an authentication mismatch.  R1 and R2 both think they are the AVG for group 1:

9-glbp-brief-r1

9-glbp-brief-r2

The following log message shows up on each router:

R1:
*Mar 1 08:29:17.833: %GLBP-4-BADAUTH: Bad authentication received from 10.1.1.2, group 1

SW3 receives GLBP hellos from the same virtual MAC by both routers, so the MAC address flaps back and forth between interfaces on SW3 as often as R1 and R2 send hellos (or more if they send other traffic):

9-mac-table

Any traffic that hosts send to a remote network with the virtual IP configured as their gateway ends up being split between the 2 routers depending on which interface the virtual MAC address was last learned out of by the switch at the moment a frame is received from a host.

 

 

Summary:

A brief summary of the differences in each misconfiguration:

 

IP Mismatch

Group Mismatch

Auth. Mismatch

HSRP

  Different vIP, same vMAC

 Only 1 becomes active

 Active vIP is reachable, non-active vIP is not reachable

  If correct vIP becomes active, other networks are reachable

  If incorrect vIP becomes active, hosts cannot reach other networks

 

  Same vIP, different vMAC

  Both become active

 G. ARPs constantly sent

  Hosts constantly update ARP cache

 Traffic from hosts split between both routers, based on current host ARP cache

 Active vIP and other networks are reachable

  Same vIP and vMAC

 Both become active

  vMAC flaps on SW3

 Traffic from hosts split between both routers, based on current SW3 MAC table

 Active vIP and other networks are reachable

VRRP

  Different vIP, same vMAC

  Both become active

  vMAC flaps on SW3

 Both active vIPs are intermittently reachable, based on SW3 MAC table

  Other networks are reachable regardless of SW3 MAC table

 

  Same as above

 Same as above

GLBP

 Different vIP and vMAC

  Only 1 becomes active

  Non-active vIP is not reachable

  If incorrect vIP becomes active, hosts cannot reach other networks

  Active vIP is reachable to some hosts but not others, based on vMAC received from GLBP load balancing

  If correct vIP is active, other networks are reachable regardless of vMAC that the host receives

  Same vIP, different vMAC

  Both become active

  G. ARPs not sent

 Hosts that ARP for gateway receive replies from both AVGs

  Traffic from hosts split between both routers, based on which ARP reply was received last

  Active vIP and other networks are reachable

 

  Same as above

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: