Network topology of disaster recovery mode:

1) working process: when the client sends a WEB request to the VIP, the LVS server selects the corresponding real server pool according to the VIP, and selects a real server in the pool according to the algorithm. LVS records the connection in the hash table, then sends the request packet of the client to the selected real server, and the finally selected real server directly sends the reply packet to the client; When the client continues to outsource, LVS will directly send the request belonging to this connection to the real server just selected according to the hash table information recorded in the update; When the connection hangs or times out, the records in the hash table will be deleted.

2) Several details of disaster recovery mode:

1 & gt； LVS and real server must be in the same network segment: (in the same broadcast domain)

In DR mode, when forwarding the client's data packet, only the mac address of the data packet destination is changed to the MAC address of the selected real server. Therefore, if LVS and the real server are in an impassable broadcast domain, the real server cannot receive the forwarded data packet. The following is the modification process of mac address:

2 & gtLVS does not need to open routing forwarding:

The DR mode of LVS can work normally without turning on the routing and forwarding function. For security reasons, if the forwarding function is not needed, it is best to turn it off.

3 & gtARP problem:

In general, the disaster recovery model needs to configure VIP on the real server in the following ways:

/sbin/ifconfig lo:0 inet VIP netmask 255.255.255.255

I) The reason is that when LVS forwards the client's packet to Real-server, because the destination IP address of the packet is VIP, if Real-server finds that the destination IP of the packet is not its own system IP after receiving this packet, it will think that the packet is not addressed to itself and will be discarded, so it is necessary to bind this IP address to the network card; When sending a reply packet to the client, the real server will exchange the source address and destination address of the packet and reply the client directly.

Ii) About ARP broadcasting:

* The mask of the VIP binding above is "255.255.255", which means that the broadcast address is his own, so he will not send the ARP to the actual broadcast domain he belongs to, so as to prevent conflicts with VIPs on LVS and lead to IP conflicts.

* In addition, on the Real-server of Linux, you need to set the sysctl option of ARP: (The following example illustrates the setting item).

Assume that the ip address on the server is as follows:

System interface MAC address IP address

HN eth 0 00:0c:29:B3:a2:54 192. 168. 18. 10

HN eth 3 00:0c:29:B3:a2:68 192. 168. 18. 1 1

HN eth 4 00:0c:29:B3:a2:5e 192. 168. 18. 12

Client eth0 00: 0c: 29: D2: C7: aa192.168.18.129.

When I ping192.168.18.129, tcpdump found that:

00:0c:29:D2:C7:aa & gt； FF: FF: FF: FF: FF: FF: FF, ARP, length 60: arpWho-has192.168.18.192.168. 00:0c:29:d2:c7:aa, ARP, length 60: arp reply192.168.18.10 is-at 00: 0c: 29: B3: A2: 5e. 00:0c:29:d2:c7:aa, ARP, length 60: arp reply192.168.10IS-at 00: 0c: 29: B3: A2: 50. 00:0c:29:d2:c7:aa, ARP, length 60: arp reply192.168.10IS-at 00: 0c: 29: B3: A2: 68. 00:0c:29:b3:a2:5e, IPv4, length 98:192.168.18.129 > 192.168.18.10: icmp response request, id 323 13, seq 1, length 6400: 0c: 29: B3: A2. 00:0c:29:d2:c7:aa, IPv4, length 98:192.168.18.10 > 192.168.18.129: icmp echo reply, id 323 13, seq 1, length 6400: 0c: 29: D2: C7. 00:0c:29:b3:a2:5e, IPv4, length 98:192.168.18.129 > 192.168.18.10: icmp response request, id 323 13, seq 2, length 6400: 0c: 29: B3: A2: 54 > 00:0c:29:d2:c7:aa, IPv4, length 98:192.168.18.10 > 192.168.18.129: icmp response reply, id 323 13, seq 2, length 6400: 0c: 29: B3: A2: 54> 00:0c:29:d2:c7:aa, ARP, length 60: arpwho-has192.168.18.129 tell192./kloc. 00: 0c: 29: B3: a2: 54, arp, length 60: ARP reply192.168.129 is-at 00: 0c: 29: D2: C7: aa Send all ARP reply packets. However,192.168.18.129 uses the first mac address that responds to eth0 as the ping request port, because192.168.1

If the real server has multiple network cards, each network card is in a different network segment, then the response of ARP request from non-native network cards can be filtered out; But if the ip of multiple network cards is in a network segment, it will not work.

sysctl-w net . IP v4 . conf . all . ARP _ filter = 1

For multiple interfaces on the same network segment, you can set the following contents to prevent them:

sysctl-w net . IP v4 . conf . all . ARP _ ignore = 1

sysctl-w net . IP v4 . conf . all . ARP _ announce = 2

When ping192.168.18.129, tcpdump found that:

00:0c:29:D2:C7:aa & gt； ff:ff:ff:ff:ff:ff:ff:ff，ARP，length 60:ARP who-has 192. 168. 18. 192. 168. 18. 12900:0c:29:B3:a2:54 & gt； 00:0c:29:d2:c7:aa, ARP, length 60: arp reply192.168.10IS-at 00: 0c: 29: B3: A2: 50. 00:0c:29:b3:a2:54, IPv4, length 98:192.168.18.129 > 192.168.18.10: icmp response request, id 32066, seq 1, length 6400: 0c: 29: B3: A2: 54 > 00:0c:29:d2:c7:aa, IPv4, length 98:192.168.18.10 > 192.168.18.129: icmp response reply, id 32066, seq 1, length 6400: 0c: 29: D2: C7: aa > 00:0c:29:b3:a2:54, IPv4, length 98:192.168.18.129 > 192.168.18.10: icmp response request, id 32066, seq 2, length 6400: 0c: 29: B3: a2: 54 > 00:0c:29:d2:c7:aa, IPv4, length 98:192.168.18.10 > 192.168.18.129: icmp response reply, id 32066, seq 2, length 6400: 0c: 29: B3: A2: 54 > 00:0c:29:d2:c7:aa, ARP, length 60: arpwho-has192.168.18.129 tell192./kloc. 00: 0C: 29: B3: A2: 54, arp, length 60: ARP reply192.168.129 is-at 00: 0c: 29: D2: C7: aa See, now only eth0 will respond.

Arp message format:

Request message: MAC address field is empty.

Response message: All fields are content.

Arp _ announcement/ARP _ ignore reference:

ARP _ announcement–Integer defines different restriction levels to announce the local source IP address from the IP packet in the ARP request sent on the interface: 0- (default) Use any local address configured on any interface1–Try to avoid local addresses that are not in the target subnet of the interface. This mode is useful when the destination host reachable through this interface requires the source IP address in the ARP request to be part of its logical network configured on the receiving interface. When we generate a request, we will check all subnets containing the target IP, and if the source address comes from such subnets, we will keep the source address. If there is no such subnet, we will choose the source address according to the rule of level 2.2, and always use the best local address of this target. In this mode, we ignore the source address in the IP packet and try to choose our preferred local address to talk to the target host. This local address is selected by looking for the main IP address on all subnets of the output interface containing the target IP address. If we can't find a suitable local address, we choose the first local address on the output interface or all other interfaces, hoping that our request will be answered, sometimes even regardless of the source IP address we announced. Use the maximum value in conf/{all, interface}/ARP _ announcement. Increasing the restriction level will have more opportunities to receive answers from the parsed target, while lowering the restriction level will publish more effective sender information.

ARP _ announcement is used to limit whether the ip address of the sending port is used to set the source address of ARP: * "0" means that the source address of ARP request is set to the source address of ip packet. * "1"indicates that the source address of ARP request is not set with the source address of ip packet. If the source address of the ip packet and the ip address of the port are in the same subnet, use the source address of the IP packet to set the source address of the ARP request, otherwise, use the setting of "2". * "2" means that the source address of ARP request is not set with the source address of ip packet, but the system chooses the best interface to send it. When the machine in the intranet wants to send an ip packet, it will request the Mac address of the router and send an arp request, which contains its own ip address and Mac address. Linux uses the source ip address of ip as the source ip address in arp by default, instead of using the sending device, so that under the framework of lvs, all sent packets are the same VIP address. Then the arp request will contain the Vip address and device Mac, and the router will update its arp cache after receiving this arp request, which will cause IP fraud and Vip robbery, so there will be problems. Now suppose a scenario to explain the ip address of ARP _ announcement: real-server: 202.106.1.100 (public local address). 172.16.1.100 (private local address), 202.106.1.254 (Vip) If the source address of the arp request generated by the IP packet sent to the client is 202.106.6554866 ARP _ ignore–integer defines different modes of sending the reply. In response to the received ARP request to resolve the local target IP address: 0- (default): reply to any local target IP address, Configure1on any interface–reply only when the destination IP address is a local address configured on the incoming interface. 2–reply only when the destination IP address is a local address configured on the incoming interface and both IP addresses of the senders are from the same subnet on this interface. 3–Do not reply to the local address configured by the scope host, and only reply to the global and link addresses. 4-7–Keep 8–Use conf/{when not replying to all local address arp.

"0" means that any locally configured destination ip address will respond to the arp request, regardless of whether the destination address of the arp request is the IP of the interface; If there are multiple network cards, and the ip of each network card is a subnet, then the arp request from one port will also be sent back by other ports. "1" means that if the destination address of the arp request is not the ip address of the interface where the arp request packet entered, no response will be made. "2" is more demanding. In addition to the condition of "1", the ip address of the arp sender and the ip address of the interface where the arp request enters must be in the same network segment. (omitted later)

This article is from Jingxue. com (), please indicate the source: /sys/ Wei Yun/LVS-desanzhongmoshiqiujiexiangjie.htm.