RIP

RIP 는 라우터들이 목적지로 가는 길을 서로 알려 주게 하는 규칙입니다. 라우터마다 자기가 아는 목적지와 거기까지의 거리를 정해진 간격으로 이웃 라우터에게 보냅니다. 각 라우터는 이웃이 알려 준 거리를 보고 가장 가까운 길을 골라 표에 적습니다. 한 기관이 관리하는 중간 크기 네트워크 안에서 쓰도록 만들었습니다.

상세

RIP(Routing Information Protocol, 라우팅 정보 프로토콜)는 라우터들이 경로 정보를 주고받는 프로토콜입니다. 라우터는 패킷을 받아 목적지 쪽으로 넘겨주는 장비입니다. 라우터마다 목적지별로 패킷을 어디로 넘길지 적은 표를 들고 있습니다. 이 표가 경로표입니다.

경로표를 사람이 손으로 채우는 방식을 정적 라우팅이라고 합니다. 이 방식에서는 회선이나 라우터가 죽어도 표가 바뀌지 않습니다. 라우터는 끊긴 길로 패킷을 계속 넘깁니다. 그런데 회선과 라우터는 자주 죽었다가 다시 살아납니다.

RIP 는 라우터들이 서로 알려 주는 정보로 경로표를 채우게 합니다. 길이 끊기면 그 길을 표에서 내립니다. 다른 길이 있으면 그 길로 갈아탑니다. 아래에서는 한 줄로 이어진 라우터 몇 대를 가지고 RIP 가 길을 고르는 계산, 경로의 길이를 재는 메트릭, 갈 수 없음을 뜻하는 16, RIP 가 맞는 네트워크의 크기를 차례로 다룹니다.

RIP 에는 판이 셋 있습니다. IPv4(Internet Protocol version 4, 인터넷 프로토콜 4판) 주소를 다루는 RIPv1 과 RIPv2, IPv6(Internet Protocol version 6, 인터넷 프로토콜 6판) 주소를 다루는 RIPng(RIP next generation, 차세대 RIP)입니다. 판마다 다른 점은 「갈래」 절에서 봅니다.

거리 벡터 방식

RIP 는 벨만-포드 알고리즘을 바탕으로 합니다. 이 알고리즘은 거리 벡터 알고리즘이라고도 부릅니다.

계산에는 비용이라는 수를 씁니다. 비용은 라우터가 자기에게 이어진 네트워크마다 매깁니다. 보통 1 로 둡니다.

이웃이 알려 준 거리에 그 이웃과 이어진 네트워크의 비용을 더합니다. 그렇게 목적지마다 가장 작은 값을 찾는 것이 이 알고리즘입니다.

RIP 의 라우터는 네트워크 전체의 모양을 모릅니다. 아는 것은 자기 경로표뿐입니다. 라우터는 경로표에 적힌 목적지와 거리를 이웃에게 알립니다. 이웃이 알려 온 목적지와 거리로 자기 표를 고칩니다. 주고받는 것이 목적지별 거리 목록뿐이라 이 방식의 이름이 거리 벡터 라우팅입니다.

경로표의 한 줄은 목적지 하나를 맡습니다. 다음 홉은 그 목적지로 가는 길에서 패킷을 넘겨줄 바로 다음 라우터입니다.

서브넷 마스크는 주소의 앞 몇 비트까지가 네트워크 번호인지 알려 주는 값입니다.

IPv4 주소에는 앞자리 값으로 정해지는 기본 마스크가 따로 있습니다. 이 기본 마스크를 자연 마스크라고 부릅니다. 128 부터 191 사이로 시작하는 주소는 자연 마스크로 앞 2바이트까지가 네트워크 번호입니다. 서브넷 마스크는 그 네트워크를 더 잘게 나눌 때 씁니다.

경로표의 한 줄에는 아래 것들이 적힙니다.

라우터 A, B, C 가 한 줄로 이어져 있다고 해 봅시다. 네트워크 N 은 C 에 직접 붙어 있습니다. 네트워크마다 비용이 1 이면 C 는 N 을 메트릭 1 로 적습니다. C 의 알림을 받은 B 는 C 와 이어진 네트워크의 비용 1 을 더해 메트릭 2 로 적습니다. 다음 홉은 C 입니다.

flowchart TD
    N["네트워크 N"]
    C["라우터 C · 메트릭 1 · 직접 붙음"]
    B["라우터 B · 메트릭 2 · 다음 홉 C"]
    A["라우터 A · 메트릭 3 · 다음 홉 B"]
    N --- C
    C -->|"N 까지 메트릭 1 을 알린다"| B
    B -->|"N 까지 메트릭 2 를 알린다"| A

메트릭은 이웃을 하나 건널 때마다 1 씩 늘어납니다. A 는 B 너머의 길이 어떻게 생겼는지 모릅니다. B 가 알려 준 2 에 1 을 더해 3 으로 적을 뿐입니다.

라우터가 이웃들이 알려 온 값을 꼭 다 모아 두는 것은 아닙니다. 구현은 대개 지금까지 본 가장 작은 메트릭과 그 값을 보낸 이웃만 기억합니다. 표를 고치는 규칙은 둘입니다.

1. 이웃이 알려 온 메트릭에 그 이웃과 이어진 네트워크의 비용을 더합니다. 그 값이 지금 적힌 메트릭보다 작으면 그 이웃을 새 다음 홉으로 삼습니다
2. 지금 다음 홉인 이웃이 알려 온 값은 커져도 받아 적습니다

규칙 1 만 있으면 메트릭은 줄기만 합니다. 다음 홉 쪽 길이 멀어져도 표에 옛 값이 남습니다. 규칙 2 가 길이 멀어졌다는 소식을 받아들이게 합니다. 두 규칙으로 한 번에 하나씩 고쳐 가도, 이웃들의 최신 값을 전부 모아 가장 작은 것을 고른 것과 같은 경로가 나옵니다.

다만 이 두 규칙은 네트워크 구성이 바뀌지 않는다고 칩니다. 라우터나 회선이 죽는 경우는 아직 다루지 않습니다. 그 경우는 「교환 순서」의 타이머와 「실패」 절이 받습니다.

메트릭과 홉 수

메트릭은 경로의 길이를 재는 수입니다. 비용은 1 부터 15 사이의 정수입니다. 경로의 메트릭은 목적지까지 지나는 네트워크들의 비용을 더한 값입니다.

홉은 패킷이 라우터 하나를 건너 다음 네트워크로 넘어가는 한 번입니다. 비용은 보통 1 로 둡니다. 경로 길이의 상한이 15 라서입니다. 모든 네트워크가 비용 1 이면 메트릭은 목적지까지의 홉 수와 같아집니다.

구현은 관리자가 네트워크마다 비용을 정할 수 있게 하기를 권합니다(SHOULD). 대역폭이나 신뢰도가 다른 네트워크 가운데 한쪽을 더 쓰게 하려 할 때 1 보다 큰 비용을 쓸 수 있습니다. 비용을 크게 주면 상한 15 가 쉽게 걸림돌이 될 수 있습니다.

직접 붙은 네트워크의 메트릭은 그 네트워크의 비용입니다. 라우터 자신까지의 거리 0 은 표에 적지 않습니다. 같은 네트워크에 붙은 장비들은 그 네트워크 줄 하나로 묶어 적습니다.

16 은 갈 수 없음

쓸 수 있는 메트릭은 1 부터 15 까지입니다. 메트릭 16 은 그 목적지에 갈 수 없다는 뜻입니다. 이 값을 무한대라고 부릅니다. 길이 사라진 것을 이웃에게 알릴 때도 평소의 갱신 메시지에 메트릭 16 을 적어 보냅니다.

16 은 일부러 작게 잡은 수입니다. 길이 사라진 뒤에도 라우터들이 서로를 믿어 메트릭을 1 씩 올려 가는 일이 있습니다. 이 현상이 무한 카운트입니다. 「실패」 절에서 자세히 봅니다.

서로를 거쳐 가면 된다고 믿는 이 상태가 라우팅 루프입니다. 라우팅 루프에서는 패킷이 라우터들 사이를 돕니다. 목적지에는 닿지 못합니다. 루프는 메트릭이 무한대에 닿아 그 네트워크가 갈 수 없다고 정해질 때 풀립니다. 그래서 무한대를 작게 잡을수록 오름이 일찍 멈춥니다.

대신 무한대는 실제 경로의 메트릭보다 커야 합니다. 수렴은 길이 바뀐 뒤 모든 라우터의 경로표가 새 상태에 맞춰지는 것입니다. 무한대를 크게 잡으면 큰 네트워크를 담습니다. 작게 잡으면 무한 카운트가 났을 때 수렴이 일찍 끝납니다.

지름은 네트워크에서 가장 긴 경로의 홉 수입니다. RIP 를 설계한 사람들은 지름이 15 를 넘는 네트워크에서는 이 프로토콜을 쓰기 어려울 것으로 보았습니다.

RIP 가 맞는 네트워크

인터넷처럼 큰 네트워크를 한 라우팅 프로토콜로 다 덮을 가능성은 아주 낮습니다. 대신 대개 한 주체가 관리하는 네트워크 묶음들로 나뉩니다. 이 묶음이 AS(Autonomous System, 자율 시스템)입니다. AS 마다 쓰는 라우팅 방식이 다를 수 있습니다.

AS 안에서 쓰는 라우팅 프로토콜이 IGP(Interior Gateway Protocol, 내부 게이트웨이 프로토콜)입니다. 게이트웨이는 라우터를 가리키던 옛 이름입니다. AS 사이에서 경로 정보를 옮기는 프로토콜은 따로 있습니다. 이쪽은 EGP(Exterior Gateway Protocol, 외부 게이트웨이 프로토콜)입니다.

flowchart TD
    subgraph AS1["AS 하나 · 한 주체가 관리한다"]
        R1["라우터"] ---|"IGP · 예를 들어 RIP"| R2["라우터"]
    end
    subgraph AS2["다른 AS · 다른 주체가 관리한다"]
        R3["라우터"] ---|"IGP · 이 AS 가 고른 것"| R4["라우터"]
    end
    R2 ---|"EGP · AS 사이에서 경로 정보를 옮긴다"| R3

AS 안의 라우터끼리는 IGP 를 씁니다. AS 와 AS 를 잇는 구간은 EGP 가 맡습니다. RIP 는 그중 IGP 쪽입니다.

RIP 는 중간 크기 AS 안의 IGP 로 쓰도록 만들었습니다. 더 복잡한 환경은 겨냥하지 않았습니다. 첫 판은 쓰는 기술이 서로 크게 다르지 않은 중간 크기 네트워크를 겨냥했습니다. 그래서 여러 캠퍼스의 IGP 로, 또 회선 속도가 크게 다르지 않은 직렬 회선을 쓰는 지역 네트워크의 IGP 로 알맞다고 보았습니다.

RIP 에는 아래 세 한계가 있습니다.

둘째 한계에 대해 설계한 사람들은 현실의 네트워크에서는 속도가 낮은 회선이 아니면 문제가 되지 않으리라고 보았습니다. 그런 회선에서도 여러 대비책이 대부분의 경우를 막을 것이라 드문 일로 여겼습니다.

교환 순서

이 절은 RIP 라우터 둘이 무엇을 어떤 차례로 주고받는지 봅니다. 막 켜진 라우터 하나와 그 이웃이 대상입니다. 표를 채우는 첫 왕복, 그 뒤의 정기 갱신, Response 를 받아 처리하는 순서, 트리거 업데이트, 경로표 한 줄이 지워지기까지를 차례로 따라갑니다.

메시지는 UDP(User Datagram Protocol, 사용자 데이터그램 프로토콜)로 오갑니다. UDP 는 보낸 것이 도착했는지 확인하지 않는 전송 방식입니다. 라우터마다 RIP 프로세스가 UDP 520번 포트로 메시지를 주고받습니다. 묻지 않고 보내는 갱신은 보내는 포트와 받는 포트가 둘 다 520 입니다.

메시지는 두 종류입니다. Request 는 상대 경로표의 전부나 일부를 달라는 메시지입니다. Response 는 보낸 쪽 경로표의 전부나 일부를 싣는 메시지입니다. Response 는 Request 의 답으로 갑니다. 묻지 않아도 갑니다.

RTE(Route Entry, 경로 항목)는 목적지 하나와 그 메트릭을 담는 칸 묶음입니다. Response 한 통에는 RTE 가 25개까지 실립니다. 보낼 경로가 더 많으면 Response 를 여러 통으로 나눠 보냅니다. 통 수에는 상한이 없습니다.

표를 채우는 첫 왕복

브로드캐스트는 같은 네트워크의 모든 장비에게 한 번에 보내는 방식입니다. 멀티캐스트는 정해진 무리에게만 보내는 방식입니다. 스플릿 호라이즌은 어떤 이웃에게서 배운 경로를 그 이웃에게는 도로 알리지 않는 규칙입니다.

1. 막 켜진 라우터는 연결된 네트워크마다 Request 를 보냅니다. 보통 RIPv1 은 브로드캐스트로, RIPv2 는 멀티캐스트로 보냅니다
2. 이 Request 에는 RTE 가 하나뿐입니다. 그 RTE 는 주소군 0 과 메트릭 16 을 담습니다. 주소군은 RTE 의 주소가 어떤 종류인지 적는 칸입니다. 이 꼴이 경로표 전체를 달라는 뜻입니다
3. 받은 라우터는 경로표 전체를 Response 에 실어 요청한 주소와 포트로 보냅니다. 이때 스플릿 호라이즌을 거칩니다

요청한 쪽은 받은 표로 자기 경로표를 고칩니다. 그래서 이 답은 스플릿 호라이즌을 거쳐야 합니다.

sequenceDiagram
    participant 새 as 막 켜진 라우터
    participant 이웃 as 이웃 라우터
    새->>이웃: Request · RTE 하나 · 주소군 0 · 메트릭 16
    이웃-->>새: Response · 경로표 전체 · 스플릿 호라이즌 적용
    Note over 새,이웃: 이후 30초 안팎마다 묻지 않고 보낸다
    이웃->>새: Response · 정기 갱신
    새->>이웃: Response · 정기 갱신
    Note over 새: 메트릭이 바뀐 경로가 생긴다
    새->>이웃: Response · 트리거 업데이트 · 바뀐 경로를 싣는다

첫 두 화살표가 표를 채우는 왕복입니다. 그 아래는 묻지 않고 보내는 Response 들입니다. 정기 갱신과 트리거 업데이트는 아래 소절에서 봅니다.

경로표 일부만 묻는 Request 도 있습니다. 받은 라우터는 RTE 마다 자기 표에서 목적지를 찾아 메트릭을 채웁니다. 경로가 없으면 16 을 채웁니다. 다 채우면 명령을 Request 에서 Response 로 바꿔 요청한 쪽에 돌려보냅니다.

이 답에는 스플릿 호라이즌을 거치지 않습니다. 이런 요청은 라우터 상태를 살피는 진단 도구가 보내는 것으로 봅니다. 라우팅에는 쓰지 않으므로 경로표를 손대지 않은 채로 보여 줍니다. 진단 도구는 520 이 아닌 포트에서 보낼 수 있습니다.

정기 갱신

30초마다 RIP 프로세스가 깨어나 경로표 전체를 담은 Response 를 모든 이웃에게 보냅니다. 묻지 않고 보내는 이 Response 가 정기 갱신입니다.

한 네트워크에 라우터가 많으면 갱신 시각이 서로 맞춰지는 일이 생깁니다. 시스템 부하가 30초 타이머를 흔들 때 그렇습니다. 그러면 브로드캐스트 네트워크에서 쓸데없는 충돌이 날 수 있습니다. 그래서 구현은 둘 중 하나를 해야 합니다.

• 부하나 직전 갱신의 처리 시간에 흔들리지 않는 시계로 30초를 잽니다
• 타이머를 걸 때마다 0~5초 사이의 무작위 시간을 더하거나 뺍니다

점대점 링크는 두 장비만 잇는 회선입니다. 갱신은 점대점 링크면 건너편 라우터에게 바로 갑니다. 브로드캐스트를 지원하는 네트워크면 브로드캐스트로 갑니다. RIPv2 는 멀티캐스트 주소 224.0.0.9 를 씁니다.

Response 를 받았을 때

Response 가 오는 까닭은 셋입니다. 특정 질의의 답, 정기 갱신, 경로 변경이 부른 트리거 업데이트입니다. 처리 순서는 셋이 같습니다.

먼저 메시지 전체를 걸러 냅니다. 걸러 내는 조건은 「실패」 절에 표로 모았습니다. 통과하면 RTE 를 하나씩 봅니다.

RTE 의 메트릭에 메시지가 들어온 네트워크의 비용을 더합니다. 16 을 넘으면 16 으로 둡니다. 식으로 쓰면 메트릭 = MIN(메트릭 + 비용, 16) 입니다.

flowchart TD
    S["RTE 하나 · 새 메트릭을 셈한다"] --> Q1{"이 목적지 경로가 표에 있나"}
    Q1 -->|"없다"| Q2{"새 메트릭이 16 인가"}
    Q2 -->|"아니다"| ADD["경로를 더한다 · 다음 홉은 보낸 라우터"]
    Q2 -->|"16 이다"| IGN["더하지 않는다"]
    Q1 -->|"있다"| Q3{"보낸 라우터가 지금 다음 홉이고 메트릭이 바뀌었나 · 또는 새 메트릭이 더 작은가"}
    Q3 -->|"그렇다"| ADOPT["새 메트릭과 다음 홉을 적는다"]
    Q3 -->|"아니다"| KEEP["표를 바꾸지 않는다"]

표에 없는 목적지는 메트릭이 16 이 아닐 때만 더합니다. 쓸 수 없는 경로를 더할 까닭이 없기 때문입니다.

만료 타이머는 그 경로의 갱신이 한동안 오지 않으면 경로를 거두게 하는 타이머입니다. 지우는 과정은 경로의 메트릭을 16 으로 돌려놓고 얼마 뒤 경로표에서 그 줄을 지우는 절차입니다. 둘의 시간은 아래 「경로가 지워지기까지」 소절에 있습니다.

경로를 더하거나 고치면 만료 타이머를 다시 겁니다. 경로 변경 플래그를 세웁니다. 트리거 업데이트도 부릅니다. 고친 메트릭이 16 이면 지우는 과정을 시작합니다.

보낸 라우터가 지금 다음 홉이면 메트릭이 같아도 만료 타이머를 다시 겁니다. 다른 라우터가 같은 메트릭의 경로를 알려 오면 보통은 갈아타지 않습니다. 갈아타면 경로가 두 라우터 사이를 오갑니다. 그러면 트리거 업데이트가 감당 못 할 만큼 납니다.

다만 지금 경로의 만료 타이머가 절반 이상 흘렀으면 새 경로로 갈아탑니다. 이 방법은 선택 사항이지만 강하게 권장됩니다.

트리거 업데이트

경로의 메트릭이 바뀌면 라우터는 다음 정기 갱신을 기다리지 않습니다. 거의 바로 갱신을 보냅니다. 이것이 트리거 업데이트입니다. 트리거 업데이트에는 경로 변경 플래그가 선 경로만 넣으면 됩니다. 경로표 전체를 보내는 것은 강하게 말립니다.

트리거 업데이트는 용량이 작은 네트워크나 라우터가 많은 네트워크에 부하를 지나치게 줄 수 있습니다. 그래서 하나를 보낸 뒤 1~5초 사이 무작위 길이의 타이머를 겁니다. 그동안 생긴 변경은 타이머가 끝날 때 한 번에 몰아 보냅니다. 그 시각까지 정기 갱신이 잡혀 있으면 트리거 업데이트는 보내지 않습니다.

트리거 업데이트에도 스플릿 호라이즌을 거칩니다. 트리거 업데이트를 다 만들고 나면 경로 변경 플래그를 내립니다.

경로가 지워지기까지

경로표의 줄마다 타이머가 둘 붙습니다. 만료 타이머가 끝나면 경로는 더 이상 유효하지 않습니다. 가비지 컬렉션 타이머가 끝나면 그 줄을 경로표에서 지웁니다.

만료 타이머는 경로를 처음 세울 때 겁니다. 그 경로의 갱신을 받을 때마다 다시 겁니다. 마지막으로 건 뒤 180초가 지나면 경로가 만료됩니다.

지우는 과정은 두 경우에 시작합니다. 만료 타이머가 끝날 때와 지금 다음 홉이 메트릭 16 을 알려 올 때입니다. 이 과정에 든 경로를 삭제 대기 경로라고 부르겠습니다. 두 경우 모두 이렇게 됩니다.

• 가비지 컬렉션 타이머를 120초로 겁니다
• 메트릭을 16 으로 바꿉니다. 이 경로로는 더 이상 패킷을 넘기지 않습니다
• 경로 변경 플래그를 세웁니다
• 트리거 업데이트를 부릅니다

stateDiagram-v2
    state "삭제 대기 · 메트릭 16" as 삭제대기
    [*] --> 유효: Response 로 경로를 배운다
    유효 --> 유효: 갱신을 받아 만료 타이머를 다시 건다
    유효 --> 삭제대기: 180초 동안 갱신 없음 · 또는 다음 홉이 16 을 알린다
    삭제대기 --> 유효: 새 경로가 온다
    삭제대기 --> [*]: 120초 뒤 경로표에서 지운다

삭제 대기 동안 이 경로는 메트릭 16 으로 모든 갱신에 실립니다. 이웃에게 경로가 사라졌다는 것을 알리려는 것입니다. 그 사이 새 경로가 오면 새 경로가 이 줄을 대신합니다. 이때 가비지 컬렉션 타이머는 멈춥니다.

예시

실물 둘을 봅니다. 첫째는 막 켜진 라우터가 보내는 경로표 전체 요청과 그 답의 바이트 배치입니다. 둘째는 라우팅 소프트웨어 FRRouting 의 RIP 데몬인 ripd 에서 RIP 를 켜는 설정입니다. 데몬은 화면 없이 뒤에서 늘 도는 프로그램입니다.

경로표 전체를 달라는 Request

RIP 메시지는 4바이트 머리말과 RTE 목록으로 이루어집니다. RTE 하나는 20바이트입니다. 한 메시지에 RTE 가 1개부터 25개까지 실립니다.

아래 그림은 RIPv2 형식 메시지에 RTE 가 하나 실린 배치입니다. 한 줄이 4바이트입니다. 위쪽이 메시지 앞쪽입니다.

block-beta
columns 4
  cmd["command · 1바이트"] ver["version · 1바이트"] mbz["must be zero · 2바이트"]:2
  afi["Address Family Identifier · 2바이트"]:2 tag["Route Tag · 2바이트"]:2
  ip["IP Address · 4바이트"]:4
  mask["Subnet Mask · 4바이트"]:4
  nh["Next Hop · 4바이트"]:4
  met["Metric · 4바이트"]:4

첫 줄이 머리말입니다. 나머지 다섯 줄이 RTE 하나입니다. 따로 정하지 않은 칸은 큰 쪽 바이트를 앞에 두는 이진 정수입니다. Address Family Identifier 가 앞에서 말한 주소군 칸입니다.

경로표 전체를 달라는 Request 는 칸이 이렇게 찹니다.

RTE 가 하나뿐이고 주소군이 0, 메트릭이 16 이라는 세 조건이 경로표 전체 요청의 표지입니다. 받는 쪽은 이 셋을 보고 경로표 전체를 보냅니다.

그 Request 에 돌아오는 Response

답은 command 가 2 인 Response 입니다. RTE 마다 칸은 이렇게 찹니다. 주소 예는 서브넷 마스크가 255.255.255.0 인 네트워크 128.6.0.0 의 서브넷 128.6.4.0 입니다.

메트릭이 16 인 경로도 RTE 로 실어 보냅니다.

FRRouting ripd 의 설정

FRRouting 의 ripd 에서 RIP 를 켜는 가장 짧은 설정입니다. 인터페이스 eth0 과 주소가 10.0.0.0/8 에 드는 인터페이스에서 RIP 가 돕니다.

!
router rip
 network 10.0.0.0/8
 network eth0
!

router rip 이 RIP 를 켭니다. 다른 RIP 명령보다 먼저 와야 합니다. network 뒤에 주소 묶음을 주면 주소가 그 묶음에 드는 인터페이스에서 RIP 를 켭니다. 예를 들어 10.0.0.0/24 를 주면 10.0.0.0 부터 10.0.0.255 까지의 주소가 켜집니다. network 뒤에 인터페이스 이름을 줄 수도 있습니다.

판과 타이머는 아래 명령으로 바꿉니다.

타이머 기본값 셋은 「교환 순서」 절의 30초 · 180초 · 120초와 같습니다. version 2 로 RIPv1 을 끄기를 강하게 권합니다. RIPv1 은 인증을 할 수 없습니다. RIPv1 을 켜 두면 묻는 원격 라우터 누구에게나 Request 의 답으로 경로표를 보냅니다.

실패

RIP 가 깨지는 조건과 그때 경로표에 일어나는 일을 봅니다. 대상은 라우터들의 경로표와 그 사이를 오가는 Response 입니다. 소식이 끊길 때, 루프가 생길 때, 루프를 줄이는 장치, 장치로도 남는 루프, 받은 메시지를 버리는 조건, 인증 순으로 봅니다.

다음 홉의 소식이 끊길 때

라우터가 죽으면 이웃에게 메트릭이 바뀌었다고 알릴 방법이 없습니다. 이웃은 지금까지 본 가장 작은 메트릭만 기억합니다. 그래서 그 변화를 끝내 모를 수 있습니다. 거리 벡터 프로토콜에 시간이 지나면 경로를 버리는 장치가 있어야 하는 까닭입니다.

30초마다 갱신이 오는데도 180초를 기다리는 까닭은 네트워크가 메시지를 가끔 잃기 때문입니다. 한 통을 놓쳤다고 경로를 삭제 대기로 돌리는 것은 바람직하지 않을 가능성이 큽니다.

무한 카운트

아래 예는 스플릿 호라이즌 같은 장치가 없을 때 일어나는 일입니다. 제대로 구현한 RIP 에서는 이렇게 되지 않습니다. 장치가 왜 필요한지 보이려는 예입니다.

flowchart TD
    A["라우터 A"] --- B["라우터 B"]
    A --- C["라우터 C"]
    B --- C
    B --- D["라우터 D"]
    C ---|"비용 10"| D
    D --- T["목표 네트워크"]

모든 네트워크의 비용은 1 입니다. C 와 D 를 잇는 링크만 비용이 10 입니다. 처음에는 D 가 목표 네트워크에 직접 붙어 메트릭 1 입니다. B 는 D 를 거쳐 2, A 와 C 는 B 를 거쳐 3 입니다.

이제 B 와 D 사이 링크가 끊깁니다. 경로는 C–D 링크로 옮겨 가야 합니다. 아래 표는 갱신 차례마다 목표 네트워크의 경로를 적은 것입니다. 모든 라우터가 같은 때 갱신을 보낸다고 칩니다.

B 는 만료로 끊긴 경로를 버립니다. 그러나 A 와 C 는 아직 B 를 거쳐 D 에 간다고 믿어 메트릭 3 을 알립니다. 다음 차례에 B 는 A 나 C 를 거쳐 갈 수 있다고 여깁니다. A 와 C 는 B 쪽 경로가 사라진 걸 안 뒤에도 서로를 거쳐 간다고 믿습니다. 그래서 메트릭이 1 씩 오릅니다.

이 오름은 C 의 메트릭이 11 에 닿을 때 끝납니다. A 를 거치면 다음 차례에 12 가 됩니다. 비용 10 인 C–D 링크로 곧장 가면 11 입니다. 더 작은 쪽인 D 직행으로 C 가 갈아탑니다.

목적지가 어느 쪽에서도 아예 갈 수 없게 되면 메트릭은 무한대 16 에 닿을 때까지 이렇게 천천히 오를 수 있습니다. 이 문제를 무한 카운트라 부릅니다. 결국은 수렴합니다. 다만 그때까지 얼마간 시간이 걸릴 수 있습니다.

루프를 줄이는 장치

앞 예의 문제 일부는 A 와 C 가 서로를 거쳐 D 에 간다고 주장하는 데서 옵니다. 어떤 이웃에게서 배운 경로를 그 이웃에게 도로 알려서 생기는 일입니다. RIP 는 이를 줄이는 장치로 포이즌 리버스를 곁들인 스플릿 호라이즌과 트리거 업데이트를 씁니다.

두 라우터가 서로를 가리키는 경로를 들고 있으면 포이즌 리버스는 루프를 바로 끊습니다. 역방향 경로를 메트릭 16 으로 알리기 때문입니다. 단순 스플릿 호라이즌은 그 경로를 알리지 않을 뿐이라 틀린 경로가 만료될 때까지 기다려야 합니다.

포이즌 리버스의 대가는 메시지 크기입니다. 백본은 여러 네트워크를 한데 모아 잇는 중심 회선입니다. 여러 건물을 잇는 캠퍼스 백본을 생각해 봅시다. 건물마다 라우터가 백본과 건물 안 네트워크를 잇습니다.

단순 스플릿 호라이즌이면 각 라우터는 백본에 자기 건물 네트워크만 알립니다. 포이즌 리버스면 백본에서 배운 경로 전부를 메트릭 16 으로 함께 알려야 합니다. 네트워크가 크면 거의 전부가 갈 수 없음인 큰 메시지가 될 수 있습니다.

그래서 구현은 단순 스플릿 호라이즌을 고를 수 있습니다. 관리자가 고르게 하는 설정을 둘 수도 있습니다. 둘을 섞는 방식도 허용됩니다.

섞는 방식은 이렇습니다. 경로가 바뀐 뒤 한동안만 역방향 경로를 메트릭 16 으로 알립니다. 그 뒤로는 갱신에서 뺍니다.

모든 RIP 구현은 스플릿 호라이즌을 써야 합니다(MUST). 포이즌 리버스도 쓰기를 권합니다(SHOULD). 포이즌 리버스를 끄는 설정은 둘 수 있습니다.

트리거 업데이트는 연쇄로 퍼집니다. 라우터 G 가 목적지 N 의 경로를 만료시키면 모든 이웃에게 트리거 업데이트를 보냅니다. N 경로가 G 를 거치는 이웃만 이 소식을 믿습니다. 나머지는 지금 쓰는 경로보다 메트릭이 큰 새 경로로 보고 무시합니다.

flowchart TD
    G["G · N 경로 만료 · 메트릭 16"] -->|"트리거 업데이트"| X["N 경로가 G 를 거치는 이웃"]
    G -->|"트리거 업데이트"| Y["N 경로가 다른 길인 이웃"]
    X -->|"16 으로 고치고 다시 트리거 업데이트"| X2["N 경로가 그 이웃을 거치는 라우터"]
    Y -->|"메트릭이 더 커서 무시"| STOP["전파가 멈춘다"]

트리거 업데이트는 G 로 이어지는 모든 경로를 거꾸로 거슬러 메트릭을 무한대로 바꿉니다. N 으로 가는 경로가 다른 길인 구간에 닿으면 멈춥니다. 삭제된 경로의 트리거 업데이트는 반드시 구현해야 합니다(MUST). 새 경로나 바뀐 경로의 트리거 업데이트는 구현해도 됩니다(MAY). 보내는 빈도는 제한해야 합니다.

장치로도 남는 루프

포이즌 리버스는 라우터 둘만 얽힌 루프를 막습니다. 셋이 서로를 속이는 꼴은 여전히 생길 수 있습니다. A 는 B 를, B 는 C 를, C 는 A 를 거쳐 간다고 믿는 경우입니다.

flowchart TD
    A["A · 다음 홉 B"] --> B["B · 다음 홉 C"]
    B --> C["C · 다음 홉 A"]
    C --> A

스플릿 호라이즌은 이런 루프를 막지 못합니다. 메트릭이 무한대에 닿아 그 네트워크가 갈 수 없다고 정해질 때에야 풀립니다. 트리거 업데이트는 이 수렴을 앞당기려는 장치입니다.

트리거 업데이트가 퍼지는 동안에도 정기 갱신은 오갑니다. 아직 소식을 못 받은 라우터는 사라진 경로를 담은 정기 갱신을 보냅니다. 트리거 업데이트가 지나간 라우터가 그 갱신을 받으면 틀린 경로의 잔재가 되살아날 수 있습니다. 트리거 업데이트가 충분히 일찍 퍼지면 이런 일은 아주 드뭅니다. 그래도 무한 카운트는 여전히 일어날 수 있습니다.

받은 Response 를 버리는 조건

Response 를 처리하면 경로표가 바뀔 수 있습니다. 그래서 받은 Response 를 먼저 꼼꼼히 걸러 냅니다. 유니캐스트는 한 장비에게만 보내는 주소입니다.

RTE 의 형식 오류는 대개 이웃이 잘못 동작한다는 신호입니다. 그 RTE 는 버리되 기록을 남겨 관리자가 보게 하기를 권합니다.

인증이 없는 기본 RIP

기본 RIP 는 안전한 프로토콜이 아닙니다. RIPv1 은 인증을 고려하지 않았습니다. 인증을 갖춘 구현이 RIPv1 보다 나중에 나왔기 때문입니다. RIPv2 는 넓혀 쓸 수 있는 인증 방식을 더했습니다. 그 방식은 「갈래」 절의 RIPv2 에서 봅니다.

갈래

RIP 의 판은 셋입니다. 판을 가르는 축은 메시지에 무엇을 싣고 누구에게 보내느냐입니다.

RIPv1

RIPv1 은 1988년에 나온 첫 판입니다. 버클리 유닉스 배포판에 들어 있던 routed 프로그램을 바탕으로 했습니다. 게이트웨이와 호스트가 경로 정보를 주고받는 사실상의 표준이 되었습니다.

갱신은 브로드캐스트로 보냅니다. 인증은 없습니다. RIPv1 의 RTE 에는 서브넷 마스크 칸이 없습니다. 그래서 받는 쪽이 주소를 읽는 뜻은 그 네트워크의 서브넷 마스크를 아는지에 따라 갈립니다.

마스크를 알면 뜻이 하나로 정해집니다. 서브넷 마스크가 255.255.255.0 인 네트워크 128.6 에서 128.6.0.0 은 네트워크 번호입니다. 128.6.4.0 은 서브넷 번호입니다. 128.6.4.1 은 호스트 주소입니다.

마스크를 모를 때가 문제입니다. 자연 마스크로 자른 네트워크 번호 밖의 비트가 모두 0 이면 네트워크 경로로 읽습니다. 밖의 비트가 하나라도 1 이면 서브넷 번호인지 호스트 주소인지 가릴 길이 없습니다. 서브넷 번호는 마스크 없이는 쓸 데가 없으므로 이 경우에는 호스트 주소로 봅니다.

flowchart TD
    S["RIPv1 RTE 의 주소를 읽는다"] --> Q1{"그 네트워크의 서브넷 마스크를 아나"}
    Q1 -->|"안다"| K["마스크로 자른다 · 128.6.4.0 은 서브넷 번호"]
    Q1 -->|"모른다"| Q2{"자연 마스크 밖의 비트가 모두 0 인가"}
    Q2 -->|"모두 0"| NET["네트워크 경로로 읽는다"]
    Q2 -->|"하나라도 1"| NODE["호스트 주소로 본다 · 128.6.4.0 이 여기 걸린다"]

호스트는 보통 직접 붙은 네트워크의 마스크만 압니다. 그래서 적절한 서브넷 마스크를 알 것이라 볼 수 없는 상대에게는 서브넷 경로를 보내지 않습니다. 따로 대비하지 않았다면 서브넷 경로를 그 서브넷이 속한 네트워크 밖으로 내보내지 않습니다. 일부 라우터는 그 경로를 배운 인터페이스의 서브넷 마스크를 그대로 가져다 쓰기도 합니다.

RIPv2

RIPv2 의 지금 판은 1998년에 나왔습니다. 머리말은 RIPv1 과 같습니다. RTE 도 20바이트로 같습니다. RIPv1 이 0 으로 비워 두던 칸에 새 정보 셋을 싣습니다. 인증을 쓰거나 새 칸에 정보를 싣는 메시지는 version 에 2 를 적습니다.

갱신은 멀티캐스트 주소 224.0.0.9 로 보냅니다. RIPv2 를 듣지 않는 호스트의 쓸데없는 부담을 덜려는 것입니다.

인증을 쓸 때는 첫 RTE 를 인증 칸으로 씁니다. 그 RTE 의 주소군은 0xFFFF 입니다. 나머지 RTE 는 24개까지 실립니다.

이 판이 정한 인증 방식은 단순 비밀번호 하나뿐입니다. 비밀번호는 16바이트 평문으로 실립니다. 보안을 더 높이는 방식은 다른 문서가 따로 정합니다.

RIPv1 라우터와 섞어 쓰도록 인터페이스마다 호환 스위치를 둡니다. 보내기 설정은 넷입니다.

기본값은 RIP-1 이나 RIP-2 로 두기를 권합니다. RIP-1 호환은 피하기를 권합니다.

RIPng

RIPng 는 IPv6 네트워크용 판으로 1997년에 나왔습니다. RIPv1 과 RIPv2 를 IPv6 에서 돌리는 데 필요한 만큼만 고쳤습니다. 거리 벡터 방식과 메트릭 1~15 는 같습니다. 라우터에만 구현하기를 권합니다.

UDP 521번 포트를 씁니다. 갱신은 모든 RIP 라우터가 듣는 멀티캐스트 그룹 FF02::9 로 보냅니다. RTE 는 서브넷 마스크 대신 프리픽스 길이를 싣습니다. 프리픽스 길이는 주소의 앞 몇 비트가 네트워크 번호인지를 수로 적은 값입니다.

다음 홉은 RTE 마다 칸을 두지 않습니다. RTE 마다 칸을 두면 RTE 크기가 거의 두 배가 되기 때문입니다. 그래서 메트릭 칸이 0xFF 인 다음 홉 RTE 를 따로 둡니다.

그 다음 홉은 뒤따르는 RTE 들에 두루 적용됩니다. 다른 다음 홉 RTE 가 나오거나 메시지가 끝날 때까지입니다. 다음 홉 주소는 링크 로컬 주소여야 합니다. 링크 로컬 주소는 같은 링크 안에서만 쓰는 IPv6 주소입니다.

인증 칸은 없습니다. 무결성과 인증은 IPv6 의 IP 인증 헤더와 캡슐화 보안 페이로드에 맡깁니다.

관련 항목

RIP 가 속하는 라우팅 방식의 분류

거리 벡터 라우팅 · 동적 라우팅 · 정적 라우팅 · 라우팅 프로토콜 · IGP · EGP

RIP 가 쓰이는 관리 단위

자율 시스템 · 인터넷 · 캠퍼스 네트워크 · 백본

RIP 와 역할을 나누거나 겨루는 라우팅 프로토콜

OSPF · IS-IS · EIGRP · IGRP · BGP · 링크 상태 라우팅 · 경로 벡터 라우팅

RIP 가 길을 계산하는 바탕

벨만-포드 알고리즘 · 라우팅 메트릭 · 홉 · 최단 경로 · 다익스트라 알고리즘

RIP 가 채우는 라우터 안의 표

경로표 · 다음 홉 · 기본 경로 · 최장 프리픽스 매치 · 라우터

RIP 에서 나는 장애

무한 카운트 · 라우팅 루프 · 수렴 · 블랙홀 경로 · 경로 플래핑

거리 벡터 라우팅이 루프를 줄이는 장치

스플릿 호라이즌 · 포이즌 리버스 · 트리거 업데이트 · 홀드다운 · 타이머

RIP 메시지를 나르는 전송 수단

UDP · 포트 · 멀티캐스트 · 브로드캐스트 · 유니캐스트 · 점대점 링크 · IP 주소

RIP 판마다 달라지는 주소 표기

서브넷 마스크 · 클래스풀 주소 체계 · CIDR · 프리픽스 · 서브넷 · IPv4 · IPv6 · 링크 로컬 주소

RIPng 가 기대는 IPv6 보안 장치

IPsec · 인증 헤더 · 캡슐화 보안 페이로드 · 인증

RIP 를 구현한 프로그램

routed · FRRouting · ripd · 라우팅 데몬

RIP 의 하위 판과 그 판을 정한 표준 문서

RIPng · RFC 1058 · RFC 2453 · RFC 2080

RIP 가 속하는 상위 분류

라우팅 · 네트워크 · 인터넷 계층 · 프로토콜