VRRP in Linux
At one young developing provider at the dawn of formation of the organization of access for physical. The following network architecture was adopted:
As the subscriber base grew, all the problems from the first three points were solved successfully. And with the latter, small problems were predicted:
If the technology were PPPoE or PPTP / L2TP, everything would be decided by simply adding a server (PPPoE) and prescribing a round-robin DNS record for the PPTP / L2TP server (not very strong in this topic, maybe that messed up).
For our access technology, VRRP remained the only option.
You can take it here . I will not describe the installation, there is nothing specific.
Briefly about VRRP:
A virtual interface is created on each server. One of the servers becomes MASTER, the other - BACKUP, with all traffic going through the MASTER server. The MASTER server responds to arp requests, the BACKUP server is silent. Two servers exchange special packages that determine which of them is MASTER and its availability, so that the BACKUP server, if the MASTER server is unavailable, switches itself to the MASTER state.
')
On the VRRP page, a load balancing method is indicated when two virtual interfaces are raised, and different gateway addresses are sent via DHCP.
I decided to use another way. Because vlans should be terminated on the same servers, then for each of the vlans there will be one viral interface, only for the odd vlan number MASTER there will be server No. 1, and server No. 2 will be BACKUP. For even vlan numbers, everything will be exactly the opposite - server number 1 will be BACKUP, and number 2 will be MASTER. Because there is a lot of interfaces, then the routed traffic will be divided approximately equally.
So, the ready decision:
Interfaces of server â„–1 (vlan number, interface ip-address, status in VRRP):
Server number 2 (vlan number, interface ip-address, status in VRRP):
Virtual interfaces will have addresses (vlan number, ip-address):
How to configure the physical interfaces will not describe - the material on this topic is complete.
To automatically download vrrp when you start the system in /etc/init.d/, create a start-up script (you can write your own or use ready-made templates on the Internet, the benefit is easily found). The point is to run one process for each interface. On bash, I wrote a simple script that generates something similar for server # 1:
And for server number 2:
In these examples:
/ bin / vrrpd - path for executable file
-i eth1.1 - the physical interface on which the virtual will be raised
-v 1 - id of the vrrp group (there can be no more than 255 groups)
10.0.1.1 - ip-address of the virtual interface
-p 255 - server priority, the more, the more priority. By default, it is assumed that the priority is 255 for the server which is MASTER.
After vrrp starts at the virtual interface, the MAC address will be 00: 00: 5E: 00: 01: xx, where xx is the id of the VRRP group. Also, routers will begin to exchange packets announcing their state. These multicast packets, it is necessary to ensure that the switches through which the two servers are connected do not filter multicasts to the address 224.0.0.18.
And now we configure iptables so that the server itself does not filter the necessary packets. Add the following lines to the / etc / sysconfig / iptables file:
Everything.
Result:
Particularly meticulous subscribers noticed only strangeness when tracing remote hosts. Strangeness looks like this:
PS In fact, when introducing this pair of servers into production, I also mastered other technologies that I had not dealt with before (LACP, OSPF), but most of all it was interesting to deal with VRRP.
- IPoE
- port-ip binding
- issuing addresses via DHCP (option 82)
- routing server on Linux (CentOS)
As the subscriber base grew, all the problems from the first three points were solved successfully. And with the latter, small problems were predicted:
- The down-time when the server was restarted (installing updates or failing) was approximately 15 minutes. On the server, vlan in the amount of the order of hundreds were terminated, and it took about 5-7 seconds to raise each interface for the vlan, which in total gave an impressive time for the server to be fully loaded. At this time the server, although it did respond, was missing ssh, which made it a little nervous.
- Increasing the load on the server could be solved by increasing the power of iron, but not to carry out an endless upgrade of iron.
- And the biggest problem. No reservation. The reboot time had to be planned for late night or morning, in order to reduce the number of calls to tech support and reduce the number of subscribers who noticed a lack of communication. I am already silent about the fact that the failure that occurred at rush hour in the evening added a tuft of gray hair on my head.
If the technology were PPPoE or PPTP / L2TP, everything would be decided by simply adding a server (PPPoE) and prescribing a round-robin DNS record for the PPTP / L2TP server (not very strong in this topic, maybe that messed up).
For our access technology, VRRP remained the only option.
You can take it here . I will not describe the installation, there is nothing specific.
Briefly about VRRP:
A virtual interface is created on each server. One of the servers becomes MASTER, the other - BACKUP, with all traffic going through the MASTER server. The MASTER server responds to arp requests, the BACKUP server is silent. Two servers exchange special packages that determine which of them is MASTER and its availability, so that the BACKUP server, if the MASTER server is unavailable, switches itself to the MASTER state.
')
On the VRRP page, a load balancing method is indicated when two virtual interfaces are raised, and different gateway addresses are sent via DHCP.
I decided to use another way. Because vlans should be terminated on the same servers, then for each of the vlans there will be one viral interface, only for the odd vlan number MASTER there will be server No. 1, and server No. 2 will be BACKUP. For even vlan numbers, everything will be exactly the opposite - server number 1 will be BACKUP, and number 2 will be MASTER. Because there is a lot of interfaces, then the routed traffic will be divided approximately equally.
So, the ready decision:
Interfaces of server â„–1 (vlan number, interface ip-address, status in VRRP):
1 10.0.1.2 MASTER
2 10.0.2.2 BACKUP
3 10.0.3.2 MASTER
...
254 10.0.254.2 BACKUP
255 10.0.255.2 MASTERServer number 2 (vlan number, interface ip-address, status in VRRP):
1 10.0.1.3 BACKUP
2 10.0.2.3 MASTER
3 10.0.3.3 BACKUP
...
254 10.0.254.3 MASTER
255 10.0.255.3 BACKUPVirtual interfaces will have addresses (vlan number, ip-address):
1 10.0.1.1
2 10.0.2.1
3 10.0.3.1
...
254 10.0.254.1
255 10.0.255.1How to configure the physical interfaces will not describe - the material on this topic is complete.
To automatically download vrrp when you start the system in /etc/init.d/, create a start-up script (you can write your own or use ready-made templates on the Internet, the benefit is easily found). The point is to run one process for each interface. On bash, I wrote a simple script that generates something similar for server # 1:
/bin/vrrpd -i eth1.1 -v 1 10.0.1.1 -p 255
/bin/vrrpd -i eth1.2 -v 2 10.0.2.1 -p 100
/bin/vrrpd -i eth1.3 -v 3 10.0.3.1 -p 255
...
/bin/vrrpd -i eth1.254 -v 254 10.0.254.1 -p 100
/bin/vrrpd -i eth1.255 -v 255 10.0.255.1 -p 255And for server number 2:
/bin/vrrpd -i eth1.1 -v 1 10.0.1.1 -p 100
/bin/vrrpd -i eth1.2 -v 2 10.0.2.1 -p 255
/bin/vrrpd -i eth1.3 -v 3 10.0.3.1 -p 100
...
/bin/vrrpd -i eth1.254 -v 254 10.0.254.1 -p 255
/bin/vrrpd -i eth1.255 -v 255 10.0.255.1 -p 100In these examples:
/ bin / vrrpd - path for executable file
-i eth1.1 - the physical interface on which the virtual will be raised
-v 1 - id of the vrrp group (there can be no more than 255 groups)
10.0.1.1 - ip-address of the virtual interface
-p 255 - server priority, the more, the more priority. By default, it is assumed that the priority is 255 for the server which is MASTER.
After vrrp starts at the virtual interface, the MAC address will be 00: 00: 5E: 00: 01: xx, where xx is the id of the VRRP group. Also, routers will begin to exchange packets announcing their state. These multicast packets, it is necessary to ensure that the switches through which the two servers are connected do not filter multicasts to the address 224.0.0.18.
And now we configure iptables so that the server itself does not filter the necessary packets. Add the following lines to the / etc / sysconfig / iptables file:
:allow_vrrp - [0:0] # vrrp
-A RH-Firewall-1-INPUT -p 112 -j allow_vrrp # 112 ( vrrp)
-A allow_vrrp -s 10.0.1.0/30 -j ACCEPT #
-A allow_vrrp -s 10.0.2.0/30 -j ACCEPT
-A allow_vrrp -s 10.0.3.0/30 -j ACCEPT
...
-A allow_vrrp -s 10.0.254.0/30 -j ACCEPT
-A allow_vrrp -s 10.0.255.0/30 -j ACCEPT
-A allow_vrrp -j LOG --log-level notice #
-A allow_vrrp -j DROP #Everything.
Result:
- Switching to a backup server occurs in less than one second, more precisely, it did not measure. For the subscriber, everything happens transparently, only the current sessions are terminated and (for subscribers behind NATs with gray ip) - the ip changes which they tension.
- You can restart servers quietly during business hours, knowing that all users will be automatically transferred to the reserve. In case of failure, there is also no particular panic.
- Trite, but - two servers are more productive than one, and with a special desire, their number can be safely increased.
Particularly meticulous subscribers noticed only strangeness when tracing remote hosts. Strangeness looks like this:
tracert ya.ru
0 10.0.34.35 # ip
1 10.0.34.3 # ip .3, .1PS In fact, when introducing this pair of servers into production, I also mastered other technologies that I had not dealt with before (LACP, OSPF), but most of all it was interesting to deal with VRRP.
Source: https://habr.com/ru/post/128770/
All Articles