VRRP Testing Note 2

In doing some extensive testing with VRRP with Keepalived, I was able to put it into Split Brain mode.

I have documented how I did this, and I will need to see if it is repeatable.

Here is one link that discusses troubleshooting for this, although I will need to find others.

https://www.atlantic.net/community/howto/vrrp-keepalived-configuration/

UPDATE: Here is another.

http://serverfault.com/questions/512153/both-servers-running-keepalived-become-master-and-have-a-same-virtual-ip

In his case on this link, here is the solution.

The problem has been resolved.

The problem was from the switch setting. When multicast filter mode is filter-all, the problem happened. The Keepalived runs O.K. when multicast filter mode is forward-all.

In his specific case, unicast could be the answer.

I realize that I do not have that mcast src ip in my file (don't think that is needed but I can add it).

I could also try to use PASS instead of AH. So I can experiment with that as well.

VRRP Testing - Note 1

First problem I ran into was with SeLinux. Apparently when the notify script wanted to write to an output file, SeLinux complained and prevented this. This made it impossible to tell if the script was even working, and therefore made it very hard to tell if VRRP / Keepalived was working.

I got around this by changing SeLinux to permissive in the /etc/selinux/conf file.

With permissive, it still complains, but does not prevent.


Next, I came to realize that the configuration parameters that were being used to start keepalived were in the /etc/sysconfig/keepalived folder.

I changed these parms to use -P -D -d -S 7.

The -P is for VRRP Only option.
-D is for Debug
-d is for dump config
-S is for log level, which is set to 7 for maximum logging.


With these changes, I noticed that BOTH virtual machines had a virtual IP, instead of just one. This surprised me. I expected only one to use the virtual IP and that it would switch back and forth.

But, doing some initial testing by disconnecting adaptors, I could see the state change being logged out to the log file.

VRRP with Unicast

Some good examples of how to do keepalived with unicast:

http://www.linux-admins.net/2015/02/keepalived-using-unicast-track-and.html

VRRP with Keepalived

First, the website for keepalived:

http://www.keepalived.org/

Originally, I read the documentation on their website, which is dated June 13th, 2002.

http://www.keepalived.org/pdf/UserGuide.pdf

Unable to believe that the documentation could not be changed after this many years, I went digging for better more updated documentation, and indeed, I found that here:

https://media.readthedocs.org/pdf/keepalived/latest/keepalived.pdf

WHY DOES THIS NOT LIVE ON THE WEBSITE????

I started reading. This is not simple / trivial.

Keepalived is essentially used mainly for load balancing, and when you read up on it, it is inferred that one needs to have LVS (Linux Virtual Server). There are quite a number of sites discussing how to build a Load Balanced with LVS, like this one below.

http://www.linux-admins.net/2013/01/building-load-balancer-with-lvs-linux.html

But there did (and still does not) seem to be much documentation discussing what you need to do, exactly, to install and run LVS. For instances, does it come by default on systems? Do you need to install it? Compile it?

One article, albeit from 2004, scared me when I started reading about patching the kernel to use it.

http://www.ultramonkey.org/papers/lvs_tutorial/html/

Later, I found this link, which, FINALLY, makes it clear that you need the package ipvsadm (on CentOS, which is the OS I am interested in).

NOTE: Maybe these are different services and packages on other Linux distributions.

https://www.server-world.info/en/note?os=CentOS_7&p=lvs

Next, I started reading further, and realized that, in order to use VRRP, you don't even need to use LVS!!! WHY? Because VRRP is only used to maintain state between Master and Slaves on Load Balancers, so that a) someone is always on top of the load balancing task and b) the Load Balancers know who the master is, and who the slave is. It is also used to prevent Split-Brain mode (multiple masters, etc).

So - why would you be interested in VRRP, without the Load Balancing? That does not seem to make much sense? And that is why these concepts are so intertwined. But in our case, admittedly a rare one, that is our requirement. We just want VRRP for the purpose of making sure a node is always up; we don't need the nodes running VRRP to load balance anything behind them.

So I found these sites below that, rather than address LVS (and using KeepaliveD for LVS and Load Balancing), and instead focus on the VRRP aspects of KeepaliveD.

https://tobrunet.ch/2013/07/keepalived-check-and-notify-scripts/

http://packetpushers.net/vrrp-linux-using-keepalived-2/

This site from Oracle helps provide some guidance on the tracking features of keepalived (scripts, interfaces, et al). It finally explained what interface tracking is for / does.

https://docs.oracle.com/cd/E37670_01/E41138/html/section_hxz_zdw_pr.html

VirtualBox Networking Configuration

VirtualBox has its own way of Networking that is a bit different than other virtualization platforms.

It's important to understand the distinctions between the types and kinds of networks that are out there and available.

VirtualBox Networking Chapter of Manual:
https://www.virtualbox.org/manual/ch06.html

VirtualBox Manual Itself:
http://www.virtualbox.org/manual/

Note: There is a pesky NIC that shows up in "ifconfig", called virbr0. This is a virtual network driver that shows up if you are running libvirtd. You will need to stop and disable libvirtd if this interface is resident, and often times you will need to reboot the box or VM after you do this for the interface to completely disappear from the ifconfig interface listing.

Generating UUID for Network Interfaces

Ever wonder where these came from? How these got generated?

Ever wanted to copy an interface file, and wonder about what happens if you use the same UUID, or - perhaps worse - what happens if you blow it away, or just change it willy nilly?

Well, I came across this and tested it on VirtualBox - because VirtualBox did not generate files or UUIDs for new NAT interfaces I created. I generated new UUIDs, and nothing complained or barked at all. Yay.

I'm sure I will remember this, but I'll post it just in case.

NOTE: The uuidgen utility seemed to be on the box. I did not need to install anything. I don't know what package this utility is a part of, and have not researched. It just seemed to work - for me at least.

http://www.itechlounge.net/2014/03/linux-how-to-generate-uuid-for-network-interface-on-rhelcentos/

Source NAT on Linux

Had a request come in to try and do a source-based NAT.

The reason for this is that the customer had a ISP router that they presumably could not log in and configure to do NAT with. Behind this router, was a Switch - apparently an L3 Switch that had some intelligence, but apparently it could not do NAT. It could have actually been related to change control, also.

I found this website here, which discussed how to do SNAT.

http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-6.html

Since websites tend to die an move, I will clip the excerpt of text I was interested in:
----------------------------------------------------------------------------------------------------------
You want to do Source NAT; change the source address of connections to something different. This is done in the POSTROUTING chain, just before it is finally sent out; this is an important detail, since it means that anything else on the Linux box itself (routing, packet filtering) will see the packet unchanged. It also means that the `-o' (outgoing interface) option can be used.
Source NAT is specified using `-j SNAT', and the `--to-source' option specifies an IP address, a range of IP addresses, and an optional port or range of ports (for UDP and TCP protocols only).

## Change source addresses to 1.2.3.4.
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4

## Change source addresses to 1.2.3.4, 1.2.3.5 or 1.2.3.6
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4-1.2.3.6

## Change source addresses to 1.2.3.4, ports 1-1023
# iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to 1.2.3.4:1-1023

Masquerading

There is a specialized case of Source NAT called masquerading: it should only be used for dynamically-assigned IP addresses, such as standard dialups (for static IP addresses, use SNAT above).
You don't need to put in the source address explicitly with masquerading: it will use the source address of the interface the packet is going out from. But more importantly, if the link goes down, the connections (which are now lost anyway) are forgotten, meaning fewer glitches when connection comes back up with a new IP address.

## Masquerade everything out ppp0.
# iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

----------------------------------------------------------------------------------------------------------
Since I used FirewallD, I had to put the NAT rule into the direct.xml rule of FirewallD (I considered trying to put it in a zone-based rule, but decided to use direct.xml).

In testing this, I found some very interesting things. I did not have an IP to NAT "to", since I don't run the networks here, and everything is set up for DHCP. But - I did have two NICs on two separate networks, so I decided to SNAT the IPs of NIC A (10.1.x.y) to NIC B (172.31.x.y).

I used tcpdump to examine packets that typically came out of NIC A as 10.1.x.y, to see if they would come out as 172.31.x.y: tcpdump -A -n -i NICA grep "172.31.x.y"

This seemed to work as long as I had ONE rule for ONE Nic. But if I tried to use TWO rules for the TWO Nics, nothing seemed to NAT at all.