두 고객 경로를 하나의 요약 경로로 광고한 뒤 한 고객 경로만 사라졌습니다. 요약 라우터는 무엇을 해야 하나요?

요약 라우터는 aggregate에는 일치하지만 살아 있는 more-specific constituent에는 일치하지 않는 패킷을 discard 또는 null 경로로 폐기해야 합니다. 구체적으로 198.51.100.0/24와 198.51.101.0/24를 198.51.100.0/23으로 광고한 뒤 198.51.101.0/24 연결이 사라졌다고 하겠습니다. 목적지 198.51.101.7에는 살아 있는 /24가 없으므로 /23의 null이 선택되어야 합니다. null이 없으면 라우터가 /16 같은 상위 경로로 되돌려 보내 부모와 자식 사이 forwarding loop가 생길 수 있습니다.

반면 198.51.100.0/24가 살아 있으면 그 /24가 /23보다 길어 정상 경로로 전달됩니다. 상태를 more-specific .100/24=up, .101/24=down, summary .100/23=advertised, null .100/23=installed로 나누면 선택 결과가 분명합니다. RFC 4632 §5.1은 aggregate에 맞고 더 구체적인 경로에는 맞지 않는 traffic을 discard해야 한다고 말하고, §5.2는 null/discard next hop을 흔한 구현으로 설명합니다. “반드시 폐기해야 한다”는 안전 규칙과 실제 장비의 null route 설치·광고 철회 조건은 구분합니다. traceroute의 마지막 hop만 보고 summary router 자체가 원인이라고 단정하지 말고 RIB/FIB와 구성요소 광고를 함께 읽습니다. 이때 null 경로의 목적지는 “장애 주소를 살려서 다른 곳으로 보내기”가 아니라, 요약 라우터가 그 주소에 대한 권위를 갖고 있다는 사실을 forwarding에 반영하는 것입니다. 구성요소가 복구되면 /24가 null보다 길어져 자동으로 정상 경로를 이기지만, 복구 순서가 광고보다 늦으면 잠시 blackhole이 유지될 수 있습니다.