☰

더미 인터페이스에 연결할 때 중복된 ICMP 에코 응답을 중지하시겠습니까?

tag-icon • tag-icon linux bridge icmp
더미 인터페이스에 연결할 때 중복된 ICMP 에코 응답을 중지하시겠습니까?

최근에 (real ) 및 ( ) br0멤버로 브리지를 구성했습니다 .eth0ifdummy0dummy.ko if

이 컴퓨터에 ping을 실행하면 다음과 같은 중복된 응답을 받습니다.

  # ping SERVERA
  PING SERVERA.domain.local (192.168.100.115) 56(84) bytes of data.
  64 bytes from SERVERA.domain.local (192.168.100.115): icmp_seq=1 ttl=62 time=113 ms
  64 bytes from SERVERA.domain.local (192.168.100.115): icmp_seq=1 ttl=62 time=114 ms (DUP!)
  64 bytes from SERVERA.domain.local (192.168.100.115): icmp_seq=2 ttl=62 time=113 ms
  64 bytes from SERVERA.domain.local (192.168.100.115): icmp_seq=2 ttl=62 time=113 ms (DUP!)

tcpdumpon 을 사용하면 다음 과 같이 SERVERAicmp 에코 응답이 다음과 같이 전송되는 것을 볼 수 있었습니다 (이상하게 두 개의 에코 요청 패킷이 내 Windows 상자 "에서" 도착함 ).eth0br0myhost

  23:19:05.324192 IP myhost.domain.local > SERVERA.domain.local: ICMP echo request, id 512, seq 43781, length 40
  23:19:05.324212 IP SERVERA.domain.local > myhost.domain.local: ICMP echo reply, id 512, seq 43781, length 40
  23:19:05.324217 IP myhost.domain.local > SERVERA.domain.local: ICMP echo request, id 512, seq 43781, length 40
  23:19:05.324221 IP SERVERA.domain.local > myhost.domain.local: ICMP echo reply, id 512, seq 43781, length 40
  23:19:05.324264 IP SERVERA.domain.local > myhost.domain.local: ICMP echo reply, id 512, seq 43781, length 40
  23:19:05.324272 IP SERVERA.domain.local > myhost.domain.local: ICMP echo reply, id 512, seq 43781, length 40

테스트 결과 동일한 물리적 스위치에 있는 호스트에는 DUP가 표시되지 않는 것으로 나타났습니다 icmp echo responses(다른 스위치에 있는 동일한 VLAN에 있는 호스트에는 dup이 표시됨 icmp echo response).

ARP스위치 테이블 때문일 수 있다는 내용을 읽었 지만 bridges과 직접 관련된 정보는 찾을 수 없습니다 bonds. 내 문제는 스위치가 아닌 Linux의 스택에 있다는 느낌이 들지만 어떤 제안이라도 받아들일 수 있습니다.

시스템이 centos6/el6 커널을 실행 중입니다 2.6.32-71.29.1.el6.i686.

브리지 인터페이스/브리지 인터페이스를 처리할 때 ICMP 에코 응답이 중복으로 전송되는 것을 어떻게 중지합니까?

감사해요,

매트

[편집하다]

빠른 참고 사항: #linux에서는 다음을 권장합니다.

[08:53] == mbrownnyc [gateway/web/freenode/] has joined ##linux
[08:57] <lkeijser> mbrownnyc: what happens if you set arp_ignore to 1 for the dummy interface?
[08:59] <lkeijser> also set arp_announce to 2 for that interface
[09:24] <mbrownnyc> lkeijser: I set arp_annouce to 2, arp_ignore to 2 in /etc/sysctl.conf and rebooted the machine... verifying that the bits are set after boot... the problem is still present

나는 이것을했고 비어있었습니다. 동일한 중복 문제입니다.

다음과 같이 브리지에 더미 인터페이스를 포함하지 않을 예정입니다.

[09:31] == mbrownnyc [gateway/web/freenode/] has joined #Netfilter
[09:31] <mbrownnyc> Hello all... I'm wondering, is it correct that even with an interface in PROMISC that the kernel will drop /some/ packets before they reach applications?
[09:31] <whaffle> What would you make think so?
[09:32] <mbrownnyc> I ask because I am receiving ICMP echo replies after configuring a bridge with a dummy interface in order for ipt_netflow to see all packets, only as reported in it's documentation: http://ipt-netflow.git.sourceforge.net/git/gitweb.cgi?p=ipt-netflow/ipt-netflow;a=blob;f=README.promisc
[09:32] <mbrownnyc> but I do not know if PROMISC will do the same job
[09:33] <mbrownnyc> I was referred here from #linux.  any assistance is appreciated
[09:33] <whaffle> The following conditions need to be met: PROMISC is enabled (bridges and applications like tcpdump will do this automatically, otherwise they won't function).
[09:34] <whaffle> If an interface is part of a bridge, then all packets that enter the bridge should already be visible in the raw table.
[09:35] <mbrownnyc> thanks whaffle PROMISC must be set manually for ipt_netflow to function, but
[09:36] <whaffle> promisc does not need to be set manually, because the bridge will do it for you.
[09:36] <whaffle> When you do not have a bridge, you can easily create one, thereby rendering any kernel patches moot.
[09:36] <mbrownnyc> whaffle: I speak without the bridge
[09:36] <whaffle> It is perfectly valid to have a "half-bridge" with only a single interface in it.
[09:36] <mbrownnyc> whaffle: I am unfamiliar with the raw table, does this mean that PROMISC allows the raw table to be populated with packets the same as if the interface was part of a bridge?
[09:37] <whaffle> Promisc mode will cause packets with {a dst MAC address that does not equal the interface's MAC address} to be delivered from the NIC into the kernel nevertheless.
[09:37] <mbrownnyc> whaffle: I suppose I mean to clearly ask: what benefit would creating a bridge have over setting an interface PROMISC?
[09:38] <mbrownnyc> whaffle: from your last answer I feel that the answer to my question is "none," is this correct?
[09:39] <whaffle> Furthermore, the linux kernel itself has a check for {packets with a non-local MAC address}, so that packets that will not enter a bridge will be discarded as well, even in the face of PROMISC.
[09:46] <mbrownnyc> whaffle: so, this last bit of information is quite clearly why I would need and want a bridge in my situation
[09:46] <mbrownnyc> okay, the ICMP echo reply duplicate issue is likely out of the realm of this channel, but I sincerely appreciate the info on the kernels inner-workings
[09:52] <whaffle> mbrownnyc: either the kernel patch, or a bridge with an interface. Since the latter is quicker, yes
[09:54] <mbrownnyc> thanks whaffle

[편집2]

브리지를 제거하고 더미 커널 모듈을 제거한 후에는 단 하나의 인터페이스만 조용하고 외로웠습니다. 여전히 중복된 ICMP 에코 응답을 받았습니다. 사실 무작위 금액을 받았습니다.http://pastebin.com/2LNs0GM8

동일한 스위치의 다른 몇몇 호스트에서는 동일한 일이 발생하지 않으므로 Linux 상자 자체와 관련이 있습니다. 아마 다음 주에 다시 재건하게 될 것 같아요. 그러면... 아시다시피... 이와 같은 일이 다시 일어날 것입니다.

[편집3] 뭔지 맞춰봐? 상자를 재구축했는데 여전히 중복된 ICMP 에코 응답이 수신됩니다. ARP 테이블에 여러 항목이 포함되어 있지 않더라도 네트워크 인프라여야 합니다.

[편집4] 정말 우스꽝 스럽습니다.

머신은 네트워크 프로브였으므로 업링크 포트를 NIC인 노드로 미러링(수신 및 송신)했습니다. 따라서 흐름은 다음과 같이 진행되어야 합니다.

  1. ICMP echo request를 통해 들어옵니다 mirrored uplink port.
  2. (실제)는 ICMP echo requestNIC에서 수신됩니다.
  3. (미러링된)은 ICMP echo requestNIC에서 수신됩니다.
  4. ICMP echo reply둘 다에 대해 전송됩니다.

제 자신이 부끄럽지만 이제 알겠습니다. #networking미러링된 트래픽을 IP가 활성화되지 않은 인터페이스로 격리하는 것이 제안되었습니다 . 또 다른 해결책은 관리 VLAN을 생성하고 관리 VLAN에 대한 패킷 미러링을 제거하는 것입니다(불행히도 내 스위치에는 옵션이 없음).

답변1

알겠어요. 당신이 찾고 있는 것은 채권입니다. 브리지에는 브리지 인터페이스의 주소를 상속받아 수신한 패킷에 대해 모두 독립적으로 작동하는 다중 인터페이스가 있습니다. 이는 컴퓨터를 통해 두 개의 네트워크 스위치를 연결할 때 유용합니다. 둘 다 동일한 스위치에 연결하면 이러한 다중 응답 동작을 볼 수 있습니다.

반면에 채권은 채권에 포함된 차량 한 대만 교통을 처리하도록 보장하는 동작을 제공합니다. 이는 본드 인터페이스 구성 방법에 따라 활성/수동 장애 조치, 스위치와의 본딩 또는 카드 순환을 통해 이루어질 수 있습니다.

본드 인터페이스에 연결된 케이블이 하나만 있기 때문에 스위치는 실제로 방정식의 일부가 아닙니다.

답변2

VMware를 사용하여 VM의 복제본을 만들었고 동일한 문제가 발생했습니다. 새 VM의 네트워킹 카드에는 새 MAC 주소가 있습니다. 고칠 수 있는 방법이 있는데, (이미 예전에 했던 일인데) 급했기 때문입니다. 새 VM을 삭제하고 이전 MAC 주소로 다시 복제하면 모든 것이 정상이었습니다.

관련 정보