lỗi định tuyến linux?

Tôi đã phải vật lộn với vấn đề không dễ tái tạo này trong một thời gian. Tôi đang sử dụng linux kernel v3.1.0 và đôi khi định tuyến đến một vài địa chỉ IP không hoạt động. Điều dường như xảy ra là thay vì gửi gói đến cổng, hạt nhân coi địa chỉ đích là cục bộ và cố gắng lấy địa chỉ MAC của nó thông qua ARP.

Ví dụ: hiện tại địa chỉ IP hiện tại của tôi là 172.16.1.104/24, cổng là 172.16.1.254:

# ifconfig eth0 eth0      Link encap:Ethernet  HWaddr 00:1B:63:97:FC:DC
          inet addr:172.16.1.104  Bcast:172.16.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:230772 errors:0 dropped:0 overruns:0 frame:0
          TX packets:171013 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:191879370 (182.9 Mb)  TX bytes:47173253 (44.9 Mb)
          Interrupt:17

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.16.1.254    0.0.0.0         UG    0      0        0 eth0
172.16.1.0      0.0.0.0         255.255.255.0   U     1      0        0 eth0

Tôi có thể ping một vài địa chỉ, nhưng không phải là 172.16.0.59:

# ping -c1 172.16.1.254
PING 172.16.1.254 (172.16.1.254) 56(84) bytes of data.
64 bytes from 172.16.1.254: icmp_seq=1 ttl=64 time=0.383 ms

--- 172.16.1.254 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.383/0.383/0.383/0.000 ms
root@pozsybook:~# ping -c1 172.16.0.1
PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.
64 bytes from 172.16.0.1: icmp_seq=1 ttl=63 time=5.54 ms

--- 172.16.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5.545/5.545/5.545/0.000 ms
root@pozsybook:~# ping -c1 172.16.0.2
PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
64 bytes from 172.16.0.2: icmp_seq=1 ttl=62 time=7.92 ms

--- 172.16.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.925/7.925/7.925/0.000 ms
root@pozsybook:~# ping -c1 172.16.0.59
PING 172.16.0.59 (172.16.0.59) 56(84) bytes of data.
From 172.16.1.104 icmp_seq=1 Destination Host Unreachable

--- 172.16.0.59 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

Khi thử ping 172.16.0.59, tôi có thể thấy trong tcpdump rằng một req ARP đã được gửi:

# tcpdump -n -i eth0|grep ARP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
15:25:16.671217 ARP, Request who-has 172.16.0.59 tell 172.16.1.104, length 28

và / Proc / net / arp có một mục không đầy đủ cho 172.16.0.59:

# grep 172.16.0.59 /proc/net/arp
172.16.0.59      0x1         0x0         00:00:00:00:00:00     *        eth0

Xin lưu ý rằng có thể truy cập 172.16.0.59 từ mạng LAN này từ các máy tính khác.

Có ai có bất cứ ý tưởng về những gì đang xảy ra? Cảm ơn.

cập nhật: trả lời các ý kiến ​​dưới đây:

• không có giao diện nào ngoài eth0 và lo
• req ARP không thể được nhìn thấy ở đầu bên kia, nhưng đó là cách nó hoạt động. vấn đề chính là một req ARP thậm chí không nên được gửi ở nơi đầu tiên
• vấn đề vẫn tồn tại ngay cả khi tôi thêm một tuyến rõ ràng bằng lệnh "route add -host 172.16.0.59 gw 172.16.1.254 dev eth0"

Đây thực sự là một lỗi kernel linux, có lẽ kể từ phiên bản 2.6.39. Tôi đã đăng câu hỏi lên danh sách lkml và netdev (xem chủ đề tại https://lkml.org/lkml/2011/11/18/191 ), và nó chỉ được thảo luận trong một chủ đề netdev khác tại http: // www .spinics.net / danh sách / netdev / dir179687.html

Giải pháp hiện tại bây giờ là khởi động lại hoặc xóa tất cả các tuyến và đợi 10 phút để các chuyển hướng icmp hết hạn. Để ngăn chặn nó xảy ra lần nữa,

echo 0 >/proc/sys/net/ipv4/conf/eth0/accept_redirects

giúp.

Mặt nạ mạng con mặc định 172.16.XX là 255.255.0.0, bạn đã cấu hình lại thành 255.255.255.0. Vì vậy, các máy chủ lưu trữ thứ 172.16.0.x và 172.16.1.x nằm trên các mạng con khác nhau. do đó, nó sẽ thử và ROUTE thông qua cổng mặc định.

Thay đổi mặt nạ mạng con của bạn thành 255.255.0.0 sẽ giải quyết vấn đề.

Bạn có thể cung cấp một sơ đồ. Nếu bạn không thể vẽ một mạng, nó không thể được sửa chữa (câu tục ngữ của các kỹ sư mạng cũ ... của tôi!).

Chúc mừng