☰

2개의 NIC를 집계하는 시스템에 의한 "합법적인" ARP 중독으로 인해 충돌이 발생합니다.

tag-icon • tag-icon networking ip arp
2개의 NIC를 집계하는 시스템에 의한 "합법적인" ARP 중독으로 인해 충돌이 발생합니다.

이상한 일이 벌어지고 있고 위협이 가해지고 있으며 우리는 이 문제를 해결해야 합니다.

그 상황:

우리 장치(네트워크 카메라)는 네트워크를 통해 비디오를 레코더/서버로 스트리밍합니다(Live555 / WIS Streamer 사용). 비디오는 UDP 패킷입니다.

하나의 특정 서버를 사용하는 특정 사이트에서 매우 자주(~24시간) 비디오를 보내는 동안 Live555 스트리머의 스레드 하나가 잠깁니다. 다른 스레드는 계속 진행되고 있으며 여전히 IP를 통해 카메라에 연결되어 있습니다. 웹 페이지를 보고 PING하는 등의 작업을 수행합니다.

우리는 의심한다: 서버; 2개의 네트워크 포트가 있고 이를 통합합니다. MAC은 2개이지만 IP 주소는 1개입니다. 이것을 와이어샤킹할 때 카메라가 한 포트(A라고 부르자)로 스트리밍하는 것을 본 다음 다른 포트(B라고 부르자)에서 ARP를 얻습니다. 장치는 MAC A로 패킷 전송을 중지하고 와이어 위로 패킷 하나를 전송합니다. MAC B로 이동한 후 해당 트랙에서 중지된 것처럼 보입니다.

추가 정보: 서버는 잘못된 구성 등의 결과로 "잘못된" 포트의 ARP 패킷을 손상시킨 것으로 보입니다. 하지만 해당 패킷은 여전히 ​​장치에서 읽고 작동합니다. 드라이버나 커널 네트워킹이 잘못 구성되었거나 CPU 주기를 절약하기 위해 체크섬을 건너뜁니다.

따라서 이 지저분한 상황은 몇 가지 질문을 불러일으킵니다.

  1. 패킷 체크섬을 확인하거나 확인을 활성화하려면 커널 네트워킹 코드의 어디에서 찾아야 합니까? 우리의 하드웨어는 임베디드 장치로 고정되어 있으므로 드라이버를 조정하는 것이 최악의 아이디어는 아닙니다.
  2. send()포트에서 지속적으로 데이터를 수신하고 ARP 테이블이 그 아래로 이동할 때 프로세스가 잠기는 오류 메커니즘을 추측할 수 있는 사람이 있습니까 ?

추가하도록 수정했습니다: 이제 우리는 ARP가 실제로 손상된 것이 아니라 Wireshark가 패킷을 올바르게 식별하지 못하고 있다고 의심합니다(패킷이 FSC 단어가 있어야 할 만큼 길다고 생각하지만 지금은 단지 제로 패딩이라고 생각합니다). 이제 이 질문의 파트 2만 남았습니다. ARP 테이블의 이러한 변경으로 인해 전송 프로세스가 중단되는 것을 방지하려면 어떻게 해야 할까요?

더 추가하려면 편집하세요.사람들이 내가 포트 상태나 프로세스 상태에 대한 질문을 무시하고 있다고 생각하기를 원하지 않습니다. 문제는 매우 드물게 발생하며(평균적으로 24시간에 한 번) 쉽게 액세스할 수 없는 하나의 (원격) 설치에서만 발생합니다. 우리는 보다 자세한 진단을 수행할 수 있도록 연구실에서 이를 복제하려고 열심히 노력하고 있지만 시스템 감시는 문제 발생 후 ~3분 이내에 재설정되므로 뉴스가 우리에게 전달될 때쯤에는 이미 재부팅되어 제대로 작동하기 시작했습니다.

Wireshark 정보를 추가하려면 편집하세요.: 여기에서 Wireshark 캡처를 요약하는 가장 좋은 방법은 잘 모르겠지만(캡처된 패킷의 최대 1Tb를 업로드하는 것은 매우 어렵습니다!) 시도해 보겠습니다. Cam:X&는 Cam:Y서로 다른 포트에서 두 개의 동일한 Live555 WIS Streamer 인스턴스에 의해 스트리밍되는 두 개의 RTSP 비디오 스트림입니다. 서버 'A'와 'B'는 서버에 있는 두 NIC의 MAC입니다.

패킷의 순서는 다음과 같습니다.

UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
ARP Packet to Cam from Server 'B' "<my IP> is now on 'B'"
Intel ANS Probe broadcast from Server 'B', Sender ID '1' team ID 'B'
Intel ANS Probe broadcast from Server 'A', Sender ID '2' team ID 'B'
<silence> from Cam:X
UDP Packet from Cam:Y -> Server 'B'
UDP Packet from Cam:Y -> Server 'B'
UDP Packet from Cam:Y -> Server 'B'

이 시간이나 그 무렵에 스트림에 다른 패킷이 없습니다. Intel ANS 패킷이 항상 NIC의 ARP와 일치하는 것은 아니지만 완전성을 위해 포함하겠다고 생각했습니다.

문제는 타이밍에 매우 민감한 것 같습니다. 우리는 서버에서 이러한 "팀" ARP를 정기적으로 확인하며 블루문에서 단 한 번만 문제를 일으킵니다. 마치 네트워크 스택 코드에 민감한 특정 지점이 있는 것처럼 보입니다. ARP 테이블 변경. 항상 동일한 스트림 인스턴스가 실패하는 것은 아니며 특히 다른 인스턴스(다른 모든 네트워크 트래픽(HTTP 등) 포함)는 계속해서 정상적으로 작동합니다.

팀으로 구성된 NIC는 이 중간 세션처럼 ARP를 "해서는 안 되는" 것처럼 들리지만 물론 트래픽이 모두 UDP인 경우 어떤 세션도 인식하지 못할 것입니다.

답변1

글쎄, 조금만 주면폐쇄이에 대해 고객은 의심스러운 네트워크 카드를 재구성했고 모든 것이 제대로 작동했습니다. 따라서 호기심이 많은 사람에게는 불행하게도 아무도 해당 사례를 해결하기 위해 수행할 수 있었던 작업을 너무 자세히 살펴보기 위해 누구에게도 비용을 지불하지 않을 것임을 의미합니다.

관련 정보