트래픽이 도착하지만 통과되지 않음

BGP가 설정된 상태로 ONLINE인 사이트의 경우. 라우트가 문제라면 BGP부터 시작하십시오.

1. 폐기되고 있는 항목이 있습니까? 그 이유는? 문제를 재현하는 동안 dropstats-non-zero를 두 번 실행하십시오: 이 값들은 누적 합계이므로, 0이 아닌 카운터 자체는 아무 의미가 없으며, 증가하는 카운터가 모든 것을 의미합니다.

2. 특정 연결을 찾으십시오. 주소, 또는 주소와 포트를 사용하여 flow-l-match를 실행하십시오. 플로우에 대한 액션이 답입니다: F는 전달(forward), D는 폐기(drop), N은 NAT입니다. 액션이 D인 플로우가 존재한다면 의도적인 정책 결정이므로, 연결 문제가 아닌 정책 문제로 이동하십시오.

3. 플로우가 전혀 없습니까? 트래픽이 데이터 플레인에 도달하지 않고 있습니다. vif를 사용하여 데이터 플레인이 예상하는 인터페이스를 점유했는지 확인하고, 해당 카운터를 ip가 보고하는 값과 비교하십시오.

   두 뷰는 합법적으로 다를 수 있는데, 데이터 플레인이 처리하는 트래픽은 커널에 도달하지 않기 때문입니다. 그러나 예상하는 인터페이스의 RX가 0인 경우는 그렇지 않습니다.

4. 플로우가 존재하고 전달 중인데도 여전히 도착하지 않습니까? 트래픽이 어디로 전송되는지 확인하십시오: 라우트는 rt로, 다음 홉은 nh로 확인합니다. Drop 유형의 다음 홉은 블랙홀이며, Tunnel 다음 홉은 터널 자체를 범위 내에 두게 됩니다.

5. 경로가 터널을 통과하는 경우, ipsec-statusall을 사용하여 터널이 활성 상태이며 바이트를 전달하고 있는지 확인하십시오. 수 시간 동안 설정된 상태이지만 카운터가 거의 0인 터널은 활성화되어 있지만 사용되지 않는 것이며, 이는 라우팅 문제를 가리킵니다.

Argo와 Linux는 별도의 상태를 유지합니다

가장 혼란스러운 데이터 플레인 증상의 대부분은 커널의 뷰를 읽고 그것이 권위적이라고 가정하는 데서 발생합니다. ip는 Linux가 인식하는 것을 보여주고, rt, nh, vif는 실제로 트래픽을 전달하는 것을 보여줍니다. 이들이 서로 다를 때, 패킷을 실제로 이동시키는 것은 데이터 플레인입니다.