요약

  • RIPE NCC에 따르면 10월 2일 01:30 UTC에 DE-CIX 피어 한 곳이 라우트 컬렉터 RRC12에 비정상적으로 많은 수의 BGP 메시지를 보내기 시작했고, 그 이후 Kafka에서 업데이트를 소비하는 처리 파이프라인이 반복적으로 시간 초과되었다.
  • 같은 날 19:10 UTC에 확인한 결과 RRC12의 공개 10월 아카이브는 여전히 01:00 UTC에서 끝나고 있었다. 이는 측정 서비스의 공개 지연일 뿐, 인터넷 경로 누락이나 트래픽 중단의 증거가 아니다.

분석

RIPE NCC는 10월 2일 09:42 CEST에 “RRC12 MRT 업데이트 파일이 생성되지 않음”이라는 상태 인시던트를 열었다. 첫 공지에서 최신 RRC12 업데이트 파일의 타임스탬프는 01:00 UTC, 최신 BVIEW 스냅샷은 00:00 UTC라고 밝혔다. 13:26 CEST에는 DE-CIX 피어 한 곳이 01:30 UTC부터 RRC12에 비정상적으로 많은 BGP 메시지를 보내기 시작했다고 설명했다. Kafka에서 업데이트를 소비하는 프로세스가 처리량을 따라가지 못했고, 재시작할 때마다 충분한 진행 전에 다시 시간 초과되었다고 한다. RIPE는 다른 RRC의 업데이트 파일 생성에도 지연이 있다고 보고했다.

RRC12는 DE-CIX에 연결된 프랑크푸르트의 라우트 컬렉터다. 라우트 컬렉터는 피어로부터 BGP 데이터를 수신하며, 해당 네트워크가 사용할 경로를 선택하지는 않는다. RIPE 문서에 따르면 수집된 데이터는 컬렉터별로 저장되며, “업데이트” 파일은 일정 구간의 변경 사항을 기록하고 BVIEW 파일은 상태 스냅샷을 저장한다. 업데이트 파일은 보통 5분마다 생성된다고 명시하고 있다. 이는 관측 피드의 공개 주기이며, 모든 컬렉터가 항상 이를 지킨다는 약속이 아니다.

19:10 UTC에 RIPE 공개 아카이브를 읽기 전용으로 확인한 결과,updates.20261002.0100.gz보다 새로운 RRC12 업데이트는 없었다. 확인 시점보다 18시간 10분 전 타임스탬프였다. RRC18 아카이브는 19:05 UTC까지 도달해 있었다. 이 비교는 그 시점 두 공개 디렉터리 간의 가시적 신선도 차이를 보여줄 뿐이며, 다른 모든 컬렉터가 영향받지 않았다는 것, 어떤 컬렉터가 더 일찍 지연을 겪었는지, RRC18에 더 새로운 파일이 있었던 이유를 설명하지 않는다.

리뷰 마감 시점에 상태 기록은 식별된 상태로 문제 해결 중이었다. 이 기록은 해당 피어의 이름이나 메시지 전송률, 관련 경로, 다른 컬렉터의 지연 기간, 큐의 재생 상태, 복구 계획을 공개하지 않았다. 경로가 손실되었거나 트래픽이 중단되었다고도 말하지 않았다. 파일이 지연되었다는 것은 분석가가 빈 구간을 해석하기 전에 파일 타임스탬프를 확인해야 한다는 뜻이며, BGP 변경이 없었다는 증거로 읽어서는 안 된다.

유용한 다음 업데이트는 짧은 복구 확인증이다. 영향받은 컬렉터의 최신 업데이트 및 BVIEW 타임스탬프, 지연된 구간이 재생되었는지 여부, 정상 공개가 언제 재개되었는지가 그 내용이다. 이를 통해 RIS 데이터 사용자는 아카이브 지연이 라우팅 시스템 자체를 바꿨다는 함의 없이 수집, 처리, 공개 상태를 구분할 수 있게 된다.

출처