요약

  • 링크가 살아 있어도, RIP가 유일한 경로 정보원이고 경로가 15홉을 넘는다면 지사 직원은 주문을 제출하지 못할 수 있다.
  • 장애 이후에는 오래된 경로가 잘못된 방향으로 트래픽을 계속 보낼 수 있다. RFC 1058은 이 카운트를 제한하기 위해 16을 사용했지, 즉각적인 서비스 복구를 약속하기 위해서가 아니었다.

경로가 너무 길어서 존재할 수 없는 경우

지사 직원이 마감 전에 주문을 제출하는 상황을 상상해 보자. 링크 표시등은 켜져 있지만, RIP가 유일한 경로 정보원이고 목적지가 메트릭 상한 너머에 있다면 게이트웨이는 광고할 수 있는 사용 가능한 경로를 갖지 못한다. 주문은 지사를 떠날 수 없다. 이번에는 다른 장애를 상상해 보자. 한 게이트웨이가 목적지를 철회했는데 그 이웃이 여전히 그 게이트웨이 쪽을 가리키고 있어, 복구 중에도 패킷이 잘못된 경로를 따라 흐를 수 있다. 이는 설명을 위한 시나리오이지 1988년에 실제 보고된 사고가 아니다. RFC 1058은 명명된 장애가 아니라 메커니즘을 기술한다.

RIP의 1988년 사양은 이 문제에 의도적으로 작은 정지점을 부여했다.RFC 1058에서 1부터 15까지의 경로 메트릭은 사용 가능했고, 16은 도달 불가를 나타냈다. 따라서 16은 무한히 먼 네트워크의 문자적 측정값이 아니었다. 그것은 프로토콜이 광고할 수 있는 경로와 철회해야 하는 경로 사이에 선택한 경계였다.

이 경계는 실질적인 타협을 강제했다. 16을 "무한대"라고 부르는 프로토콜은 메트릭이 15를 넘는 유효한 경로를 표현할 수 없다. Hedrick의 메모는 이 설계가 중간 규모 네트워크를 겨냥한 것이며, 설계자들이 RIP가 지름 15를 넘어서는 실용적이지 않을 것이라고 보았다는 견해를 기록한다. 작은 상한은 또한 오래된 경로가 프로토콜이 더 이상 계산하지 않을 때까지 거쳐야 하는 증분 수를 줄였다.

숫자 자체는 해결책이 아니었다

RFC 1058은 낮은 상한을 완전한 해결책으로 제시하지 않는다. 이 문서는 무한대까지 카운트하는 현상을 수렴 실패로 기술하고, 스플릿 호라이즌, 포이즌드 리버스, 트리거드 업데이트를 추가 안전장치로 논의한다. 그런 제어조차 한계가 있었다. 트리거드 업데이트가 늦게 도착하면 잔존한 잘못된 경로가 순환하는 것을 막지 못해, 무한대까지 카운트하는 일은 여전히 가능했다.

메트릭은 장애를 한 방식으로는 유한하게 만들었지만 무해하게 만들지는 않았다. 게이트웨이들이 카운트하는 동안에도 잘못된 경로로 패킷을 보낼 수 있었다. 경로는 서비스를 방해할 만큼 오랫동안 유한하게 잘못될 수 있다. "16"은 제어 평면이 언제 그 경로를 더 이상 사용 가능하다고 취급하지 않는지를 답할 뿐, 그 이전에 모든 패킷이 작동하는 경로를 거쳤다는 것을 증명하지는 않는다.

이후 문서들도 이 구분을 유지한다.RFC 2453, 즉 RIP 버전 2 사양은 프로토콜의 한계와 루프 동작을 기술하면서 16을 무한대로 유지했다.RFC 1812는 RIP를 역사적 라우팅 프로토콜로 기록하는데, 잘 문서화된 메커니즘이라고 해서 보편적인 라우팅 설계는 아니라는 점을 일깨워 준다.

작은 네트워크는 설계의 일부였다

16을 임의의 오래된 상수로 읽고 싶은 유혹이 있다. 하지만 메모는 더 많은 것을 드러내는 설명을 제공한다. 무한대 값은 필요 이상으로 크지 않아야 하는데, 장애 이후 한 단계가 늘어날 때마다 카운트가 길어질 수 있기 때문이다. 동시에 평범한 경로를 표현할 수 없을 만큼 작아서도 안 된다. 이 선택은 잘못된 정보가 살아남을 때 네트워크 지름과 복구 시간 사이에서 균형을 맞춘다.

그렇다면 이 상한은 단지 패킷 필드의 세부 사항이 아니라 운영 가정이다. RIP를 선택한 네트워크 운영자는 토폴로지 범위도 함께 수용한 것이다. 네트워크가 그 범위를 넘어 성장하면, 어떤 타이머 조정으로도 메트릭 16의 경로를 프로토콜의 의미에서 유효하게 만들 수 없다. 시스템은 표현의 한계점에 도달한 것이다.

이 교훈은 RIP를 넘어 확장된다. 유한한 값은 장애가 퍼지는 시간이나 공간을 제한할 수 있지만, 그 대가로 일부 원래는 생각할 수 있었던 상태를 범위 밖으로 선언해야 한다. 설계자는 그 비용을 누가 부담하는지 물어야 한다. 프로토콜의 수렴 동작인가, 재설계를 해야 하는 운영자인가, 아니면 경로를 표현할 수 없게 되는 사용자인가. 1988년, RIP는 이 선택을 이례적으로 명확하게 드러냈다. 16이란, RIP의 지도가 길을 알고 있다는 주장을 멈춘 지점이었다.

주요 문서:RFC 1058,RFC 2453,RFC 1812.