리눅스 라우팅 버그?


9

나는 이래로 쉽게 재현 할 수없는 문제로 어려움을 겪고있다. Linux 커널 v3.1.0을 사용하고 있으며 때로는 일부 IP 주소로 라우팅이 작동하지 않습니다. 패킷이 게이트웨이로 전송되는 대신 커널은 대상 주소를 로컬로 처리하고 ARP를 통해 MAC 주소를 가져 오려고합니다.

예를 들어, 현재 내 IP 주소는 172.16.1.104/24이고 게이트웨이는 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

몇 가지 주소를 핑할 수 있지만 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

172.16.0.59를 핑하려고하면 tcpdump에서 ARP 요청이 전송되었음을 알 수 있습니다.

# 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

/ proc / net / arp에 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

172.16.0.59이 있음을 유의하시기 바랍니다 이며 다른 컴퓨터에서이 LAN에서 액세스 할 수.

아무도 무슨 일이 일어나고 있는지 알고 있습니까? 감사.

업데이트 : 아래의 의견에 답변 :

  • eth0과 lo 외에 인터페이스가 없습니다.
  • ARP 요청은 다른 쪽에서는 볼 수 없지만 그것이 작동하는 방식입니다. 주요 문제는 ARP req가 처음부터 전송되어서는 안된다는 것입니다
  • "route add -host 172.16.0.59 gw 172.16.1.254 dev eth0"명령으로 명시 적 경로를 추가하더라도 문제가 지속됩니다.

나는 이것이 일종의 기본 행동이라고 생각합니다 .ARP 테이블도 보자? 다른 쪽 끝의 arp 테이블이 여기에 유용 할 수 있습니다.
SpacemanSpiff

어떻게 고치나요? 호스트 별 경로를 설정하면 다시 작동합니까? 호스트가 대상이 로컬이라고 생각하게하는 ICMP 리디렉션을 받는지 궁금합니다.
Paul

arp 회신이 다시 오지 않는 것 같습니다. 172.16.0.59 호스트에서 tcpdump 할 수 있습니까? VM 게스트입니까? 호스트의 네트워크 트래픽도 확인하십시오.
AndreasM

당신은 출력을 게시 할 수 있습니까 ifconfig -a? 이 호스트에 다른 인터페이스 / IP가 할당되어 있습니까?
Khaled

답글로 질문을 업데이트했습니다
Balázs Pozsár

답변:


7

실제로 2.6.39 버전 이후의 리눅스 커널 버그입니다. 질문을 lkml 및 netdev 목록에 게시했으며 ( https://lkml.org/lkml/2011/11/18/191 의 스레드 참조 ) http : // www 의 다른 netdev 스레드에서 방금 논의되었습니다. .spinics.net / lists / netdev / msg179687.html

현재 솔루션은 이제 다시 부팅하거나 모든 경로를 플러시하고 icmp 리디렉션이 만료 될 때까지 10 분 동안 기다립니다. 다시 발생하지 않도록

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

도움이됩니다.


불행히도 위의 내용은 도움이되지 않는 것 같습니다.
sivann

모든 인터페이스에 대해이를 시도하십시오. find / proc / sys / net -name accept_redirects | x를 읽는 동안; echo -n 0> $ x를하십시오; 완료 또는 다른 버그가 있습니다
Balázs Pozsár

고마워, 나는 모든 인터페이스에 대해 이미 활성화했다. IP는 IPSEC 터널에서 온 것으로 (이 머신에는 장애물이 있음) 항상 eth0 인터페이스의 arp 테이블에 5-10 (172.x)이 나열되고 (불완전한) HWaddress 및 누락 된 HWtype으로 나열됩니다. 그것들은 만료되는 것처럼 보이고 새로운 것들이 대신하지만 때로는 재부팅이 필요합니다.
Sivann

-1

172.16.XX 기본 서브넷 마스크는 255.255.0.0이며 255.255.255.0으로 재구성했습니다. 따라서 호스트 172.16.0.x와 172.16.1.x는 서로 다른 서브넷에 있습니다. 따라서 기본 게이트웨이를 통해 시도하고 라우팅합니다.

서브넷 마스크를 255.255.0.0으로 변경하면 문제가 해결됩니다.

다이어그램을 제공 할 수 있습니까? 네트워크를 그릴 수 없다면 고칠 수 없습니다 (오래된 네트워크 엔지니어는 저에게 속입니다!).

건배,


네트워크 다이어그램 그리기에 어떤 웹 앱 또는 경량 데스크톱 앱을 추천 하시겠습니까?
벨민 페르난데스

"기본"넷 마스크와 일반적으로 관련이 없습니다. 어쨌든, 위의 대답을 참조하십시오.
Balázs Pozsár

마크 다운 주셔서 감사합니다. 라우터가 ICMP 리디렉션을 생성한다고 생각하는 이유는 무엇입니까?
유닉스 청소부

라우터는 호스트가 다른 게이트웨이를 사용해야하기 때문에 리디렉션을 생성합니다. 문제에 대한 이해가 버그라고 생각합니다. 달리 교육하고 싶지 않다면
유닉스 청소부

허용 된 답변에 링크 된 스레드를 읽으십시오. 문제는 이러한 라우팅 정보가 없어도 버려지지 않는다는 것입니다. 라우터 / 게이트웨이에는 문제가 없습니다.
Baláss Pozsár
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.