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
one two three four |
|
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