Knowledge map advanced must read: read how large-scale map data efficient storage and retrieval>>>

The way to solve the problem is as follows

1. Check the router

2. To check the server, first Ping the next router (intended to test the connection problem with the router), the results are as follows:

From 192.168.1.10: icmp_ seq=1 Redirect Network(New nexthop: 192.168.1.1)

From 192.168.1.10: icmp_ seq=2 Redirect Network(New nexthop: 192.168.1.1)

From 192.168.1.10: icmp_ seq=3 Redirect Network(New nexthop: 192.168.1.1)

At that time, the first reaction was that there would not be any ARP virus on 192.168.1.10, but the next machine was hard to find, so we had to remove the network from this machine, but there was still a problem

3. The problem of ARP is located

Modifying kernel parameters

net.ipv4.conf.eth0.accept_ redirects=0

net.ipv4.conf.all.accept_ redirects=0

net.ipv4.conf.default.accept_ redirects=0

After modification, run the following command to make the parameter effective
/SBIN/sysctl – P

Confirm that these values are all 0, and continue to check ARP – A

It’s as slow as an ox, but I found a problem

(192.168.1.1) at 5c:dd:70:46:5c:3e [ether] PERM on eth0

The original one is perm, which obviously does the binding of IP and MAC, and it’s 192.168.1.1 (Gateway). This MAC address seems to be the same as the original router’s MAC address, but we changed the new router’s MAC address. The problem is that it’s different

So that’s the problem

4. Dealing with problems

Collect the MAC of the current router

vim /etc/ethers

192.168.1.1 new Mac

arp -f

arp -a

ping 192.168.1.1