라우팅 데이터베이스 개요

라우팅 프로토콜 데이터베이스

각 IGP 라우팅 프로토콜은 동일한 프로토콜을 실행하는 다른 라우터에서 학습한 라우팅 정보의 데이터베이스를 유지하고 프로토콜이 정의하고 요구하는 대로 이 정보를 사용합니다. AS 내에서 공유되는 라우팅 정보는 IGP(Interior Gateway Protocol)를 통해 전송됩니다.

다양한 IGP 중에서 가장 일반적인 것은 RIP, OSPF 및 IS-IS입니다. IS-IS 및 OSPF는 수신한 라우팅 정보를 사용하여 링크 상태 데이터베이스를 유지 관리합니다. 이 데이터베이스는 어떤 인접 이웃이 작동하고 있는지 확인하고 네트워크 토폴로지 맵을 구축하는 데 사용합니다. IGP는 빠른 연기와 가벼운 업무 수행을 위해 설계되었습니다. 신뢰할 수 있는 내부 피어는 신뢰할 수 없는 피어가 요구하는 엄격한 보안 조치를 요구하지 않기 때문에 일반적으로 보통 수준의 보안 시스템만 통합합니다. 따라서 일반적으로 모든 내부 인터페이스에서 IGP를 활성화하고 최소의 추가 구성을 수행하여 AS 내에서 라우팅을 시작할 수 있습니다. 개별 인접을 설정할 필요가 없습니다.

IS-IS 및 OSPF는 Dijkstra 알고리즘을 사용하고 RIP 및 RIPng는 Bellman-Ford 알고리즘을 사용하여 최고의 경로 또는 경로(동일한 비용의 경로가 여러 있는 경우)를 결정하여 각 목적지에 도달하고 이러한 경로를 Junos OS 라우팅 테이블에 설치합니다.

피어 AS와 공유되는 라우팅 정보는 외부 게이트웨이 프로토콜(EGP)에 의해 전송됩니다. 거의 모든 네트워크에서 사용하는 기본 EGP는 BGP(Border Gateway Protocol)입니다. BGP는 매우 안전하게 설계되었습니다. 링크의 각 쪽에서 개별 연결을 명시적으로 구성해야 합니다. 따라서 많은 수의 연결이 구성 및 유지 관리가 어렵지만 각 연결은 안전합니다.

인터페이스에서 프로토콜을 구성할 경우 해당 인터페이스에서 프로토콜 제품군을 구성해야 합니다.

Junos OS 라우팅 테이블

Junos OS 라우팅 테이블은 라우팅 정보 데이터베이스를 유지하기 위해 라우팅 프로토콜 프로세스에 사용됩니다. 이 표에서 라우팅 프로토콜 프로세스는 정적으로 구성된 라우트, 직접 연결 인터페이스( 직접 경로 또는 인터페이스 경로라고도 함) 및 모든 라우팅 프로토콜에서 학습한 모든 라우팅 정보를 저장합니다. 라우팅 프로토콜 프로세스는 수집된 라우팅 정보를 사용하여 각 대상에 대한 활성 경로를 선택합니다. 이는 패킷을 대상으로 전송하는 데 실제로 사용되는 경로입니다. 소스 호스트에서 대상 호스트로 트래픽을 라우팅하려면 트래픽이 전달되는 디바이스가 패킷이 취해야 할 경로를 학습해야 합니다. 학습한 후에는 정보가 라우팅 테이블에 저장됩니다. 라우팅 테이블은 A 지점에서 B 지점까지 가능한 모든 경로 목록을 유지합니다.

기본적으로 Junos OS는 세 개의 라우팅 테이블(유니캐스트 경로용, 다른 하나는 멀티캐스트 경로용, 세 번째는 MPLS)을 유지 관리합니다. 특정 라우트 그룹을 분리해야 하거나 라우팅 정보를 조작할 수 있는 유연성이 필요한 경우를 지원하기 위해 추가 라우팅 테이블을 구성할 수 있습니다. 일반적으로 대부분의 운영은 추가 라우팅 테이블의 복잡성에 의존하지 않고 수행할 수 있습니다. 그러나 인터페이스 경로를 두 개 이상의 라우팅 테이블로 가져오고, 동일한 경로를 다른 피어로 익스포트할 때 서로 다른 라우팅 정책을 적용하고, 위화감 있는 멀티캐스트 토폴로지를 통해 유연성을 높이는 등 여러 가지 특정 용도로 라우팅 테이블을 생성할 수 있습니다.

각 라우팅 테이블은 이름으로 식별되며, 이 이름은 프로토콜 제품군에 이어 마침표와 소형의 무계수 정수로 구성됩니다. 프로토콜 제품군은 inet (Internet), iso (ISO) 또는 MPLS(mpls )가 될 수 있습니다. 다음 이름은 Junos OS가 유지 관리하는 기본 라우팅 테이블에 대해 예약되어 있습니다.

• inet.0—기본 IP 버전 4(IPv4) 유니캐스트 라우팅 테이블

• inet6.0—기본 IP 버전 6(IPv6) 유니캐스트 라우팅 테이블

• instance-name.inet.0—특정 라우팅 인스턴스를 위한 유니캐스트 라우팅 테이블

• inet.1—멀티캐스트 포워딩 캐시

• inet.2—RPF(Multicast Reverse Path Forwarding) 조회에 사용되는 유니캐스트 경로

• inet.3—경로 정보를 위한 MPLS 라우팅 테이블

• mpls.0—LSP(Label-Switched Path) 다음 홉을 위한 MPLS 라우팅 테이블

  참고:

  명확히 하려면 이 주제에는 마치 하나의 테이블만 있는 것처럼 라우팅 테이블에 대한 일반적인 논의가 포함되어 있습니다. 그러나 라우팅 테이블 간에 구별해야 하는 경우 해당 이름은 명시적으로 사용됩니다.

네트워크 및 서브네트워크

상호 연결되고 서로 폼 네트워크와 통신할 수 있는 대규모 시스템 그룹. 일반적으로 네트워크는 단일 엔티티가 소유하거나 운영하는 대규모 시스템 및 장치를 식별합니다. 데이터가 호스트에서 호스트로 전달됨에 따라 트래픽은 네트워크 사이 또는 네트워크를 통해 라우팅됩니다.

그림 1 은 간단한 라우터 네트워크를 보여줍니다.

이 간단한 네트워크는 호스트 샌프란시스코에서 마이애미를 호스팅하는 여러 가지 방법을 제공합니다. 패킷은 덴버와 클리블랜드를 통해 경로를 따를 수 있습니다. 또는 패킷을 피닉스를 통해 마이애미로 직접 라우팅할 수 있습니다. 라우팅 테이블에는 가능한 모든 경로와 조합이 포함되어 있습니다. 이 경로는 소스에서 목적지로 가는 모든 방법의 전체 목록입니다.

라우팅 테이블에는 소스에서 대상까지 가능한 모든 경로가 포함되어야 합니다. 그림 1 의 네트워크를 위한 라우팅 테이블에는 샌프란시스코-덴버, 샌프란시스코-클리블랜드, 샌프란시스코-마이애미, 덴버-클리블랜드 등의 항목이 포함되어야 합니다. 소스와 목적지의 수가 증가함에 따라 라우팅 테이블은 빠르게 늘고 있습니다. 과중한 라우팅 테이블 크기는 네트워크를 서브네트워크로 분할하는 주된 이유입니다.

네트워크가 커짐에 따라 네트워크를 유지하고 네트워크 내 호스트 간에 트래픽을 효과적으로 라우팅하는 기능이 점점 더 어려워지고 있습니다. 성장을 수용하기 위해 네트워크는 서브네트워크로 분할됩니다. 기본적으로 서브네트워크는 보다 구체적인 네트워크 주소와 서브넷 마스크(대상 접두사)로 식별된다는 점을 제외하고는 네트워크와 똑같이 작동합니다. 서브네트워크는 라우팅 게이트웨이를 보유하고 있으며 대규모 네트워크와 똑같은 방식으로 라우팅 정보를 공유합니다.

포워딩 테이블

라우팅은 소스에서 대상 주소로 데이터 패킷을 전송하는 것입니다. 여기에는 네트워크 또는 네트워크 전반에 메시지를 전달하는 것이 포함됩니다. 이 프로세스에는 소스에서 대상으로 정확하게 패킷을 전달하기 위한 라우팅 정보 교환과 패킷 포워딩 절차라는 두 가지 주요 구성 요소가 있습니다.

패킷이 적절한 호스트 주소로 올바르게 전달되려면 호스트에 고유한 숫자 식별자 또는 IP 주소가 있어야 합니다. 대상 호스트의 고유 IP 주소는 라우팅 테이블의 엔트리를 형성합니다. 이들 엔트리는 주로 소스에서 대상으로 전송될 때 패킷이 통과하는 경로를 결정하는 책임을 맡고 있습니다.

Junos OS는 라우팅 테이블에서 포워딩 테이블로 모든 활성 경로를 설치합니다. 활성 경로는 패킷을 대상으로 포워딩하는 데 사용됩니다.

Junos OS 커널은 포워딩 테이블의 마스터 복사본을 유지합니다. 패킷 포워딩을 담당하는 라우터의 일부인 패킷 포워딩 엔진에 포워딩 테이블을 복사합니다.

라우팅 테이블이 패킷이 취할 수 있는 모든 경로 목록인 경우 포워딩 테이블은 특정 대상에 대한 최상의 경로 목록입니다. 최상의 경로는 사용 중인 특정 라우팅 프로토콜에 따라 결정되지만 일반적으로 소스와 대상 간의 홉 수가 최상의 경로를 결정합니다.

그림 1에 표시된 네트워크에서 샌프란시스코에서 마이애미까지의 홉 수가 가장 적은 경로는 피닉스를 통과하기 때문에 포워딩 테이블은 가능한 모든 샌프란시스코-마이애미 경로를 피닉스를 통과하는 단일 경로로 라우팅합니다. 마이애미의 목적지 주소가 있는 모든 트래픽은 다음 홉인 피닉스로 직접 전송됩니다.

패킷을 수신한 후 피닉스 라우터는 동일한 대상 주소를 사용하여 또 다른 경로 조회를 수행합니다. 그런 다음 피닉스 라우터는 패킷을 적절하게 라우팅합니다. 전체 경로를 고려하지만, 경로의 개별 홉에서 라우터는 경로의 다음 홉으로 패킷을 전송하는 것만 담당합니다. 피닉스 라우터가 특정 방식으로 트래픽을 관리하는 경우, 마이애미로 가는 길에 휴스턴을 통해 패킷을 보낼 수 있습니다. 이 시나리오는 특정 고객 트래픽이 우선 순위 트래픽으로 취급되고 더 빨라지거나 더 직접적인 경로를 통해 라우팅되는 반면 다른 모든 트래픽은 비보유 트래픽으로 취급될 가능성이 높습니다.

라우팅 및 포워딩 테이블의 동기화 방법

Junos OS 라우팅 프로토콜 프로세스는 라우팅과 포워딩 테이블 간의 라우팅 정보를 동기화하는 작업을 담당합니다. 이를 위해 라우팅 프로토콜 프로세스는 라우팅 테이블의 모든 경로에서 활성 경로를 계산하고 포워딩 테이블에 설치합니다. 라우팅 프로토콜 프로세스는 패킷을 전송하는 라우터의 일부인 라우터의 패킷 포워딩 엔진에 포워딩 테이블을 복사합니다. 그림 2 는 라우팅 테이블이 동기화되는 방법을 보여줍니다.

NetFlow V9 지원

NetFlow Services Export Version 9(NetFlow V9)는 템플릿을 사용하여 라우터에서 패킷을 관찰할 수 있는 확장 가능하고 유연한 방법을 제공합니다. 각 템플릿은 라우터가 데이터를 내보내는 형식을 나타냅니다.

이 기능은 플로우 기반 디바이스에 대해 Netflow V5 또는 V8을 지원합니다.

자세한 내용은 모니터링, 샘플링 및 수집 서비스 인터페이스 사용자 가이드를 참조하십시오.