업데이트 전송 및 수신 시 RIP 및 IGRP의 동작

소개

이 문서에서는 라우팅 업데이트를 보내거나 받을 때 RIP(Routing Information Protocol) 및 IGRP(Interior Gateway Routing Protocol)에서 수행한 일련의 작업에 대해 설명합니다.

사전 요구 사항

요구 사항

이 문서에 대한 특정 요건이 없습니다.

사용되는 구성 요소

이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전에 적용됩니다.

• Cisco IOS Software 릴리스 12.2(27)

• Cisco 2500 Series 라우터

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다.이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다.현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.

일반 동작

업데이트 보내기

RIP 또는 IGRP가 업데이트를 전송할 때 업데이트를 알리기 전에 특정 검사를 수행합니다.이 목록은 라우터 1에서 라우터 2로 업데이트를 전송하기 전에 발생하는 이벤트의 순서를 보여줍니다. 네트워크 다이어그램을 사용하면 이벤트 순서를 더 자세히 검사할 수 있습니다.

• 서브넷 정보는 업데이트를 제공하는 인터페이스와 동일한 주 네트워크에 속합니까?

  • 아니요:라우터 1은 주요 네트워크 경계에서 요약하고 네트워크를 광고합니다.

  • 예:네트워크에 업데이트를 제공하는 인터페이스와 동일한 서브넷 마스크가 있습니까?

    • 예:라우터 1은 서브넷을 광고합니다.

    • 아니요:네트워크에 /32 마스크가 있습니까?

      • 예:RIP이면 네트워크가 광고됩니다.IGRP인 경우 라우터 1이 네트워크를 삭제합니다.

      • 아니요:라우터 1이 네트워크를 삭제합니다.

업데이트 수신

RIP 또는 IGRP가 업데이트를 수신할 때 업데이트를 수락하고 서브넷 마스크를 적용하기 전에 특정 검사를 수행합니다.라우터 2가 라우터 1의 업데이트를 수락하기 전에 발생하는 이벤트의 시퀀스입니다.

• 업데이트를 수신한 인터페이스와 동일한 주 넷의 업데이트에서 서브넷을 수신합니까?

  • 예:라우터 2는 업데이트를 받은 인터페이스의 마스크를 적용합니다.알려진 네트워크에 업데이트의 호스트 부분에 호스트 비트가 설정되어 있으면 라우터 2는 호스트 마스크(/32)를 적용합니다. RIP의 경우 /32 경로를 후속 라우터에 계속 광고하지만 IGRP는 알리지 않습니다.

  • 아니요:이 주요 네트워크의 서브넷이 라우팅 테이블에 이미 존재합니까? 업데이트를 수신한 서브넷이 아닌 인터페이스에서 알 수 있습니까?이 업데이트의 네트워크는 두 라우터 간의 링크가 번호가 지정되지 않은 링크인 경우가 아니면 주 넷이어야 합니다. 이 경우 업데이트에서 서브넷 정보를 포함할 수 있습니다.

    • 예:라우터 2는 업데이트를 무시합니다.

    • 아니요:라우터 2는 클래스풀 마스크를 적용합니다.업데이트가 번호가 지정되지 않은 링크를 통해 전송되고 서브넷 정보(네트워크의 서브넷 부분에 비트 설정)가 포함된 경우 라우터 2는 호스트 마스크를 적용합니다.번호가 지정되지 않은 사례 예는 ip unnumered 명령 이해 및 구성을 참조하십시오.

특정 사례

업데이트 보내기

라우터 1이 라우터 2에 업데이트를 전송하면 다음 검사를 수행합니다.

• 131.108.5.0/24은 131.108.2.0/24과 동일한 주요 네트워크에 속하며, 이 업데이트 소스가 어디입니까?

  • 예:131.108.5.0/24의 서브넷 마스크는 131.108.2.0/24과 동일하며, 이 중 업데이트를 제공하는 것은 무엇입니까?

    • 예:라우터 1은 네트워크를 광고합니다.

• 137.99.88.0/24은 131.108.2.0/24과 동일한 주요 네트워크에 속하며, 이 업데이트 소스가 어디입니까?

  • 아니요:라우터 1은 주요 네트워크 경계에서 137.99.88.0/24을 요약하고 137.99.0.0으로 알립니다.

이 프로세스에서는 라우터 2에 대한 업데이트에서 131.108.5.0 및 137.99.0.0을 포함하는 라우터 1이 생성됩니다. 라우터 1에 표시된 debug ip rip 명령 출력에서 이를 확인할 수 있습니다.

*Mar 25 00:22:46.177: RIP: sending v1 update to 255.255.255.255 via Serial0 (131.108.2.2)  
*Mar 25 00:22:46.178: RIP: build update entries
*Mar 25 00:22:46.182: subnet 131.108.5.0, metric 1
*Mar 25 00:22:46.185: network 137.99.0.0, metric 1

업데이트 수신

debug ip rip 명령을 실행하면 라우터 1에서 라우터 2에서 수신된 라우팅 업데이트를 확인할 수 있습니다.

*Mar 25 00:22:46.201: RIP: received v1 update from 131.108.2.2 on Serial0 
*Mar 25 00:22:46.203:131.108.5.0 in 1 hops
*Mar 25 00:22:46.205:137.99.0.0 in 1 hops

수신된 네트워크에 적용할 마스크를 확인하기 위해 라우터 2에서 수행하는 검사를 확인합니다.

• 수신된 주 네트워크137.99.0.0 업데이트를 수신한 인터페이스에 할당된 주소인 131.108.2.0과 동일합니까?

  • 아니요:이 주요 네트워크의 서브넷이 다른 인터페이스에서 알려진 라우팅 테이블에 이미 존재합니까?

    • 아니요:137.99.0.0은 클래스 B 주소이므로 라우터 2는 자연 마스크(/16)를 적용합니다.

• 서브넷 131.108.5.0이 서브넷 131.108.2.0과 동일한 주 네트워크에 속합니까? 이는 업데이트를 받은 인터페이스입니다.

  • 예:라우터 2는 업데이트를 받은 인터페이스의 마스크인 /24 마스크를 적용합니다.

이 프로세스를 수행하면 라우터 2의 라우팅 테이블에 다음과 같은 네트워크와 마스크가 나타나며 show ip route 명령과 함께 표시됩니다.

R    137.99.0.0/16 [120/1] via 131.108.2.2, 00:00:07, Serial0 
     131.108.0.0/24 is subnetted, 3 subnets
R    131.108.5.0 [120/1] via 131.108.2.2, 00:00:08, Serial0 
C    131.108.2.0 is directly connected, Serial0
C    131.108.3.0 is directly connected, Ethernet0

관련 정보

• RIPv1 및 IGRP에서 가변 길이 서브넷 마스크를 지원하지 않는 이유는 무엇입니까?
• RIP 또는 IGRP가 불연속 네트워크를 지원하지 않는 이유는 무엇입니까?
• IGRP 기술 지원 페이지
• RIP 기술 지원 페이지
• IP 라우팅 프로토콜 기술 지원 페이지
• 기술 지원 및 문서 − Cisco Systems