☰

경로 추가/삭제 후 타이밍 문제(경로가 사용되지 않음)

tag-icon • tag-icon linux routing socket
경로 추가/삭제 후 타이밍 문제(경로가 사용되지 않음)

원시 IP 소켓을 실행하는 애플리케이션이 있는데, 이 소켓의 대상은 'ip Route add' 명령을 통해 설치된 경로에 의해 관리됩니다. 이러한 경로는 소켓 수명 동안 변경될 수 있습니다(예: 다음 홉 변경으로 인해).

단순화하여 2개의 인터페이스 가 있고 eth0. eth1을 통한 기본 경로도 있습니다 eth0.

예를 들어 원시 소켓의 끝점은 10.10.10.10eth1에 주소가 있습니다. 100.0.0.1원시 소켓의 수명 동안 다음을 수행합니다.

ip -f inet route delete 10.10.10.10
ip -f inet route add 100.0.0.2 dev eth1
ip -f inet route add 10.10.10.10/32 via 100.0.0.2 dev eth1

이제 내가 보는 것은 이 작업 트래픽이 몇 초 동안 올바르게 진행된 후 eth1짧은 동안(0.5초 미만) 동안(eth0을 통해) 잘못되었다가 다시 정확하다는 것입니다(영구적으로 볼 수 있는 한). ).

그래서 내 주요 질문은 다음과 같습니다. - 여기서 무엇이 잘못될 수 있는지 설명할 수 있는 사람이 있습니까? ip route flush cache앞서 언급한 순서 뒤에 추가를 시도했지만 아무 효과가 없었습니다. 나는 현재 트래픽이 때때로 중단되는 이유에 대해 의아해합니다. 라우팅 명령의 타이밍 문제이거나 순간적으로 경로를 비활성화하는 다른 트리거라고 생각하지만 옵션이 부족합니다.

내 원시 소켓에서 옵션을 사용하려고 시도했지만 SO_BINDTODEVICE아쉽게도 별 도움이 되지 않았습니다. 주요 차이점은 트래픽이 잘못되면 전송되지 않는다는 것입니다.조금도, 잘못된 인터페이스를 거치게 되기 때문입니다. 그러나 내가 바랐던 것은 이것이 errno를 E_CANNOTROUTE(존재하지 않음)와 같은 것으로 설정하여 이를 포착하고 패킷 전송을 다시 시도할 수 있다는 것이었습니다. 현재는 이 작업을 수행하지 않지만 이러한 오류를 잡을 수 있는 방법이 있습니까? 나는 시스템과 소켓을 실행하는 애플리케이션에 대해 (거의) 모든 권한을 갖고 있습니다.

내가 아는 한 가지 해결책은 L3 원시 소켓을 사용하지 않고 소켓을 사용하는 것입니다 AF_PACKET(그리고 ARP/ND도 직접 수행함). 하지만 아직은 이에 대해 다루지 않겠습니다.

업데이트

이 경로 변경 동작을 변경하여 시스템의 동작을 개선했습니다. 다음 홉을 업데이트해야 할 때 이제 이미 설치된 경로를 살펴보고 이를 기반으로 조치를 취합니다.

  • 거기에 없으면 새 경로를 설치하고 삭제를 건너뜁니다.
  • 정확한 경로가 이미 존재한다면(동일한 nh, 동일한 개발), 이제 아무것도 하지 않습니다.
  • 이 경로에 대해 다른 nh가 존재하는 경우 이제 이 nh에 대해서만 보다 구체적인 삭제를 수행한 다음 추가합니다.

이로 인해 대부분의 문제가 안정화되었지만 실제 삭제+추가가 발생할 때(새 메커니즘의 마지막 경우) 여전히 동일한 일이 발생하는 경우가 있습니다(훨씬 덜 자주). 또한 이것은 실제로 무엇이 잘못되었는지 설명하지 못하므로(단순히 이를 우회할 뿐입니다) 여기서 무엇이 잘못되었는지 정말 궁금하기 때문에 지금은 이 질문을 열어 두겠습니다.

참고: centos4에서 centos6, 32비트로 이동하는 것을 볼 수 있는 한 centos에 문제가 있습니다.

답변1

내가 올바르게 이해했다면 패킷은 항상 eth1 밖으로 나가야 하며, 문제는 eth1의 새로운 다음 홉으로 업데이트할 때 패킷이 때때로 eth0 밖으로 나가는 것입니다. 삭제+추가가 원자적 작업이 아니기 때문입니다.

먼저 추가를 수행한 다음 삭제를 수행해 보십시오. 방금 추가한 새 경로도 삭제되지 않도록 삭제는 구체적이어야 합니다(제가 생각하는 장치 및 다음 홉을 사용하여).

답변2

eth0을 통한 기본 경로(또는 10.10.10.10/32를 포함하는 다른 경로)가 있습니까? 먼저 삭제한 다음 추가하는 경우 삭제가 발생하고 삭제와 추가 사이의 시간 동안 패킷이 기본 경로를 빠져나간 다음 추가가 발생하고 패킷이 예상한 곳으로 이동하기 시작하는 경쟁 조건이 발생할 수 있습니다.

그것은 분명히 일종의 경쟁 조건처럼 들립니다. 이는 귀하가 언급한 두 가지 라우팅 작업의 비원자적 특성 때문일 가능성이 높습니다(Law29에서 설명한 대로).

관련 정보