VRRP tests in mixed environment - Revision history

Mariusz: /* VIP advertisement with Quagga */ Add basics

2019-01-08T23:48:14Z

VIP advertisement with Quagga: Add basics

Mariusz: Add ping results when the VIP host goes down

2019-01-07T10:41:29Z

Add ping results when the VIP host goes down

Mariusz: Add description for advertising the VIP

2019-01-04T10:42:06Z

Add description for advertising the VIP

Mariusz: Add a diagram

2019-01-02T17:04:54Z

Add a diagram

Mariusz: Created page with "== Motivation == To find a method for replacing a single point of failure created by headnodes in the trial platform. Keepalived already uses VRRP for failover of HAProxy virt..."

2019-01-02T16:41:53Z

Created page with "== Motivation == To find a method for replacing a single point of failure created by headnodes in the trial platform. Keepalived already uses VRRP for failover of HAProxy virt..."

New page

== Motivation ==
To find a method for replacing a single point of failure created by headnodes in the trial platform.
Keepalived already uses VRRP for failover of HAProxy virtual IPs (VIPs) -- can we make use of this?

== All you need to know about VRRP (for this task) ==
Hosts first join the <code>224.0.0.18</code> multicast group. VRRP advertisements are send to this address by the Master and received by Backups. If there are multiple hosts sending advertisements, the one with the highest priority is selected as the Master. If all senders have the same priority, the host with the highest IP address is selected as the Master.

There can be multiple VRRP groupings of Masters and backups (called "instances") and each of them is identified by its <code>vrID</code>.

Each advertisement also includes a list of virtual IPs and authentication data (for example secrets shared between hosts being part of the instance).

A sample VRRP packet:
<nowiki>
11:04:02.958005 52:54:00:a7:12:5c > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 58: (tos 0xc0, ttl 255, id 98, offset 0, flags [none], proto VRRP (112), length 44)
172.28.0.136 > 224.0.0.18: vrrp 172.28.0.136 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 150, authtype simple, intvl 1s, length 24, addrs(1): 100.100.100.100 auth "mvDvaixF"
</nowiki>

== VRRP across servers and switches POC ==
Because VRRP is an open standard, servers with keepalived installed can send valid VRRP packets that are then interpreted by physical switches.

Here a test setup consisting of a physical L3 switch and 2 virtual machines running on the same host and connected to a L2 bridge was created.

TODO: Add diagram explaining the idea.

HAProxy and keepalived were installed and configured on the VMs using <code>kolla-ansible</code>.

VRRP was configured on the switch to conform to the keepalived config. Here are used commands:

<nowiki>
SMIS(config)# router vrrp
SMIS(config-vrrp)# interface vlan 1
SMIS(config-vrrp-if)# vrrp 51 ipv4 100.100.100.100
SMIS(config-vrrp-if)# vrrp 51 priority 1
SMIS(config-vrrp-if)# vrrp 51 text-authentication mvDvaixF
SMIS(config-vrrp-if)# vrrp 51 timer 1
</nowiki>

(<code>100.100.100.100</code> is the HAProxy VIP)

The already configured management VLAN (ID 1) was used here for simplicity:

<nowiki>
SMIS(config)# show ip interface vlan 1

vlan1 is up, line protocol is up
Internet Address is 172.28.0.198/16
Broadcast Address 172.28.255.255
IP address allocation method is dynamic
IP address allocation protocol is dhcp
</nowiki>

With all the above done, one of the VMs becomes the Master and gets the VIP:
<nowiki>
root@ubuntu:~# ip a s ens3
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 52:54:00:a7:12:5c brd ff:ff:ff:ff:ff:ff
inet 172.28.0.136/16 brd 172.28.255.255 scope global ens3
valid_lft forever preferred_lft forever
inet 100.100.100.100/32 scope global ens3
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fea7:125c/64 scope link
valid_lft forever preferred_lft forever
</nowiki>

The other server has only its internal IP on corresponding interface and the switch becomes a Backup:
<nowiki>
SMIS(config-vrrp-if)# show vrrp detail

vlan1 - vrID 51
---------------
State is Backup
Virtual IP address is 100.100.100.100
Virtual MAC address is 00:00:5e:00:01:33
Master router is 100.100.100.100
Associated IpAddresses :
----------------------
100.100.100.100
Advertise time is 1 secs
Current priority is 1
Configured priority is 1
Configured Authentication
Authentication key is mvDvaixF
</nowiki>

Stopping keepalived on the Master causes the VIP to switch to the other server and when there are no servers with a VIP, the switch becomes the Master. The moment keepalived goes up on any of the servers, the switch transitions to Backup again and this server becomes the new Master.

Unfortunately, with this setup, the switch doesn't seem to keep track of the internal IP of the current master (as evident on the previous listing where the "Master router is" field shows the VIP) and it doesn't add a route telling how to reach the VIP:
<nowiki>
SMIS(config-vrrp-if)# show ip route

S 0.0.0.0/0 [1] via 172.28.0.2
C 172.28.0.0/16 is directly connected, vlan1
</nowiki>

== Resources ==

* VRRP Protocol whitepaper http://www2.elo.utfsm.cl/~tel242/exp/04/VRRP_protocol.pdf
* First Hop Redundancy Protocols Configuration Guide, Cisco IOS Release 15M&T https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp_fhrp/configuration/15-mt/fhp-15-mt-book/fhp-vrrp.html

← Older revision		Revision as of 23:48, 8 January 2019
Line 94:		Line 94:

	== VIP advertisement with Quagga ==		== VIP advertisement with Quagga ==
		+
		+	=== The basics ===
		+	This description assumes that the reader has an understanding of the following:
		+
		+	# A routing table is a list of routes a router knows about.
		+	# Any network a router is connected to directly (meaning the network is configured on one of its interfaces), gets an automatic entry in the routing table specifying which interface the network is configured on. Example: <code>C 172.28.0.0/16 is directly connected, vlan1</code> means the network <code>172.28.0.0/16</code> is configured on interface <code>vlan1</code>.
		+	# The goal of routing is to exchange routing tables between routers, so that each router knows which of its neighbour is the "next hop" for a packet destined to the network specified by the destination IP address of each packet. This includes updating routing tables if the route fails or changes.
		+	# RIP is one of so-called "routing protocols" that provide an algorithm for facilitating the exchange of routing tables. RIP (like many other routing protocols) is an open standard, i.e it's implementation is not tied to a specific router vendor.
		+	# Quagga is simply a set of software daemons that implement routing protocols, so that any Linux machine can participate in the exchange of routes. Quagga's daemon implementing RIP his called <code>ripd</code>.
		+
		+	=== The solution ===
	The same setup as for the VRRP part -- 2 VMs on a bridge and a physical L3 switch, but this time Quagga is installed on both VMs.		The same setup as for the VRRP part -- 2 VMs on a bridge and a physical L3 switch, but this time Quagga is installed on both VMs.

← Older revision		Revision as of 10:41, 7 January 2019
Line 230:		Line 230:
	</nowiki>		</nowiki>

		+	When the host holding the VIP goes down, around 160s is needed to migrate the route:
		+	<nowiki>
		+	[1546854365.147454] 64 bytes from 100.100.100.100: icmp_seq=11 ttl=64 time=0.494 ms
		+	[1546854366.147363] 64 bytes from 100.100.100.100: icmp_seq=12 ttl=64 time=0.393 ms
		+	[1546854367.147340] 64 bytes from 100.100.100.100: icmp_seq=13 ttl=64 time=0.388 ms
		+
		+	[1546854527.147422] 64 bytes from 100.100.100.100: icmp_seq=173 ttl=64 time=0.474 ms
		+	[1546854528.147426] 64 bytes from 100.100.100.100: icmp_seq=174 ttl=64 time=0.487 ms
		+	[1546854529.147307] 64 bytes from 100.100.100.100: icmp_seq=175 ttl=64 time=0.404 ms
		+	</nowiki>
		+	This is, most likely, because of RIP timers.

	== Resources ==		== Resources ==

@@ Line 92: / Line 92: @@
 C 172.28.0.0/16 is directly connected, vlan1
 </nowiki>
 == Resources ==
@@ Line 97: / Line 235: @@
 * VRRP Protocol whitepaper http://www2.elo.utfsm.cl/~tel242/exp/04/VRRP_protocol.pdf
 * First Hop Redundancy Protocols Configuration Guide, Cisco IOS Release 15M&T https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp_fhrp/configuration/15-mt/fhp-15-mt-book/fhp-vrrp.html

@@ Line 21: / Line 21: @@
 Here a test setup consisting of a physical L3 switch and 2 virtual machines running on the same host and connected to a L2 bridge was created.
-TODO: Add diagram explaining the idea.
+[[File:Vrrp_keepalived_and_switch_idea.png|400px]]
 HAProxy and keepalived were installed and configured on the VMs using <code>kolla-ansible</code>.