RIP 또는 IGRP가 불연속 네트워크를 지원하지 않는 이유는 무엇입니까?

다운로드 옵션

PDF (114.8 KB)
다양한 디바이스에서 Adobe Reader로 보기
ePub (88.4 KB)
iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
Mobi (Kindle) (86.8 KB)
Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기

업데이트:2005년 8월 10일

문서 ID:13724

편견 없는 언어

본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

소개

연속되지 않은 네트워크는 다른 주요 네트워크를 분리하는 주요 네트워크로 구성됩니다.그림 1에서 네트워크172.20.0.0 서브넷이 네트워크 172.16.0.0을 분리합니다. 172.16.0.0은 분리된 네트워크입니다.이 문서에서는 RIPv1 및 IGRP가 불연속 네트워크를 지원하지 않는 이유에 대해 설명하고 이 문제를 해결하는 방법에 대해 설명합니다.

그림 1 - 인접 네트워크

사전 요구 사항

요구 사항

다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

RIPv1 및 IGRP를 구성하는 방법
IP 주소 및 서브넷을 기반으로 하는 개념

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

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

표기 규칙

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

배경 정보

RIP 및 IGRP는 클래스 프로토콜(classful protocol)입니다.RIP가 다른 주요 네트워크 경계를 통해 네트워크를 광고할 때마다 RIP는 주요 네트워크 경계에서 광고된 네트워크를 요약합니다.그림 1에서 라우터 1이 172.16.5.0을 포함하는 업데이트를 172.20.88.0에 걸쳐 라우터 2로 전송하면 라우터는 172.16.5.0/24을 172.16.0.0/16으로 변환합니다. 이 프로세스를 자동 요약이라고 합니다.

라우터 1에서 라우터 2로 업데이트 전송

그림 1의 토폴로지를 사용하여 라우터 1이 라우터 2로 업데이트를 보낼 준비를 할 때 답변해야 할 질문을 식별합니다. 이 의사 결정에 대한 자세한 내용은 업데이트 전송 및 수신 시 RIP 및 IGRP 동작을 참조하십시오.여기서 network 131.108.5.0/24의 광고가 관심을 갖습니다.다음과 같은 질문에 답해야 합니다.

172.16.5.0/24은 172.20.88.0/24과 동일한 주요 네트워크에 속합니까? 172.은 업데이트를 제공하는 인터페이스에 할당된 네트워크입니까?
- 아니요:라우터 1은 172.16.5.0/24을 요약하고 경로 172.16.0.0/16을 광고합니다. 요약은 주요 클래스 경계로 수행됩니다.이 경우 주소는 클래스 B 주소이므로 요약은 16비트입니다.
- 예:이 예제의 경우는 아니지만, 질문에 대한 대답이 "예"인 경우 라우터 1은 네트워크를 요약하지 않으며 서브넷 정보를 그대로 유지하면서 네트워크를 광고합니다.

라우터 1에서 debug ip rip 명령을 사용하여 라우터 1에서 전송하는 업데이트를 확인합니다.

RIP: sending v1 update to 255.255.255.255 via Serial3/0 (172.20.88.2)
RIP: build update entries
  network 172.16.0.0 metric 1

라우터 2가 라우터 1에서 업데이트 수신

라우터 2가 라우터 1에서 수신 및 업데이트를 준비할 때, 응답해야 할 질문을 파악해야 합니다.다시 한 번 강조하지만, 여기서 네트워크 172.16.5.0/24의 접대에 관심이 있다는 점을 기억하십시오.그러나 라우터 1이 업데이트를 전송했을 때 네트워크가 172.16.0.0/16으로 요약되었습니다. 다음 질문에 답해야 합니다.

업데이트를 수신하는 네트워크(172.16.0.0/16)은 업데이트를 받은 인터페이스에 할당된 주소인 172.20.88.0의 동일한 주요 네트워크에 속합니까?
- 아니요:이 주요 네트워크의 서브넷이 업데이트를 받은 인터페이스 이외의 인터페이스에서 알려진 라우팅 테이블에 이미 존재합니까?
- 예:업데이트를 무시합니다.

다시, 라우터 2에서 debug ip rip 명령을 사용하여 라우터 1에서 제공된 업데이트를 확인합니다.

RIP: received v1 update from 172.20.88.2 on Serial2/0
     172.16.0.0 in 1 hops

그러나 라우터 2의 라우팅 테이블은 업데이트가 무시되었음을 나타냅니다.172.16.0.0의 하위 네트워크 또는 네트워크에 대한 유일한 항목은 Ethernet0에 직접 연결된 항목입니다. 라우터 2의 show ip route 명령 출력에는 다음이 표시됩니다.

172.20.0.0/24 is subnetted, 1 subnets
C       172.20.88.0 is directly connected, Serial2/0
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.2.0 is directly connected, Ethernet0/0

RIPv1 및 IGRP의 동작은 라우터 1과 라우터 2가 업데이트될 때 라우터 1과 라우터 2가 모두 172.16.5.0/24 및 172.16.2.0/24의 연결된 하위 네트워크에 대해 학습하지 않는 것입니다. 따라서 이러한 두 하위 네트워크의 디바이스는 서로 통신할 수 없습니다.

솔루션

경우에 따라 인접하지 않은 네트워크는 불가피합니다.이러한 경우에는 RIPv1 또는 IGRP를 사용하지 않는 것이 좋습니다.EIGRP 또는 OSPF와 같은 라우팅 프로토콜은 이러한 상황에 더 적합합니다.

연결 설정

인접하지 않은 네트워크에서 RIPv1 또는 IGRP를 사용하는 경우, 고정 경로를 사용하여 인접하지 않은 서브네트워크 간의 연결을 설정해야 합니다.이 예에서는 이러한 고정 경로가 이 연결을 설정합니다.

라우터 1:

ip route 172.16.2.0 255.255.255.0 172.20.88.1

라우터 2의 경우:

ip route 172.16.5.0 255.255.255.0 172.20.88.2