이 페이지에서
MPLS 트래픽 엔지니어링 구성
MPLS 및 트래픽 엔지니어링
트래픽 엔지니어링을 통해 라우팅 테이블을 사용하는 표준 라우팅 모델을 우회하여 데이터 패킷이 따르는 경로를 제어할 수 있습니다. 트래픽 엔지니어링은 혼잡한 링크에서 자동으로 계산된 목적지 기반 최단 경로에 의해 선 선택되지 않는 대체 링크로 플로우를 이동합니다. 트래픽 엔지니어링을 통해 다음을 할 수 있습니다:
고가의 장거리 파이버를 보다 효율적으로 사용합니다.
단일 또는 여러 실패 발생 시 트래픽이 재라우팅되는 방식을 제어합니다.
주요 트래픽과 일반 트래픽을 경로별로 분류합니다.
트래픽 엔지니어링 설계의 핵심은 라우터 간의 LSP(Label Switched Path) 구축에 기반합니다. LSP는 프레임 릴레이 또는 ATM의 가상 서킷과 같이 연결 지향적입니다. LSP는 다음을 신뢰할 수 없습니다: LSP에 들어가는 패킷은 우선 처리가 가능하지만 전달 보증이 없습니다. LSP는 또한 경로에 들어가는 패킷이 봉투에 캡슐화되어 중간 노드에 터치되지 않고 전체 경로를 가로질러 전환된다는 점에서 단방향 터널과 유사합니다. LSP는 네트워크에서 패킷이 전달되는 방식을 세부적으로 제어합니다. 신뢰성 제공을 위해 LSP는 일련의 1차 및 2차 경로를 사용할 수 있습니다.
LSP는 BGP 트래픽(목적지가 AS[Autonomous System] 외부에 있는 트래픽)에 대해서만 구성할 수 있습니다. 이 경우, AS 내의 트래픽은 LSP의 존재에 영향을 받지 않습니다. LSP는 또한 BGP(Border Gateway Protocol) 및 IGP 트래픽 모두에 대해서도 구성할 수 있습니다. 따라서 AS 내 트래픽과 AS 간 트래픽 모두 LSP의 영향을 받습니다.
MPLS 트래픽 엔지니어링 및 신호 전송 프로토콜 개요
트래픽 엔지니어링은 네트워크 리소스와 트래픽 성능을 최적화하면서 네트워크가 효율적이고 안정적으로 운영되도록 해줍니다. 트래픽 엔지니어링을 수행하면 내부 게이트웨이 프로토콜(IGP)이 선택한 최단 경로의 트래픽 플로우를 네트워크에서 잠재적으로 덜 혼잡한 물리적 경로로 이동할 수 있습니다. 소스 라우팅 외에 트래픽 엔지니어링을 지원하기 위해서는 네트워크가 다음을 수행해야 합니다.
대역폭과 관리 요구 사항 등의 모든 제약 조건을 고려하여 소스의 경로를 계산해야 합니다.
경로가 계산되면 네트워크 전체에 네트워크 토폴로지 및 링크 속성에 대한 정보를 배포해야 합니다.
네트워크 리소스를 예약하고 링크 속성을 수정해야 합니다.
전송 트래픽이 IP 네트워크를 통해 라우팅될 때는 경로 엔지니어링에 MPLS가 자주 사용됩니다. 전송 네트워크의 정확한 경로는 트래픽을 보내는 쪽이나 받는 쪽에 별로 중요하지 않지만, 네트워크 관리자는 종종 특정 원본 및 대상 주소 쌍에서 트래픽을 보다 효율적으로 라우팅하고 싶어 합니다. 각 패킷에 구체적인 라우팅 지침을 포함하는 짧은 레이블을 추가하면 MPLS는 다음 홉 조회를 기반으로 패킷을 전달하는 대신 네트워크에서 라우터 간에 패킷을 스위칭합니다. 그 결과로 생긴 경로를 레이블 스위칭 경로(LSP)라고 합니다. LSP는 네트워크에서 트래픽 이동을 제어하고 트래픽 전달 속도를 높여줍니다.
LSP는 수동으로 또는 신호 전송 프로토콜을 사용하여 생성하실 수 있습니다. 신호 전송 프로토콜은 전송 네트워크에서 트래픽에 대한 LSP를 설정하기 위해 MPLS 환경에서 사용됩니다. Junos OS는 LDP 및 리소스 예약 프로토콜(RSVP)의 두 가지 신호 전송 프로토콜을 지원합니다.
MPLS 트래픽 엔지니어링은 다음과 같은 구성 요소를 사용합니다.
패킷 전달을 위한 MPLS LSP
네트워크 토폴로지 및 링크 속성에 대한 정보를 배포하기 위한 IGP 확장
경로 계산 및 경로 선택을 위한 제한된 최단 경로 우선(CSPF)
경로를 따라 전달 상태를 설정하고 리소스를 예약하기 위한 RSVP 확장
Junos OS는 다른 여러 최단 경로 우선(OSPF) 지역에서도 트래픽 엔지니어링을 지원합니다.
트래픽 엔지니어링 기능
트래픽 흐름을 기존 물리적 토폴로지로 매핑하는 작업이 트래픽 엔지니어링 입니다. 트래픽 엔지니어링을 수행하면 트래픽 플로우를 내부 게이트웨이 프로토콜(IGP)이 선택한 최단 경로에서 나와 네트워크 전체에 걸쳐 잠재적으로 덜 혼잡한 물리적 경로로 이동할 수 있습니다.
트래픽 엔지니어링은 다음을 할 수 있는 기능을 제공합니다.
알려진 병목 현상 또는 네트워크의 혼잡 포인트를 중심으로 기본 경로를 라우팅합니다.
기본 경로가 단일 또는 여러 실패에 직면할 때 트래픽 경로를 다시 라우팅하는 방법을 정밀하게 제어합니다.
네트워크의 다른 하위 집합이 잠재적인 대체 경로를 따라 충분히 활용되지 않으면 네트워크의 하위 집합이 과도하게 활용되지 않도록 하여 사용 가능한 총 대역폭과 장거리 광섬유를 보다 효율적으로 사용할 수 있도록 합니다.
운영 효율성을 극대화합니다.
패킷 손실과 혼잡 기간을 최소화하고 처리량 최대화하여 네트워크의 트래픽 관련 성능 특성을 향상시킵니다.
다중 서비스 인터넷을 지원하기 위해 필요한 네트워크의 통계적으로 바인딩된 성능 특성(예: 손실률, 지연 변동, 전송 지연)을 향상시킵니다.
트래픽 엔지니어링 구성 요소
Junos® 운영 시스템(OS)에서 트래픽 엔지니어링은 MPLS 및 RSVP로 구현됩니다. 트래픽 엔지니어링은 다음과 같은 네 가지 기능 요소로 구성됩니다.
LSP에 대한 트래픽 엔지니어링 구성
LSP를 구성할 때, 호스트 경로(32비트 마스크)는 송신 라우터를 향해 수신 라우터에 설치되며, 호스트 경로의 주소는 LSP의 목적지 주소입니다. [edit protocols mpls]계층 레벨에서 traffic engineering문에 대한 bgp옵션은 기본적으로 활성화되어(bgp옵션을 명시적으로 구성할 수도 있음) BGP(Border Gateway Protocol)만 경로 계산에 LSP를 사용할 수 있습니다. 다른 traffic-engineering문 옵션을 사용해 마스터 라우팅 인스턴스에서 이 행동을 변경할 수 있습니다. 이 기능은 특정 라우팅 인스턴스에서 사용할 수 없습니다. 또한, 한 번에 traffic-engineering문 옵션(bgp,,bgp-igp 또bgp-igp-both-ribs는) 중mpls-forwarding 하나만 활성화할 수 있습니다.
traffic-engineering문 옵션 중 하나를 활성화하거나 비활성화하면 모든 MPLS 경로가 제거되고 라우팅 테이블에 다시 삽입됩니다.
섹션 요약 LSA의 LSP 메트릭 광고에서 설명한 바와 같이 LSAs(Link State Advertisements)에서 LSP 메트릭을 광고하기 위해 최단 경로 우선(OSPF) 및 트래픽 엔지니어링을 구성할 수 있습니다.
다음 섹션에서는 LSP의 트래픽 엔지니어링 구성 방법을 설명합니다:
- BGP 및 IGP 트래픽 포워딩 모두에 대한 LSP 사용
- 가상 개인 네트워크에서 포워딩을 위한 LSP 사용
- 포워딩에 경로 선택이 아닌 RSVP 및 LDP 경로 사용
- 요약 LSA의 LSP 메트릭 광고
BGP 및 IGP 트래픽 포워딩 모두에 대한 LSP 사용
traffic-engineering문에 옵션을 bgp-igp포함하여 송신 라우터 앞으로 트래픽을 포워딩하기 위해 LSP를 사용하도록 BGP 및 IGP를 구성할 수 있습니다. 이 bgp-igp옵션은 모든 inet.3 경로가 inet.0 라우팅 테이블로 이동하도록 합니다.
수신 라우터에서 traffic-engineering문에 옵션을 bgp-igp포함합니다:
traffic-engineering bgp-igp;
다음 계층 수준에서 이 문을 포함시킬 수 있습니다:
[edit protocols mpls][edit logical-systems logical-system-name protocols mpls]주:traffic-engineering문에 대한bgp-igp옵션은 VPN에 대해 구성할 수 없습니다). VPN을 사용하기 위해서는 해당 경로가 inet.3 라우팅 테이블에 있어야 합니다.
가상 개인 네트워크에서 포워딩을 위한 LSP 사용
VPN이 제대로 기능하기 위해서는 해당 경로에 inet.3 라우팅 테이블이 남아 있어야 합니다. VPN의 경우, BGP 및 IGP가 송신 라우터로 향하는 트래픽을 포워딩하기 위해 LSP를 사용하도록 traffic-engineering문의 bgp-igp-both-ribs옵션을 구성합니다. 이 bgp-igp-both-ribs옵션은 수신 경로를 inet.0 라우팅 테이블(IPv4 유니캐스트 경로용)과 inet.3 라우팅 테이블(MPLS 경로 정보용) 모두에 설치합니다.
수신 라우터에는 traffic-engineering bgp-igp-both-ribs문을 포함합니다:
traffic-engineering bgp-igp-both-ribs;
다음 계층 수준에서 이 문을 포함시킬 수 있습니다:
[edit protocols mpls][edit logical-systems logical-system-name protocols mpls]
bgp-igp-both-ribs문을 사용하면 inet.3 테이블의 경로가 inet.0 테이블에 복사됩니다. 복사된 경로는 LDP 신호 또는 RSVP 신호를 받으며 inet.0의 다른 경로보다 선호도가 떨어질 가능성이 높습니다. 선호도가 떨어지는 경로는 활성 경로로 선택될 가능성이 더 높습니다. 라우팅 정책은 활성 경로에만 작용하기 때문에 문제가 될 수 있습니다. 이 문제를 방지하기 위해 mpls-forwarding옵션을 대신 사용합니다.
수치상 가장 낮은 선호 값을 가진 LSP가 선호 경로로 선택됩니다.
예:
user@host# show protocols mpls
label-switched-path lsp1 {
to 192.168.4.4;
preference 1000;
}
label-switched-path lsp2 {
to 192.168.4.4;
preference 1001;
}
user@host# run show route table inet.3
inet.3: 2 destinations, 3 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
198.168.4.4/32 *[RSVP/1000/1] 00:17:23, metric 30
> to 192.168.2.18 via ge-0/0/1.0, label-switched-path lsp1
to 192.168.5.5 via ge-0/0/2.0, label-switched-path Bypass->192.168.2.18->192.168.3.3
[RSVP/1001/1] 00:17:23, metric 30
> to 192.168.2.18 via ge-0/0/1.0, label-switched-path lsp2
to 192.168.5.5 via ge-0/0/2.0, label-switched-path Bypass->192.168.2.18->192.168.3.3선호 설정 값이 1000인 LSP가 우수하므로 선호 설정 값이 1001인 LSP보다 선호됩니다.
포워딩에 경로 선택이 아닌 RSVP 및 LDP 경로 사용
traffic-engineering문에 대한 bgp-igp또는 bgp-igp-both-ribs옵션을 구성하는 경우, 우선 순위가 높은 LSP는 inet.0 라우팅 테이블의 IGP 경로를 대체할 수 있습니다. IGP 경로는 더 이상 활성 경로가 아니기 때문에 더 이상 재배포되지 않을 수 있습니다.
traffic-engineering문에 대한 mpls-forwarding옵션을 구성하는 경우, LSP는 포워딩에 되지만 경로 선택에서 제외됩니다. 이러한 경로는 inet.0 및 inet.3 라우팅 테이블에 모두 추가됩니다. inet.0 라우팅 테이블의 LSP에는 활성 경로가 선택될 때 열등한 우선순위가 부여됩니다. 그러나 inet.3 라우팅 테이블 LSP는 일반적인 기본 선호도가 제공되므로 포워딩 다음 홉을 선택하는 데 사용됩니다.
mpls-forwarding옵션을 활성화하면 현재 활성 경로보다 선호도가 낮더라도 상태가 ForwardingOnly인 경로가 우선적으로 포워딩을 위해 선호됩니다. 경로 상태를 조사하기 위해 show route detail명령을 실행합니다.
LSP를 포워딩에 사용하지만 경로 선택에서 제외하려면 traffic-engineering문에 mpls-forwarding옵션을 포함합니다:
traffic-engineering mpls-forwarding;
다음 계층 수준에서 이 문을 포함시킬 수 있습니다:
[edit protocols mpls][edit logical-systems logical-system-name protocols mpls]
mpls-forwarding 옵션을 구성할 때, IGP 바로 가기 경로는 inet.0 라우팅 테이블에만 복사됩니다.
bgp-igp-both-ribs 옵션과 달리 mpls-forwarding 옵션을 사용하면 LDP 신호 경로 및 RSVP 신호 경로를 포워딩에 사용할 수 있으며, 라우팅 정책이 적용될 수 있도록 라우팅 목적으로 BGP 및 IGP 경로를 활성 상태로 유지할 수 있습니다.
예를 들어, 라우터가 BGP(Border Gateway Protocol)을 실행 중이며 다른 BGP 스피커로 전송해야 하는 BGP 경로가 10.10.10.1/32라고 가정합니다. bgp-igp-both-ribs 옵션을 사용하고, 라우터에 10.10.10.1에 대한 LSP(Label Switched Path)도 있는 경우, 10.10.10.1에 대한 MPLS 경로는 inet.0 라우팅 테이블에서 활성화됩니다. 이를 통해 라우터가 10.10.10.1 경로를 다른 BGP 라우터에 알리는 것을 방지합니다. 반면에, bgp-igp-both-ribs옵션 대신 mpls-forwarding옵션을 사용하는 경우, 10.10.10.1/32 BGP(Border Gateway Protocol) 경로는 BGP 스피커에 광고되며, LSP는 여전히 10.10.10.1 목적지로 트래픽을 포워딩하는 데 사용됩니다.
요약 LSA의 LSP 메트릭 광고
LSP를 링크로 처리하도록 MPLS 및 최단 경로 우선(OSPF)를 구성할 수 있습니다. 이 구성으로 네트워크의 다른 라우터가 이 LSP를 사용할 수 있습니다. 이 목표를 달성하기 위해 요약 LSA의 LSP 메트릭을 광고하도록 MPLS 및 최단 경로 우선(OSPF) 트래픽 엔지니어링을 구성해야 합니다.
MPLS 경우, traffic-engineering bgp-igp및 문label-switched-path을 포함합니다:
traffic-engineering bgp-igp; label-switched-path lsp-name { to address; }
다음 계층 수준에서 이러한 문을 포함할 수 있습니다.
[edit protocols mpls][edit logical-systems logical-system-name protocols mpls]
최단 경로 우선(OSPF)의 경우, lsp-metric-into-summary문을 포함합니다:
lsp-metric-into-summary;
다음 계층 수준에서 이 문을 포함시킬 수 있습니다:
[edit protocols ospf traffic-engineering shortcuts][edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts]
최단 경로 우선(OSPF) 트래픽 엔지니어링에 대한 자세한 정보는 라우팅 장치를 위한 Junos OS 라우팅 프로토콜 라이브러리를 참조하십시오.
영역 간 트래픽 엔지니어링 활성화
Junos OS는 다수의 최단 경로 우선(OSPF) 영역에서 인접한 트래픽 엔지니어링 LSP 신호를 보낼 수 있습니다. LSP 신호는 중첩 또는 인접 신호 중 하나를 사용해 반드시 수행해야 하며, 이는 RFC 4206 일반화된 다중 프로토콜 레이블 스위칭(GMPLS) 트래픽 엔지니어링(TE)에 대한 레이블 스위치 경로(LSP) 계층에 설명되어 있습니다. 그러나 인접한 신호 지원은 기본 신호만으로 제한됩니다. 재 최적화는 인접한 신호와 함께 지원되지 않습니다.
다음은 영역 간 트래픽 엔지니어링 기능 중 일부를 설명합니다.
느슨한 홉 영역 경계 라우터(ABR)가 OSPF 영역 내의 명시적 경로 객체(ERO)를 사용해 수신 라우터에서 구성될 때 영역 간 트래픽 엔지니어링이 활성화될 수 있습니다. ERO 확장은 ABR에서 완료됩니다.
CSPF가 활성화될 때 영역 간 트래픽 엔지니어링 기능이 활성화될 수 있지만, 수신 라우터의 LSP 구성에 ABR이 명시되지 않을 수 있습니다(ABR은 자동으로 지정될 수 있습니다).
차별화된 서비스(DiffServ) 트래픽 엔지니어링은 클래스 유형 매핑이 여러 영역에서 통일되는 한 지원됩니다.
영역 간 트래픽 엔지니어링을 활성화하려면 각 LSP 전송 라우터 구성에 expand-loose-hop 명령문을 포함시키세요.
expand-loose-hop;
다음 계층 수준에서 이 문을 포함시킬 수 있습니다:
[edit protocols mpls][edit logical-systems logical-system-name protocols mpls]
LSP를 위한 AS 간 트래픽 엔지니어링 활성화
일반적으로 다음 조건을 충족하는 LSP에 대해 트래픽 엔지니어링이 가능합니다:
LSP의 양쪽 끝은 동일한 최단 경로 우선(OSPF) 영역이나 동일한 IS-IS(Intermediate System to Intermediate System) 레벨에 있습니다.
LSP의 양쪽 끝은 동일한 자율 시스템(AS) 이내의 서로 다른 최단 경로 우선(OSPF) 영역에 있습니다. 서로 다른 IS-IS(Intermediate System to Intermediate System) 레벨로 끝나는 LSP는 지원되지 않습니다.
명시적 경로 LSP의 양쪽 끝은 서로 다른 최단 경로 우선(OSPF) AS에 있으며 자율 시스템 경계 라우터(ASBR)는 명시적 경로 LSP에서 지원되는 루즈 홉으로 정적으로 구성됩니다. 자세한 내용은 Configuring Explicit-Path LSPs를 참조하십시오.
LSP에서 정적으로 정의된 ASBR이 없으면 하나의 라우팅 도메인 또는 AS와 다른 라우팅 도메인 간에 트래픽 엔지니어링이 불가능합니다. 그러나 AS가 단일의 서비스 프로바이더 제어 하에 있을 경우, 트래픽 엔지니어링 된 LSP가 AS를 통해 그것들을 연결하는 최단 경로 우선(OSPF) ASBR을 동적으로 발견하도록 하는 것이 가능합니다(IS-IS는 이 기능에서 지원되지 않습니다).
AS 간 트래픽 엔지니어링 LSP는 특정 네트워크 요구 사항이 충족되고, 제한 조건이 적용되지 않으며, 최단 경로 우선(OSPF) 패시브 모드가 EBGP로 구성되어 있는 한 가능합니다. 자세한 내용은 다음 섹션에서 제공됩니다:
AS 간 트래픽 엔지니어링 요구 사항
AS 간 트래픽 엔지니어링 LSP의 적절한 설정 및 기능은 다음 네트워크 요구 사항에 따라 다르며, 이 모든 것이 충족되어야 합니다:
모든 AS는 단일 서비스 프로바이더의 통제 하에 있습니다.
최단 경로 우선(OSPF)는 각 AS 내에서 라우팅 프로토콜로 사용되며, EBGP는 AS 간의 라우팅 프로토콜로 사용됩니다.
ASBR 정보는 각 AS 내에서 사용할 수 있습니다.
EBGP 라우팅 정보는 최단 경로 우선(OSPF)에 의해 배포되며, IBGP 완전 메시가 각 AS 내에 배치됩니다.
LSP 송신은 inter AS 링크에서 구성되지 않지만 각 AS의 진입 및 종료 지점 ASBRS 간에 구성됩니다.
서로 다른 AS에서 ASBR 간의 EBGP 링크는 직접 링크이며 최단 경로 우선(OSPF) 하에 패시브 트래픽 엔지니어링 링크로 구성되어야 합니다. 루프백이나 다른 링크 주소가 아닌 원격 링크 주소 자체는 이 패시브 링크의 원격 노드 식별자로 사용됩니다. 최단 경로 우선(OSPF) 패시브 트래픽 엔지니어링 모드 구성에 대한 자세한 내용은 최단 경로 우선(OSPF) 패시브 트래픽 엔지니어링(TE) 모드 구성를 참조하십시오.
또한 최단 경로 우선(OSPF) 패시브 트래픽 엔지니어링 링크의 원격 노드에 사용되는 주소는 EBGP 링크에 사용되는 주소와 동일해야 합니다. 최단 경로 우선(OSPF) 및 BGP(Border Gateway Protocol)에 대한 자세한 내용은 Junos OS Routing Protocols Library for Routing Devices를 참조하십시오.
AS 간 트래픽 엔지니어링 제한 사항
AS 간 트래픽 엔지니어링 LSP에는 계층적 및 중첩된 신호만 지원됩니다. Point-to-point LSP만 지원됩니다(point-to-multipoint 지원은 없습니다).
또한 다음과 같은 제한 사항이 적용됩니다. 위의 요구 사항이 충족되더라도, 이러한 조건들 중 어느 하나라도 inter AS 트래픽 엔지니어링 LSP를 불가능하게 하는 데 충분합니다.
Multihop BGP(Border Gateway Protocol)은 지원되지 않습니다.
AS 내에서 BGP(Border Gateway Protocol) 경로를 알 수 없도록 하는 policer 또는 topology 사용은 지원되지 않습니다.
EBGP peer 간의 LAN에서 다중 ASBR은 지원되지 않습니다. EBGP peer 간의 LAN에서 ASBR은 하나만 지원됩니다(다른 ASBR은 LAN에서 존재할 수 있지만 보급될 수는 없습니다).
ASBR 정보를 숨기거나 ASBR 정보가 AS 내부에서 배포되지 않도록 하는 루트 리플렉터 또는 정책은 지원되지 않습니다.
양방향 LSP는 지원되지 않습니다(LSP는 트래픽 엔지니어링 관점에서 단방향입니다).
동일한 대상에 대한 AS 간 경로와 AS 내부 경로가 모두 있는 topology는 지원되지 않습니다.
또한 모든 LSP에서 일상적으로 사용되는 몇 가지 기능은 AS 간 트래픽 엔지니어링에서 지원되지 않습니다:
관리자 그룹 링크 색상은 지원되지 않습니다.
보조 대기는 지원되지 않습니다.
재최적화는 지원되지 않습니다.
트랜짓 라우터의 크랭크백은 지원되지 않습니다.
다양한 경로 계산은 지원되지 않습니다.
Graceful restart은 지원되지 않습니다.
AS 간 트래픽 엔지니어링 LSP의 제한 사항 또는 지원되지 않는 기능의 목록은 완전하지 않습니다.
최단 경로 우선(OSPF) 패시브 트래픽 엔지니어링(TE) 모드 구성
일반적으로 최단 경로 우선(OSPF)와 같은 내부 라우팅 프로토콜은 AS 간의 링크에서 실행되지 않습니다. 그러나 AS 간 트래픽 엔지니어링이 제대로 작동하려면, AS 간 링크, 특히 원격 인터페이스의 주소에 대한 정보가 AS 내에서 사용 가능해야 합니다. 이 정보는 일반적으로 EBGP 도달 가능성 메시지나 최단 경로 우선(OSPF) 라우팅 광고에는 포함되지 않습니다.
AS 내에서 이 링크 주소 정보를 플러딩하고 트래픽 엔지니어링 계산에서 사용할 수 있도록 하려면 각 AS 간 인터페이스에서 트래픽 엔지니어링에 대한 최단 경로 우선(OSPF) 패시브 모드를 구성해야 합니다. 또한 최단 경로 우선(OSPF)가 배포하고 트래픽 엔지니어링 데이터베이스에 포함할 수 있도록 원격 주소를 제공해야 합니다.
AS 간 인터페이스에서 트래픽 엔지니어링을 위한 최단 경로 우선(OSPF) 패시브 모드를 구성하려면 [edit protocols ospf area area-id interface interface-name]계층 레벨에서 링크에 대한 passive문을 포함합니다:
passive {
traffic-engineering {
remote-node-id ip-address; /* IP address at far end of inter-AS link */
}
}
최단 경로 우선(OSPF)가 라우터에서 올바르게 구성되어 있어야 합니다. 다음 예제에서는 AS 내에서 최단 경로 우선(OSPF)를 사용하여 트래픽 엔지니어링 정보를 배포하도록 AS 간 링크so-1/1/0를 구성합니다. 원격 IP 주소는 192.168.207.2입니다.
[edit protocols ospf area 0.0.0.0]
interface so-1/1/0 {
unit 0 {
passive {
traffic-engineering {
remote-node-id 192.168.207.2;
}
}
}
}
패킷 전달 구성 요소
Junos 트래픽 엔지니어링 아키텍처의 패킷 전달 구성 요소는 MPLS입니다. MPLS는 네트워크에서 사전 결정된 경로를 따라 IP 패킷의 플로우를 안내하는 역할을 합니다. 이 경로를 레이블 스위칭 경로(LSP)라고 합니다. LSP는 단순합니다. 즉, 트래픽이 헤드엔드(수신) 라우터에서 테일엔드(송신) 라우터로 한 방향으로 흐릅니다. 이중 트래픽의 경우 각 방향의 트래픽을 전달하는 두 개의 LSP가 필요합니다. LSP는 한 개 이상의 레이블 스위칭 홉을 연결하여 생성되기 때문에 MPLS 도메인에서 특정 라우터의 패킷이 다른 라우터로 전달되도록 해줍니다.
수신 라우터는 IP 패킷을 수신하면 이 패킷에 MPLS 헤더를 추가하고 LSP의 다음 라우터로 이를 전달합니다. 레이블이 지정된 이 패킷은 LSP의 테일엔드인 송신 라우터에 도달할 때까지 각 라우터가 LSP를 따라 전달합니다. 이제 MPLS 헤더가 제거되고 IP 대상 주소와 같은 레이어 3 정보를 기반으로 패킷이 전달됩니다. 이 방식의 좋은 점은 LSP의 물리적 경로가 대상 IP 주소에 도달하기 위해 IGP가 최단 경로로 어떤 것을 선택할지에 제한받지 않는다는 것입니다.
레이블 스와핑을 기반으로 패킷 전달하기
각 라우터의 패킷 전달 프로세스는 레이블 스와핑이라는 개념을 기반으로 합니다. 이 개념은 고정 가상 회선(PVC)에서 각 비동기 전송 방식(ATM) 스위치에 발생하는 것과 비슷합니다. 각 MPLS 패킷은 20비트의 고정 길이 레이블 필드를 포함하는 4바이트 캡슐화 헤더를 전달합니다. 레이블을 포함하는 패킷이 라우터에 도착하면 라우터는 이 레이블을 검사하고 MPLS 포워딩 테이블에 인덱스로 복사합니다. 포워딩 테이블의 각 항목에는 동일한 인바운드 레이블의 특정 인터페이스에 도착하는 모든 패킷에 적용되는 일련의 포워딩 정보와 매핑된 인터페이스-인바운드 레이블 쌍이 포함되어 있습니다.
패킷이 MPLS 백본을 통과하는 방법
이 섹션에서는 IP 패킷이 MPLS 백본 네트워크를 통과할 때 어떻게 처리되는지 설명합니다.
MPLS 백본의 입력 에지에서 수신 라우터가 IP 헤더를 검사합니다. 이 분석을 기반으로 패킷이 분류되고, 레이블이 할당되며, MPLS 헤더에서 캡슐화되어 LSP의 다음 홉을 향해 전달됩니다. MPLS는 IP 패킷이 LSP에 할당되는 방식에 있어 매우 높은 유연성을 제공합니다. 예를 들어, Junos 트래픽 엔지니어링 구현에서 동일한 송신 라우터의 MPLS 도메인을 나갈 예정인 수신 라우터에 도착하는 모든 패킷은 동일한 LSP에 따라 전달됩니다.
패킷이 LSP를 통과하기 시작하면 각 라우터는 레이블을 사용하여 어떻게 전달할지 결정합니다. MPLS 전달 방식은 원래 IP 헤더와 상관없이 결정됩니다. 수신 인터페이스와 레이블은 MPLS 포워딩 테이블에 대한 조회 키로 사용됩니다. 이전 레이블은 새 레이블로 교체되고 패킷이 LSP에 따라 다음 홉으로 전달됩니다. 패킷이 송신 라우터에 도달할 때까지 LSP의 각 라우터에서 이 프로세스가 반복됩니다.
패킷이 송신 라우터에 도착하면 레이블이 제거되고 패킷이 MPLS 도메인을 나갑니다. 그런 다음 IP 라우팅 프로토콜이 계산하는 기존의 최단 거리 경로에 따라 패킷의 원래 IP 헤더에 포함된 대상 IP 주소를 기반으로 패킷이 전달됩니다.
정보 배포 구성 요소
트래픽 엔지니어링에는 네트워크 로딩에 대한 동적 정보뿐만 아니라 네트워크 토폴로지에 대한 자세한 정보가 필요합니다. 정보 배포 구성 요소를 구현하기 위해 간단한 IGP 확장이 정의됩니다. 링크 속성은 각 라우터의 링크 상태 광고(LSA)의 일부로 포함됩니다. IS-IS(Intermediate System to Intermediate System) 확장은 새로운 TLV(유형, 길이, 값)를 포함하고, 최단 경로 우선(OSPF) 확장은 불투명 링크 상태 광고(LSA)로 구현됩니다. 링크 상태 IGP가 사용하는 표준 플러딩 알고리즘에 의해 링크 상태가 라우팅 도메인의 모든 라우터에 배포됩니다. IGP 링크 상태 광고에 추가될 트래픽 엔지니어링 확장의 일부에는 최대 링크 대역폭, 최대 예약 링크 대역폭, 현재 대역폭 예약 및 링크 색상 지정이 포함됩니다.
각 라우터는 특수한 트래픽 엔지니어링 데이터베이스에 네트워크 링크 속성과 토폴로지 정보를 유지합니다. 이 트래픽 엔지니어링 데이터베이스는 물리적 토폴로지에서 LSP를 배치하기 위해 명시적 경로를 계산하는 용도로만 사용됩니다. 그 다음의 후속 트래픽 엔지니어링 계산은 IGP 및 IGP의 링크 상태 데이터베이스와 상관없이 이루어지도록 별도의 데이터베이스가 유지 관리됩니다. 한편 IGP는 수정 없이 계속 작동하면서 라우터의 링크 상태 데이터베이스에 포함된 정보를 기반으로 기존의 최단 거리 경로 계산을 수행합니다.
경로 선택 구성 요소
IGP가 네트워크 링크 속성과 토폴로지 정보를 플러딩하여 트래픽 엔지니어링 데이터베이스에 배치하면 각 수신 라우터는 이 트래픽 엔지니어링 데이터베이스를 사용하여 라우팅 도메인의 여러 LSP에 대한 경로를 계산합니다. 각 LSP의 경로는 엄격하거나 느슨한 명시적 경로로 표시될 수 있습니다. 명시적 경로는 LSP의 물리적 경로에 포함되어야 하는 라우터의 사전 구성된 시퀀스입니다. 수신 라우터가 LSP의 모든 라우터를 지정하는 경우, 이 LSP는 엄격한 명시적 경로에 의해 확인된다고 말합니다. 수신 라우터가 LSP의 일부 라우터만 지정하는 경우에는 LSP가 느슨한 명시적 경로라 표현됩니다. 엄격한 명시적 경로와 느슨한 명시적 경로를 지원함으로써 경로 선택 프로세스에 가능하면 광범위한 자유를 주면서 필요할 때는 제약을 가할 수도 있습니다.
수신 라우터는 트래픽 엔지니어링 데이터베이스의 정보에 CSPF(Constrained Shortest Path First) 알고리즘을 적용하여 각 LSP에 대한 물리적 경로를 결정합니다. CSPF는 네트워크에서 가장 짧은 경로가 계산될 때 특정 제한 사항을 고려하도록 수정된 최단 경로 우선 알고리즘입니다. CSPF 알고리즘은 다음과 같은 입력 정보를 포함할 수 있습니다.
IGP에서 학습되어 트래픽 엔지니어링 데이터베이스에 보관되는 토폴로지 링크 상태 정보
IGP 확장에 의해 전달되어 트래픽 엔지니어링 데이터베이스에 보관되는 네트워크 리소스 상태 관련 속성(예: 총 링크 대역폭, 예약된 링크 대역폭, 사용 가능한 링크 대역폭, 링크 색상)
사용자 구성에서 획득한 제안된 LSP를 통과하는 트래픽을 지원하는 데 필요한 관리 속성(예: 대역폭 요구 사항, 최대 홉 수, 관리 정책 요구 사항)
CSPF는 새로운 LSP에 대한 각 후보 노드 및 링크를 고려하기 때문에 리소스 가용성을 기반으로 또는 해당 구성 요소 선택이 사용자 정책 제약을 위반하는지 여부에 따라 특정 경로 구성 요소를 수락하거나 거부합니다. CSPF 계산의 출력 결과는 제약 조건을 충족하는 네트워크 내 최단 경로를 제공하는 라우터 주소 시퀀스로 구성된 명시적 경로입니다. 그러면 이 명시적 경로는 신호 전송 구성 요소로 전달되어 LSP 상의 라우터에 전달 상태를 설정합니다.
신호 전송 구성 요소
LSP는 신호 전송 구성 요소에 의해 실제로 설정되기 전에는 사용 가능한 것으로 알려지지 않습니다. LSP 상태를 설정하고 레이블을 배포하는 역할을 하는 신호 전송 구성 요소는 다음과 같은 여러 RSVP 확장에 의존합니다.
명시적 경로 개체는 RSVP 경로 메시지가 기존의 최단 경로 IP 라우팅과 상관없는 라우터의 명시적 시퀀스를 통과할 수 있게 해줍니다. 이 명시적 경로는 엄격할 수도 있고 느슨할 수도 있습니다.
레이블 요청 개체는 RSVP 경로 메시지가 중간 라우터로 하여금 설정하려는 LSP에 레이블 결합을 제공하도록 요청할 수 있게 해줍니다.
레이블 개체는 RSVP가 기존 메커니즘을 변경하지 않고 레이블 배포를 지원할 수 있게 해줍니다. RSVP 예약 메시지는 RSVP 경로 메시지의 역경로를 따르기 때문에 레이블 개체가 다운스트림 노드에서 업스트림 노드로의 레이블 배포를 지원합니다.
오프라인 경로 계획 및 분석
온라인 경로 계산으로 인한 관리 노력의 감소에도 불구하고 오프라인 계획 및 분석 도구는 전 세계적으로 트래픽 엔지니어링을 최적화하는 데 필요합니다. 온라인 계산은 자원 제약을 고려하여 한 번에 한 LSP를 계산합니다. 이 접근 방법의 문제는 결정적이지 못하다는 것입니다. LSP가 계산되는 순서는 네트워크 전반에 걸쳐 각 LSP의 물리적 경로를 결정하는 데 중요한 역할을 합니다. 이 과정에서 초기에 계산된 LSP는 이전에 계산된 LSP가 네트워크 자원을 소비하기 때문에 나중에 계산된 LSP보다 더 많은 자원을 사용할 수 있습니다. LSP가 계산되는 순서가 변경되는 경우 LSP의 물리적 경로의 결과 집합도 변경될 수 있습니다.
오프라인 계획 및 분석 도구는 각 링크의 자원 제약 및 각 LSP의 요구 사항을 동시에 검토합니다. 오프라인 접근 방식은 완료에 거의 모든 시간이 걸릴 수 있지만 글로벌 계산을 수행하고 각 계산 결과를 비교하고 나서 네트워크 전체에 가장 적합한 최고의 솔루션을 선택합니다. 오프라인 계산의 결과는 네트워크 자원의 사용을 최적화하는 LSP 집합입니다. 오프라인 계산이 완료된 후 LSP는 전 세계적으로 최적화된 솔루션의 규칙에 따라 각각 설치 되므로 임의의 순서로 설정할 수 있습니다.
유연한 LSP 계산 및 구성
트래픽 엔지니어링은 트래픽 플로우를 물리적 토폴로지로 매핑하는 것과 관련이 있습니다. 제약 기반 라우팅을 사용하여 온라인으로 경로를 결정할 수 있습니다. 물리적 경로가 어떻게 계산되는지에 관계없이 전송 상태는 RSVP를 통해 네트워크 전반에 걸쳐 지정됩니다.
Junos OS는 다음과 같이 LSP를 라우팅하고 구성하는 방법을 지원합니다.
LSP에 대한 전체 경로를 오프라인에서 계산할 수 있으며 필요한 정적 전송 상태로 LSP에서 각 라우터를 개별적으로 구성할 수 있습니다. 이는 일부 인터넷 서비스 제공업체(ISP)가 자체 IP-over-ATM 코어를 구성하는 방법과 유사합니다.
LSP의 전체 경로를 오프라인에서 계산할 수 있으며 전체 경로로 수신 라우터를 정적으로 구성할 수 있습니다. 그러면 수신 라우터는 LSP를 따라 각 라우터에서 전송 상태를 설정하는 동적 신호 전송 프로토콜로 RSVP를 사용합니다.
동적 온라인 LSP를 계산하기 위해 제약 기반 라우팅에 의존할 수 있습니다. 각 LSP에 대한 제약을 구성하면 네트워크 자체는 이러한 제약을 가장 잘 충족하는 경로를 결정합니다. 특히, 수신 라우터는 제약에 따라 전체 LSP를 계산한 다음 네트워크 전반에 걸쳐 신호 전송을 시작합니다.
LSP의 부분 경로를 오프라인에서 계산할 수 있고 경로의 라우터 하위 세트로 수신 라우터를 정적으로 구성한 다음, 온라인 계산을 허용하여 전체적인 경로를 결정할 수 있습니다.
예를 들어, 미국 전역에서 두 개의 동서 경로를 포함하는 토폴로지를 고려하십시오. 북쪽에 있는 한 개는 시카고를 통해 지나가고 남쪽에 있는 한 개는 댈러스를 통해 지나갑니다. 뉴욕에 있는 라우터와 샌프란시스코에 있는 라우터 사이에 LSP를 설정하고 싶다면 댈러스에 있는 라우터에 대한 느슨한 경로의 단일 홉을 포함하도록 LSP의 부분 경로를 구성할 수 있습니다. 결과는 남부 경로를 따라 LSP 라우트가 지정됩니다. 수신 라우터는 CSPF를 사용하여 전체 경로를 계산하고 RSVP를 사용하여 LSP를 따라 전송 상태를 지정합니다.
어떠한 제약 없이 수신 라우터를 구성할 수 있습니다. 이 경우, LSP 경로를 결정하는 데 일반적으로 IGP의 가장 짧은 경로 라우팅이 사용됩니다. 이러한 구성은 트래픽 엔지니어링 측면에서 어떠한 가치도 제공하지 않습니다. 그러나 이는 사용하기 쉽고 가상 사설 통신망(Virtual Private Networks: VPN)과 같은 서비스가 필요한 상황에서 유용할 수 있습니다.
이러한 모든 경우에서, 일차 LSP의 백업으로 여러 LSP를 지정할 수 있으므로 둘 이상의 구성 접근 방식을 결합할 수 있습니다. 예를 들어, 일차 경로를 명시적으로 오프라인에서 명백히 계산하고 이차 경로를 제약 기반이 되도록 설정하며 3차 경로를 비-제약 기반이 되도록 할 수 있습니다. 일차 LSP가 라우팅되는 서킷이 실패할 경우, 수신 라우터는 다운스트림 라우터로부터 수신된 오류 알림 또는 RSVP 소프트 상태 정보의 만료로 인해 중단을 알아차립니다. 그런 다음 라우터는 트래픽을 상시 대기 중인 LSP로 동적으로 전송하거나 RSVP에 새로운 백업 LSP를 위한 전송 상태를 생성하도록 요청합니다.
BGP 개요를 사용하는 Link-State 분포
- IGP(Interior Gateway Protocol) 역할
- IGP(Interior Gateway Protocol)의 한계
- Link-State 분포 확장의 필요성
- BGP를 솔루션으로 사용
- 지원 및 비지원 기능
- SPRING(Source Packet Routing in Networking)을 위한 BGP Link-State 확장
- OSPF를 IGP로 사용하는 BGP를 통해 학습된 NLRI 노드 확인
- OSPF를 IGP로 사용하여 BGP를 통해 학습한 접두사 NLRI 확인
IGP(Interior Gateway Protocol) 역할
IGP(Interior Gateway Protocol)는 AS(Autonomous System) 내의 장치 간에 라우팅 정보를 교환하는 데 사용되는 프로토콜 유형입니다. 목적지까지의 최적 경로를 계산하는 방법에 따라 IGP는 두 가지 범주로 나누어집니다.
Link-state 프로토콜 - Link-state 프로토콜을 실행하는 모든 라우터가 인터네트워크에 대한 동일한 정보를 가질 때까지 멀티캐스트 주소 및 트리거된 라우팅 업데이트를 사용하여 모든 라우터에 네트워크 토폴로지(직접 연결된 링크 및 해당 link-state)에 대한 정보를 보급합니다. 목적지에 대한 최적의 경로는 최대 지연, 사용 가능한 최소 대역폭, 리소스 클래스 선호도와 같은 제약 조건을 기준으로 계산됩니다.
최단 경로 우선(OSPF)과 IS-IS가 link-state 프로토콜의 예입니다.
디스턴스 벡터 프로토콜 - 브로드캐스트 주소를 사용하여 직접 연결된 이웃에 완전한 라우팅 테이블 정보를 보급합니다. 최적의 경로는 목적지 네트워크에 대한 홉 개수를 기준으로 계산됩니다.
RIP는 디스턴스 벡터 프로토콜의 예입니다.
이름에서 알 수 있듯이, IGP의 역할은 주어진 라우팅 도메인 내부에 라우팅 연결을 제공하는 것입니다. 라우팅 도메인은 공통 라우팅 프로토콜을 공유하는 공통 관리 제어 하에 있는 라우터 집합입니다. AS는 여러 라우팅 도메인으로 구성될 수 있으며, IGP는 인접 라우터로부터 네트워크 접두사(경로)를 보급하고 학습하여 특정 접두사에 대한 연결성을 보급하는 모든 소스에 대한 항목을 궁극적으로 포함하는 경로 테이블을 구축합니다. IGP는 경로 선택 알고리즘을 실행하여 로컬 라우터와 각 목적지 간의 최적 경로를 선택하고 라우팅 도메인을 구성하는 라우터 간의 완벽한 연결을 제공합니다.
IGP는 내부 네트워크 연결성을 보급하는 것 외에도 경로 재분배라고 하는 프로세스를 통해 해당 IGP의 라우팅 도메인 외부에 있는 라우팅 정보를 보급하는 데 자주 사용됩니다. 경로 재분배는 AS 내부 연결이 필요할 때 여러 라우팅 도메인을 함께 묶기 위해 별개의 라우팅 프로토콜 사이에서 라우팅 정보를 교환하는 프로세스입니다.
IGP(Interior Gateway Protocol)의 한계
각 개별 IGP는 고유한 장점과 한계가 있지만 일반적으로 IGP의 가장 큰 한계는 성능과 확장성입니다.
IGP는 트래픽 엔지니어링용으로 네트워크 토폴로지 정보를 획득하고 배포하는 작업을 처리하도록 설계되었습니다. 이 모델은 제대로 작동하지만 IGP는 대규모 데이터베이스를 배포하는 데 있어 확장 한계가 내재되어 있습니다. IGP는 영역 내 토폴로지 정보를 획득하는 이웃을 자동 감지할 수 있습니다. 그러나 link-state 데이터베이스 또는 트래픽 엔지니어링 데이터베이스는 단일 영역이나 AS 범위를 가지므로, 종단 간 트래픽 엔지니어링과 같은 응용 프로그램을 제한하면 외부 가시성이 확보되어 더 나은 결정을 내릴 수 있습니다.
MPLS 및 GMPLS(Generalized MPLS)와 같은 레이블 스위칭 네트워크의 경우, 대부분의 기존 트래픽 엔지니어링 솔루션은 단일 라우팅 도메인에서 작동합니다. 이러한 솔루션은 수신 노드에서 송신 노드로의 경로가 송신 노드의 라우팅 영역 또는 AS를 벗어날 때 작동하지 않습니다. 이러한 경우, 네트워크 전체에서 완전한 라우팅 정보를 사용할 수 없기 때문에 경로 계산 문제가 복잡해집니다. 이는 일반적으로 서비스 공급자가 확장성 제약과 기밀성에 대한 우려로 라이팅 영역이나 AS를 넘어 라우팅 정보를 누출하지 않기로 선택하기 때문입니다.
Link-State 분포 확장의 필요성
IGP의 한계 중 한 가지는 단일 영역이나 AS를 벗어나 link-state 분포를 확장할 수 없다는 것입니다. 그러나 여러 영역 또는 AS에서 IGP가 확보한 link-state 정보를 확장하려면 다음이 필요합니다.
LSP 경로 계산 - 이 정보는 여러 라우팅 도메인(예: 영역 간 TE LSP)에서 MPLS LSP의 경로를 계산하는 데 사용됩니다.
외부 경로 컴퓨팅 엔터티 - ALTO(Application Layer Traffic Optimization) 및 PCE(Path Computation Elements)와 같은 외부 경로 컴퓨팅 엔터티는 트래픽 엔지니어링 정보를 포함하여 네트워크 토폴로지와 네트워크 내 연결의 현재 상태를 기반으로 경로 계산을 수행합니다. 이 정보는 일반적으로 네트워크 내의 IGP에 의해 배포됩니다.
그러나 외부 경로 컴퓨팅 엔터티는 IGP에서 이 정보를 추출할 수 없으므로 네트워크 모니터링을 수행하여 네트워크 서비스를 최적화합니다.
BGP를 솔루션으로 사용
개요
여러 도메인에서 link-state 분포에 대한 요구 사항을 충족하기 위해 외부 게이트웨이 프로토콜(EGP)은 IGP 영역에서 link-state와 트래픽 엔지니어링 정보를 수집하고, 이를 외부 구성 요소와 공유하며, 도메인 간 MPLS LSP 컴퓨팅 경로에 사용해야 합니다.
BGP는 AS(Autonomous System) 간에 라우팅과 연결성 정보를 교환하도록 설계된 표준화된 EGP입니다. BGP는 수백 만 개의 항목(예: VPN 접두사)을 확장 가능한 방식으로 배분할 수 있으므로 더 나은 확장 속성을 보유한 입증된 프로토콜입니다. BGP는 오늘날 인터넷의 모든 경로를 전달하는 데 적합한 유일한 라우팅 프로토콜입니다. 주로 BGP가 TCP 위에서 실행되고 TCP flow 제어를 사용할 수 있기 때문입니다. 반대로 내부 게이트웨이 프로토콜(IGP)에는 플로우 제어가 없습니다. IGP에 경로 정보가 너무 많으면 이탈이 시작됩니다. BGP에 정보를 너무 빨리 전송하는 인접 스피커가 있는 경우 BGP는 TCP 승인을 지연시켜 해당 이웃을 제한할 수 있습니다.
BGP의 또 다른 이점은 기본 프로토콜을 변경할 필요 없이 끝없는 확장성을 제공하는 TLV(유형, 길이, 값) 튜플 및 NLRI(Network Layer Reachability Information)를 사용한다는 것입니다.
도메인 전반에 link-state 정보를 배포하는 것은 서비스 제공자의 이익을 보호하기 위한 정책을 사용하여 규제됩니다. 이를 위해서는 정책을 사용하여 토폴로지 배포를 제어해야 합니다. 구현된 정책 프레임워크가 있는 BGP는 도메인 간 경로 배포에서 잘 작동합니다. Junos OS에서 BGP는 정책 중심입니다. 운영자는 피어링할 neighbor를 명시적으로 구성하고 BGP에 대한 경로를 수락해야 합니다. 또한 라우팅 정책은 라우팅 정보를 필터링하고 수정하는 데 사용됩니다. 따라서 라우팅 정책은 라우팅 테이블에 대한 완전한 관리 제어를 제공합니다.
AS 내에서 IGP-TE와 BGP-TE 모두 동일한 정보 집합을 제공하지만, BGP-TE는 표준 BGP 프로토콜에서 상속되는 더 나은 확장 속성을 가집니다. 이 속성은 BGP-TE를 다중 영역/다중 AS 토폴로지 정보를 획득하기 위한 보다 확장 가능한 선택으로 만듭니다.
BGP를 솔루션으로 사용하여 IGP에서 획득한 정보를 BGP로 배포하는 데 사용합니다. ISP는 일반 BGP 피어링을 통해 이 정보를 다른 ISP, 서비스 제공업체 및 CDN(Content Distribution Network)에 선택적으로 노출할 수 있습니다. 이를 통해 외부 경로 컴퓨팅 엔터티가 경로 리플렉터를 수동적으로 수신하여 정보에 액세스할 수 있도록 여러 영역과 AS에서 IGP 획득 정보를 집계할 수 있습니다.
구현
Junos OS에서 IGP는 토폴로지 정보를 TED(Traffic Engineering Database)라는 데이터베이스에 설치합니다. TED(Traffic Engineering Database)에는 집계된 토폴로지 정보가 포함됩니다. TED(Traffic Engineering Database)에 IGP 토폴로지 정보를 설치하려면 [edit protocols isis traffic-engineering]및 [edit protocols ospf traffic-engineering]계층 수준에서 set igp-topology구성 문을 사용해야 합니다. BGP를 사용하여 link-state 정보를 배포하는 메커니즘에는 TED(Traffic Engineering Database)를 BGP-TE에 알리고(가져오기)하고 BGP-TE에서 TED(Traffic Engineering Database)로 항목을 설치하는(내보내기) 프로세스가 포함됩니다.
Junos OS 릴리스 20.4R1부터 IPv4 주소 외에 TED(Traffic Engineering Database)에 IPv6 정보를 저장하도록 IS-IS 트래픽 엔지니어링을 구성할 수 있습니다. BGP-LS는 TED(Traffic Engineering Database) 가져오기 정책을 사용하여 TED(Traffic Engineering Database)에서 lsdist.0 라우팅 테이블로의 경로로 이 정보를 배포합니다. 이러한 경로는 IPv6 라우터 ID TLV(유형, 길이, 값)가 포함된 NLRI(Network Layer Reachability Information)로 BGP-TE 피어에 보급됩니다. IPv6 정보를 추가하면 전체 네트워크 토폴로지를 TED(Traffic Engineering Database)로 가져올 수 있습니다.
BGP-LS NLRI 및 컨페더레이션 ID
Junos OS 릴리스 23.1R1부터 Junos OS는 BGP 컨페더레이션이 활성화된 경우 BGP-LS(BGP Link State) NLRI(Network Layer Reachability Information)가 TLV 512에 컨페더레이션 ID를 포함할 수 있도록 지원합니다. NLRI는 RFC 9086에 명시된 것과 같이 TLV 517에 멤버 AS(Autonomous System) 번호와 함께 컨페더레이션 ID를 포함합니다. Junos OS 트래픽 엔지니어링 데이터베이스 모듈은 BGP-LS NLRI(lsdist.0 라우팅 테이블에 추가됨)를 발생시키면서 TLV 512 및 TLV 517에 각각 컨페더레이션 ID와 멤버 AS 번호를 인코딩하기 위해 필요한 변경을 수행합니다. Junos OS 릴리스 23.1R1 이전의 릴리스에서는 BGP-LS NLRI가 TLV 512에 멤버 AS 번호만 포함하며 컨페더레이션 ID가 lsdist.0 라우팅 테이블에 인코딩되지 않습니다.
TED(Traffic Engineering Database) 가져오기
TED(Traffic Engineering Database)를 BGP-TE에 보급하기 위해 TED(Traffic Engineering Database)의 링크와 노드 항목이 경로 형태로 변환됩니다. 이렇게 변환된 경로는 경로 정책에 따라 해당 IGP를 대신하여 TED(Traffic Engineering Database)에 의해 사용자가 볼 수 있는 lsdist.0라는 라우팅 테이블에 설치됩니다. TED(Traffic Engineering Database)에서 lsdist.0로 항목을 유출하는 절차는 TED(Traffic Engineering Database) 가져오기라고 합니다(그림 그림 1).
TED(Traffic Engineering Database) 가져오기 프로세스를 제어하는 정책이 있습니다. 기본적으로 TED(Traffic Engineering Database)에서 lsdist.0 테이블로 항목이 유출되지 않습니다.
Junos OS 릴리스 17.4R1부터 TED(Traffic Engineering Database)는 lsdist.0 라우팅 테이블의 RSVP-TE 토폴로지 정보 외에도 IGP(Interior Gateway Protocol) 토폴로지 정보를 설치합니다(그림 그림 1). Junos OS 릴리스 17.4R1 이전에는 TED(Traffic Engineering Database)에서 RSVP-TE 토폴로지 정보만 내보냈습니다. 이제 IGP 및 트래픽 엔지니어링 토폴로지 정보를 모두 모니터링할 수 있습니다. BGP-LS는 lsdist.0에서 IGP 항목을 읽고 이러한 항목을 BGP 피어에 보급합니다. IGP 토폴로지 정보를 lsdist.0에서 BGP-LS로 가져오려면 [edit protocols mpls traffic-engineering database import igp-topology]계층 수준에서 set bgp-ls구성 문을 사용합니다.
TED(Traffic Engineering Database) 내보내기
BGP는 정책에 따라 lsdist.0 테이블에서 경로를 내보내거나 보급하도록 구성할 수 있습니다. 이것은 BGP의 모든 종류의 경로 발생에서 공통적입니다. BGP-TE를 TED(Traffic Engineering Database)에 보급하려면 BGP-TE address family와 BGP로 재배포할 경로를 선택하는 내보내기 정책으로 BGP를 구성해야 합니다.
그런 다음 BGP는 다른 NLRI와 마찬가지로 이러한 경로를 전파합니다. BGP-TE family가 구성되고 협상된 BGP 피어는 BGP-TE NLRI를 수신합니다. BGP는 수신된 BGP-TE NLRI를 lsdist.0 테이블에 경로 형태로 저장합니다. 이는 로컬에서 발생한 BGP-TE 경로를 저장하는 것과 동일한 테이블입니다. lsdist.0에서 BGP 설치 경로는 다른 경로와 마찬가지로 다른 피어에 배포됩니다. 따라서 표준 경로 선택 절차는 여러 스피커에서 수신되는 BGP-TE NLRI에 적용됩니다.
도메인 간 TE를 달성하기 위해 lsdist.0의 경로가 정책을 통해 TED(Traffic Engineering Database)로 유출됩니다. 이 프로세스는 TED(Traffic Engineering Database)라고 합니다(그림 그림 1).
TED(Traffic Engineering Database) 내보내기 프로세스를 제어하는 정책이 있습니다. 기본적으로 lsdist.0 테이블에서 TED(Traffic Engineering Database)로 항목이 유출되지 않습니다.
Junos OS 릴리스 22.4R1부터 세그먼트 라우팅 프로토콜에서 생성되는 트래픽 엔지니어링(TE) 정책을 트래픽 엔지니어링 데이터베이스(TED) 및 BGP 링크 상태에 경로로 배포할 수 있습니다. BGP 링크 상태는 외부 컨트롤러가 도메인 내에서는 물론 여러 도메인 전체에 대해 경로 계산, 다시 최적화, 네트워크 시각화 등의 작업을 수행할 수 있도록 트래픽 엔지니어링(TE) 정책과 관련된 정보를 수집합니다.
세그먼트 라우팅(SR) 정책을 TED에 보관할 수 있으려면 set protocols source-packet-routing traffic-engineering database를 구성해야 합니다.
PCE 및 ALTO와 같은 SDN 애플리케이션의 경우 BGP-TE 보급 정보는 라우터의 TED(Traffic Engineering Database)로 유출될 수 없습니다. 이러한 경우 BGP-TE를 사용하여 라우터와 피어링하는 외부 서버를 사용하여 네트워크에 걸쳐 있는 스카이/오케스트레이션 시스템으로 토폴로지 정보를 이동할 수 있습니다. 이러한 외부 서버는 BGP-TE 소비자로 간주될 수 있으며 여기에서 BGP-TE 경로를 수신하지만 보급하지는 않습니다.
신뢰성 값 할당
항목이 TED(Traffic Engineering Database)에 설치되면 BGP-TE에서 학습한 정보를 CSPF 경로 계산에 사용할 수 있습니다. TED(Traffic Engineering Database)는 신뢰성 값을 기반으로 하는 프로토콜 선호 체계를 사용합니다. 신뢰성 값이 낮은 프로토콜보다 신뢰성 값이 높은 프로토콜이 선호됩니다. BGP-TE는 동시에 여러 프로토콜에서 학습한 정보를 보급할 수 있는 기능이 있으므로, TED(Traffic Engineering Database)의 IGP 설치 항목 외에도 두 개 이상의 프로토콜에 해당하는 BGP-TE 설치 항목이 있을 수 있습니다. TED(Traffic Engineering Database) 내보내기 구성 요소는 BGP-TE가 지원하는 각 프로토콜에 대한 TED(Traffic Engineering Database) 프로토콜과 신뢰성 수준을 생성합니다. 이러한 신뢰성 값은 CLI에서 구성할 수 있습니다.
BGP-TE 프로토콜의 신뢰성 순서는 다음과 같습니다.
-
Unknown—80
-
OSPF—81
-
ISIS Level 1—82
-
ISIS Level 2—83
-
정적—84
-
Direct—85
교차 신뢰성 경로 계산
신뢰성 값을 할당한 후, 각 신뢰성 수준이 개별 평면으로 처리됩니다. CSPF(Constraint Shortest Path First) 알고리즘은 할당된 가장 높은 신뢰성에서 가장 낮은 신뢰성으로 시작하여, 해당 신뢰성 수준 내에서 경로를 찾습니다.
BGP-TE를 사용하면 AS 간 경로를 계산하기 위해 신뢰성 수준 전반에서 경로를 계산하는 것이 필수적입니다. 예를 들어, 영역 0 항목이 OSPF에 의해 설치되고 영역 1 항목은 BGP-TE에 의해 설치되므로, 영역 1을 통해 경로를 계산하는 영역 0과 다른 신뢰도 설정이 장치에 표시됩니다.
신뢰성 수준에서 경로 계산을 활성화하려면 , 및 [edit protocols rsvp]계층 수준에서 cross-credibility-cspfedit protocols mpls[edit protocols mpls label-switched-path lsp-name]문을 포함합니다. [edit protocols rsvp] 계층 수준에서 cross-credibility-cspf을 활성화하면 bypass LSP와 전송 중 느슨한 홉 확장에 영향을 미칩니다.
cross-credibility-cspf을 구성하면 CSPF(Constrained Shortest Path First) 알고리즘을 사용하여 신뢰성 수준 전반에서 경로 계산이 가능합니다. 여기서 제약은 신뢰성 기준으로 수행되지 않고 할당된 신뢰성 값을 무시하는 단일 제약으로 수행됩니다.
BGP-TE NLRI 및 TLV
다른 BGP 경로와 마찬가지로 BGP-TE NLRI는 BGP-TE NLRI를 말하는 경로 리플렉터를 통해 배포될 수도 있습니다. Junos OS는 BGP-TE family에 대한 경로 리플렉션 지원을 구현합니다.
다음은 지원되는 NLRI 목록입니다.
-
Link NLRI
-
Node NLRI
-
IPv4 Prefix NLRI(수신 및 전파)
-
IPv6 Prefix NLRI(수신 및 전파)
-
트래픽 엔지니어링(TE) 정책 NLRI
Junos OS는 위의 NRLI route-distinguisher 형식을 지원하지 않습니다.
다음은 링크 및 노드 NLRI에서 지원되는 필드 목록입니다.
-
Protocol-ID—NLRI는 다음 프로토콜 값으로 시작됩니다.
-
ISIS-L1
-
ISIS-L2
-
OSPF
-
SPRING-TE
-
-
Identifier—이 값은 구성 가능합니다. 기본적으로 식별자 값은
0으로 설정됩니다. -
Local/Remote node descriptor—다음이 포함됩니다.
-
AS(Autonomous System)
-
BGP-LS Identifier—이 값은 구성 가능합니다. 기본적으로 BGP-LS 식별자 값은
0으로 설정됩니다. -
Area-ID
-
IGP router-ID
-
-
Link descriptors (Only for link NLRI)—여기에는 다음이 포함됩니다.
-
링크 로컬/원격 식별자
-
IPv4 인터페이스 address
-
IPv4 neighbor address
-
IPv6 neighbor/인터페이스 address - IPv6 neighbor 및 인터페이스 address는 생성되지 않고 수신될 때만 저장 및 전파됩니다.
-
Multi-토폴로지 ID - 이 값은 생성된 것이 아니라 수신 시 저장 및 전파됩니다.
-
다음은 지원되는 LINK_STATE 속성 TLV 목록입니다.
-
링크 속성:
-
관리 그룹
-
최대 링크 대역폭
-
최대 예약 대역폭
-
비예약 대역폭
-
트래픽 엔지니어링(TE) 기본 메트릭
-
SRLG
-
다음 TLV는 생성되지 않고 수신될 때만 저장 및 전파됩니다.
-
불투명 링크 속성
-
MPLS 프로토콜 마스크
-
메트릭
-
링크 보호 유형
-
링크 이름 속성
-
-
-
노드 속성:
-
IPv4 Router-ID
-
Node flag bits - 오버로드 비트만 설정됩니다.
-
다음 TLV는 생성되지 않고 수신될 때만 저장 및 전파됩니다.
-
Multi-토폴로지
-
OSPF 특정 노드 속성
-
불투명 노드 속성
-
노드 이름
-
IS-IS 영역 식별자
-
IPv6 Router-ID
-
-
접두사 속성 - 이러한 TLV는 다른 알려지지 않은 TLV처럼 저장 및 전파됩니다.
-
지원 및 비지원 기능
Junos OS는 BGP를 사용한 link-state 분포와 함께 다음 기능을 지원합니다.
멀티프로토콜 보장 포워딩 기능 보급
노드 및 link-state BGP와 BGP-TE NLRI의 송수신
BGP-TE NLRI를 위한 NSR(Nonstop Active Routing)
정책
Junos OS는 BGP를 사용한 link-state 분포에 대해 다음 기능을 지원하지 않습니다. not
집계된 토폴로지, 링크 또는 노드
BGP-TE NLRI를 위한 경로 구분자
Multi-토폴로지 식별자
Multi-instance 식별자(기본 인스턴스 ID 제외)
링크 및 노드 영역 TLV 보급
MPLS 시그널링 프로토콜 보급
중복되는 address로 노드 및 링크 정보 가져오기
SPRING(Source Packet Routing in Networking)을 위한 BGP Link-State 확장
Junos OS 릴리스 17.2R1부터 BGP link-state address family가 확장되어 SPRING(Source Packet Routing in Networking) 토폴로지 정보를 SDN(Software-Defined Networking) 컨트롤러에 배포합니다. BGP는 일반적으로 IGP로부터 link-state 정보를 학습하고 이를 BGP 피어에 배포합니다. BGP 외에도 SDN 컨트롤러는 컨트롤러가 IGP 도메인의 일부인 경우 IGP에서 직접 link-state 정보를 가져올 수 있습니다. 그러나 BGP link-state 분포는 토폴로지 정보를 내보내기 위해 확장 가능한 메커니즘을 제공합니다. SPRING용 BGP link-state 확장은 도메인 간 네트워크에서 지원됩니다.
- SPRING(Source Packet Routing in Networking)
- BGP Link-State SPRING 데이터 흐름
- 지원되는 BGP Link-State 속성 및 TLV, SPRING이 있는 BGP Link-State에 지원되지 않는 기능
SPRING(Source Packet Routing in Networking)
SPRING는 수신 라우터가 실제 경로를 결정하기 위해 네트워크의 중간 노드에 의존하지 않고, 네트워크의 특정 노드와 링크 집합을 통해 패킷을 조정할 수 있도록 하는 컨트롤 플레인 아키텍처입니다. SPRING은 네트워크 세그먼트 보급을 위해 IS-IS, OSPF와 같은 IGP를 연결합니다. 네트워크 세그먼트는 토폴로지 또는 service 기반의 모든 명령을 나타낼 수 있습니다. IGP 세그먼트는 IGP 토폴로지 내에서 link-state 라우팅 프로토콜에 의해 보급됩니다. IGP 세그먼트에는 두 가지 유형이 있습니다.
| Adjacency segment |
IGP에 있는 두 노드 사이의 특정 인접성을 통한 one-hop 경로 |
| Prefix segment |
IGP 토폴로지 상태에 따르며, 접두사에 대한 multi-hop, equal-cost, multipath-aware shortest-path |
BGP 네트워크에서 SPRING이 활성화되면 BGP link-state address family는 IGP link-state 라우팅 프로토콜에서 SPRING 정보를 학습하고 세그먼트 식별자(SID) 형식으로 세그먼트를 보급합니다. BGP link-state address family는 SID 및 기타 SPRING 관련 정보를 BGP 피어에 전달하도록 확장되었습니다. 경로 리플렉터는 적절한 터널 조합으로 패킷을 추가하여 원하는 노트 및 링크 집합을 통해 패킷을 조정할 수 있습니다. 이 기능을 사용하면 BGP link-state address family가 SPRING 정보를 BGP 피어에 보급할 수도 있습니다.
BGP Link-State SPRING 데이터 흐름
그림 2는 IS-IS가 TED(Traffic Engineering Database)에 푸시하는 BGP link-state SPRING 데이터의 데이터 흐름을 나타냅니다.
-
IGP는 SPRING 속성을 TED(Traffic Engineering Database)에 푸시합니다.
-
SPRING 기능 및 알고리즘 정보는 노드 속성으로 TED(Traffic Engineering Database)로 전달됩니다.
-
인접 SID 및 LAN 인접 SID 정보는 링크 속성으로 전달됩니다.
-
접두사 SID 또는 노드-SID 정보는 접두사 속성으로 전달됩니다.
-
새로운 집합 또는 기존 속성의 변경은 새로운 데이터로 TED(Traffic Engineering Database)에 대한 IGP 업데이트를 트리거합니다.
경고:IGP 수준에서 트래픽 엔지니어링이 비활성화된 경우 TED(Traffic Engineering Database)에 대한 어떤 속성도 푸시되지 않습니다.
-
링크, 노드, 접두사 설명자를 포함한 BGP 트래픽 엔지니어링 NLRI의 모든 매개 변수는 TED(Traffic Engineering Database)의 항목에서 파생됩니다.
-
TED(Traffic Engineering Database)는 정책에 따라 IGP에서 경로 항목을
lsdist.0라우팅 테이블로 가져옵니다. -
BGP의 기본 정책은 BGP에만 알려진 경로를 내보내는 것입니다.
lsdis.0라우팅 테이블에서 비 BGP 경로에 대한 내보내기 정책을 구성합니다. 이 정책은 TED(Traffic Engineering Database)에서 학습한 항목을 보급합니다.
지원되는 BGP Link-State 속성 및 TLV, SPRING이 있는 BGP Link-State에 지원되지 않는 기능
SPRING이 있는 BGP link-state는 네트워크에서 시작, 수신 및 전파되는 다음 속성과 TLV(유형, 길이, 값)를 지원합니다.
Node attributes
-
세그먼트 라우팅 기능
-
세그먼트 라우팅 알고리즘
Link attributes
-
Adjacent-SID
-
LAN Adjacent-SID
Prefix descriptors
-
IP 연결성 정보
Prefix attributes
-
Prefix SID
다음 목록은 시작되지 않았지만 네트워크에서 수신 및 전파되는 TLV를 지원합니다.
Prefix descriptors
-
Multi토폴로지 ID
-
OSPF 경로 유형
Prefix attributes
-
Range
-
Binding SID
Junos OS는 SPRING 확장이 있는 BGP link-state에서 다음 기능을 지원하지 않습니다.
-
IPv6 prefix 발생
-
Multi토폴로지 식별자
-
SPRING 매개 변수에 대한 TED(Traffic Engineering Database) 내보내기
-
tcpdump가 있는 새 TLV(기존 TLV도 지원되지 않음)
-
IPv6을 통한 SPRING
OSPF를 IGP로 사용하는 BGP를 통해 학습된 NLRI 노드 확인
다음은 OSPF를 IGP로 사용하여 BGP를 통해 학습된 NLRI 노드를 확인하기 위한 샘플 출력입니다.
목적
lsdist.0 라우팅 테이블 항목을 확인합니다.
작업
운영 모드에서 show route table lsdist.0 명령을 실행합니다.
user@host> show route table lsdist.0 te-node-ip 10.7.7.7 extensive
lsdist.0: 216 destinations, 216 routes (216 active, 0 holddown, 0 hidden)
NODE { AS:65100 Area:0.0.0.1 IPv4:10.7.7.7 OSPF:0 }/1536 (1 entry, 1 announced)
TSI:
LINK-STATE attribute handle 0x61d5da0
*BGP Preference: 170/-101
Next hop type: Indirect, Next hop index: 0
Address: 0x61b07cc
Next-hop reference count: 216
Source: 10.2.2.2
Protocol next hop: 10.2.2.2
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
State:<Active Int Ext>
Local AS: 65100 Peer AS: 65100
Age: 30:22 Metric2: 2
Validation State: unverified
Task: BGP_65100.10.2.2.2
Announcement bits (1): 0-TED Export
AS path: I
Accepted
Area border router: No
External router: No
Attached: No
Overload: No
SPRING-Capabilities:
- SRGB block [Start: 900000, Range: 90000, Flags: 0x00]
SPRING-Algorithms:
- Algo: 0
Localpref: 100
Router ID: 10.2.2.2
Indirect next hops: 1
Protocol next hop: 10.2.2.2 Metric: 2
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 10.11.1.2 via et-0/0/0.1 weight 0x1
Session Id: 0x143
10.2.2.2/32 Originating RIB: inet.0
Metric: 2 Node path count: 1
Forwarding nexthops: 1
Nexthop: 10.11.1.2 via et-0/0/0.1
Session Id: 143의미
경로가 lsdist.0 라우팅 테이블에 나타납니다.
OSPF를 IGP로 사용하여 BGP를 통해 학습한 접두사 NLRI 확인
다음은 OSPF를 IGP로 사용하여 BGP를 통해 학습한 접두사 NLRI를 확인하기 위한 샘플 출력입니다.
목적
lsdist.0 라우팅 테이블 항목을 확인합니다.
작업
운영 모드에서 show route table lsdist.0 명령을 실행합니다.
user@host> show route table lsdist.0 te-ipv4-prefix-node-ip 10.7.7.7 extensive
lsdist.0: 216 destinations, 216 routes (216 active, 0 holddown, 0 hidden)
PREFIX { Node { AS:65100 Area:0.0.0.1 IPv4:10.7.7.7 } { IPv4:10.7.7.7/32 } OSPF:0 }/1536 (1 entry, 0 announced)
*BGP Preference: 170/-101
Next hop type: Indirect, Next hop index: 0
Address: 0x61b07cc
Next-hop reference count: 216
Source: 10.2.2.2
Protocol next hop: 10.2.2.2
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
State: <Active Int Ext>
Local AS: 65100 Peer AS: 65100
Age: 30:51 Metric2: 2
Validation State: unverified
Task: BGP_65100.10.2.2.2
AS path: I
Accepted
Prefix Flags: 0x00, Prefix SID: 1007, Flags: 0x50, Algo: 0
Localpref: 65100
Router ID: 10.2.2.2
Indirect next hops: 1
Protocol next hop: 10.2.2.2 Metric: 2
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 10.11.1.2 via et-0/0/0.1 weight 0x1
Session Id: 0x143
10.2.2.2/32 Originating RIB: inet.0
Metric: 2 Node path count: 1
Forwarding nexthops: 1
Nexthop: 10.11.1.2 via et-0/0/0.1
Session Id: 143의미
경로가 lsdist.0 라우팅 테이블에 나타납니다.
예: BGP를 사용하는 link-state 배포 구성
이 예에서는 BGP(Border Gateway Protocol)를 구성하여 여러 도메인에 걸쳐 link-state 정보를 전달하는 방법을 보여줍니다. 이는 영역 간 트래픽 엔지니어링(TE) LSP와 같은 복수 도메인의 MPLS LSP에 대한 경로를 계산하고 네트워크 토폴로지를 획득하기 위해 ALTO 및 PCE 등과 같이 확장 가능하고 정책으로 제어되는 외부 경로 계산 개체의 수단을 제공하는 데 사용됩니다.
요구 사항
이 예에서 사용되는 하드웨어 및 소프트웨어 구성 요소는 다음과 같습니다.
-
M 시리즈, MX 시리즈 또는 T 시리즈 라우터 조합의 라우터 4개
-
모든 라우터에서 실행되는 Junos OS 릴리스 14.2 또는 이후 버전
시작하기 전에:
-
디바이스 인터페이스를 구성합니다.
-
디바이스에 대한 AS(Autonomous System) 번호 및 라우터 ID를 구성합니다.
-
다음과 같은 프로토콜을 구성합니다.
-
RSVP
-
MPLS
-
BGP
-
IS-IS
-
OSPF
-
개요
Junos OS 릴리스 14.2부터는 여러 영역과 AS(Autonomous System)에 토폴로지 정보를 배포하는 새로운 메커니즘이 도입되어 원래 IGP를 사용해 입수됐던 link-state 정보가 BGP(Border Gateway Protocol) 확장을 통해 전달됩니다. IGP 프로토콜은 대규모 데이터베이스를 배포하는 데 있어 확장 제한이 있습니다. BGP는 다중 영역 및 다중 AS 토폴로지 정보를 전달하기 위한 보다 확장 가능한 수단일 뿐만 아니라 다중 AS 토폴로지 배포에 유용할 수 있는 정책 제어를 제공합니다. BGP link-state 토폴로지 정보는 영역 간 트래픽 엔지니어링(TE) LSP와 같은 복수 도메인의 MPLS LSP(Label Switched Path)에 대한 경로를 계산하고 네트워크 토폴로지를 획득하기 위해 ALTO 및 PCE 등과 같이 확장 가능하고 정책으로 제어되는 외부 경로 계산 개체의 수단을 제공하는 데 사용됩니다.
Junos OS 릴리스 17.1R1부터는 QFX10000 스위치에서 BGP를 사용하는 link-state 배포가 지원됩니다.
토폴로지
그림 3에서 라우터 R0 및 R1과 라우터 R2 및 R3는 다른 AS(Autonomous System)에 속합니다. 라우터 R0 및 R1은 OSPF를 실행하고, 라우터 R2 및 R3는 IS-IS를 실행합니다.
구성
CLI 빠른 구성
이 예를 빠르게 구성하려면, 아래 명령을 복사하여 텍스트 파일로 붙여 넣은 다음 모든 라인브레이크를 제거하고, 네트워크 구성을 일치하는 데 필요한 세부 사항을 바꾸고 [edit] 계층 수준에서 명령을 CLI로 복사해 붙여 넣은 다음, 구성 모드에서 commit을 입력합니다.
R0
set interfaces ge-0/0/0 unit 0 family inet address 10.8.31.101/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.137/32 set routing-options router-id 10.255.105.137 set routing-options autonomous-system 65533 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering database export policy accept-all set protocols mpls cross-credibility-cspf set protocols mpls label-switched-path to-R3-inter-as to 10.255.105.135 set protocols mpls label-switched-path to-R3-inter-as bandwidth 40m set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.137 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp neighbor 10.255.105.141 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept
R1
set interfaces ge-0/0/0 unit 0 family inet address 10.8.31.103/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.8.42.102/24 set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.141/32 set interfaces lo0 unit 0 family iso address 47.0005.0102.5501.8181 set routing-options router-id 10.255.105.141 set routing-options autonomous-system 65533 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.141 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp export nlri2bgp set protocols bgp group ibgp neighbor 10.255.105.137 set protocols bgp group ebgp type external set protocols bgp group ebgp family traffic-engineering unicast set protocols bgp group ebgp neighbor 10.8.42.104 local-address 10.8.42.102 set protocols bgp group ebgp neighbor 10.8.42.104 peer-as 65534 set protocols isis interface ge-0/0/1.0 passive remote-node-iso 0102.5502.4211 set protocols isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.104 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.104 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.139 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept set policy-options policy-statement nlri2bgp term 1 from family traffic-engineering set policy-options policy-statement nlri2bgp term 1 then accept
R2
set interfaces ge-0/0/0 unit 0 family inet address 10.8.64.104/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.8.42.104/24 set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.139/32 set interfaces lo0 unit 0 family iso address 47.0005.0102.5502.4211.00 set routing-options router-id 10.255.105.139 set routing-options autonomous-system 65534 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering database import policy ted2nlri set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.139 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp export nlri2bgp set protocols bgp group ibgp neighbor 10.255.105.135 set protocols bgp group ebgp type external set protocols bgp group ebgp family traffic-engineering unicast set protocols bgp group ebgp export nlri2bgp set protocols bgp group ebgp peer-as 65533 set protocols bgp group ebgp neighbor 10.8.42.102 set protocols isis level 1 disable set protocols isis interface ge-0/0/0.0 set protocols isis interface ge-0/0/1.0 passive remote-node-iso 0102.5501.8181 set protocols isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.102 set protocols isis interface lo0.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.102 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.141 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept set policy-options policy-statement nlri2bgp term 1 from family traffic-engineering set policy-options policy-statement nlri2bgp term 1 then accept set policy-options policy-statement ted2nlri term 1 from protocol isis set policy-options policy-statement ted2nlri term 1 from protocol ospf set policy-options policy-statement ted2nlri term 1 then accept set policy-options policy-statement ted2nlri term 2 then reject
R3
set interfaces ge-0/0/0 unit 0 family inet address 10.8.64.106/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.135/32 set interfaces lo0 unit 0 family iso address 47.0005.0102.5502.4250 set routing-options router-id 10.255.105.135 set routing-options autonomous-system 65534 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering database export policy accept-all set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.135 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp neighbor 10.255.105.139 set protocols isis interface ge-0/0/0.0 level 1 disable set protocols isis interface lo0.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept
절차
단계별 절차
다음 예는 구성 계층에서 다양한 수준의 탐색이 필요합니다. CLI 탐색에 대한 정보는 구성 모드에서 CLI 편집기 사용을 참조하십시오.
라우터 R1을 구성하려면 다음과 같이 하십시오.
-
라우터 R1 인터페이스를 구성합니다.
[edit interfaces] user@R1# set ge-0/0/0 unit 0 family inet address 10.8.31.103/24 user@R1# set ge-0/0/0 unit 0 family iso user@R1# set ge-0/0/0 unit 0 family mpls user@R1# set ge-0/0/1 unit 0 family inet address 10.8.42.102/24 user@R1# set ge-0/0/1 unit 0 family iso user@R1# set ge-0/0/1 unit 0 family mpls user@R1# set lo0 unit 0 family inet address 10.255.105.141/32 user@R1# set lo0 unit 0 family iso address 47.0005.0102.5501.8181
-
라우터 R1의 라우터 ID와 AS(Autonomous System)를 구성합니다.
[edit routing-options]user@R1# set router-id 10.255.105.141 user@R1# set autonomous-system 65533 -
라우터 R1의 모든 인터페이스에서(관리 인터페이스 제외) RSVP를 활성화합니다.
[edit protocols]user@R1# set rsvp interface all user@R1# set rsvp interface fxp0.0 disable -
라우터 R1의 모든 인터페이스에서(관리 인터페이스 제외) MPLS를 활성화합니다.
[edit protocols]user@R1# set mpls interface all user@R1# set mpls interface fxp0.0 disable -
라우터 R1이 라우터 R0과 피어링하도록 BGP 그룹을 구성하고 로컬 주소와 neighbor 주소를 할당합니다.
[edit protocols]user@R1# set bgp group ibgp type internal user@R1# set bgp group ibgp local-address 10.255.105.141 user@R1# set bgp group ibgp neighbor 10.255.105.137 -
ibgp BGP 그룹에 BGP-TE 신호 전송 NLRI(Network Layer Reachability Information)를 포함합니다.
[edit protocols]user@R1# set bgp group ibgp family traffic-engineering unicast -
라우터 R1에서 정책 nlri2bgp 내보내기를 활성화합니다.
[edit protocols]user@R1# set bgp group ibgp export nlri2bgp -
라우터 R1이 라우터 R2와 피어링하도록 BGP 그룹을 구성하고 로컬 주소와 neighbor AS(Autonomous System)를 ebgp BGP 그룹에 할당합니다.
[edit protocols]user@R1# set bgp group ebgp type external user@R1# set bgp group ebgp neighbor 10.8.42.104 local-address 10.8.42.102 user@R1# set bgp group ebgp neighbor 10.8.42.104 peer-as 65534 -
ebgp BGP 그룹에 BGP-TE 신호 전송 NLRI를 포함합니다.
[edit protocols]user@R1# set bgp group ebgp family traffic-engineering unicast -
AS 간 링크에서 passive traffic-engineering을 활성화합니다.
[edit protocols]user@R1# set isis interface ge-0/0/1.0 passive remote-node-iso 0102.5502.4211 user@R1# set isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.104 -
라우터 R1을 라우터 R0에 연결하는 인터페이스와 라우터 R1의 루프백 인터페이스에서 최단 경로 우선(OSPF)을 활성화하고 트래픽 엔지니어링 기능을 활성화합니다.
[edit protocols]user@R1# set ospf traffic-engineering user@R1# set ospf area 0.0.0.0 interface lo0.0 user@R1# set ospf area 0.0.0.0 interface ge-0/0/0.0 -
AS 간 링크에서 passive traffic-engineering을 활성화합니다.
[edit protocols]user@R1# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.104 user@R1# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.139 -
BGP-TE NLRI에서 오는 트래픽을 허용하도록 정책을 구성합니다.
[edit policy-options]user@R1# set policy-statement accept-all from family traffic-engineering user@R1# set policy-statement accept-all then accept user@R1# set policy-statement nlri2bgp term 1 from family traffic-engineering user@R1# set policy-statement nlri2bgp term 1 then accept
결과
구성 모드에서 show interfaces, show routing-options, show protocols 및 show policy-options 명령을 입력하여 구성을 확인합니다. 출력 결과가 의도한 구성대로 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정하십시오.
user@R1# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 10.8.31.103/24;
}
family iso;
family mpls;
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.8.42.102/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.105.141/32;
family iso {
address 47.0005.0102.5501.8181:00;
}
}
}
user@R1# show routing-options router-id 10.255.105.141; autonomous-system 65533;
user@R1# show protocols
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
interface all;
interface fxp0.0 {
disable;
}
}
bgp {
group ibgp {
type internal;
local-address 10.255.105.141;
family traffic-engineering {
unicast;
}
export nlri2bgp;
neighbor 10.255.105.137;
}
group ebgp {
type external;
family traffic-engineering {
unicast;
}
neighbor 10.8.42.104 {
local-address 10.8.42.102;
peer-as 65534;
}
}
}
isis {
interface ge-0/0/1.0 {
passive {
remote-node-iso 0102.5502.4211;
remote-node-id 10.8.42.104;
}
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface lo0.0;
interface ge-0/0/0.0;
interface ge-0/0/1.0 {
passive {
traffic-engineering {
remote-node-id 10.8.42.104;
remote-node-router-id 10.255.105.139;
}
}
}
}
}
user@R1# show policy-options
policy-statement accept-all {
from family traffic-engineering;
then accept;
}
policy-statement nlri2bgp {
term 1 {
from family traffic-engineering;
then {
accept;
}
}
}
절차
단계별 절차
다음 예는 구성 계층에서 다양한 수준의 탐색이 필요합니다. CLI 탐색에 대한 정보는 구성 모드에서 CLI 편집기 사용을 참조하십시오.
다음을 참조하여 라우터 R2를 구성하십시오:
-
라우터 R2 인터페이스를 구성합니다.
[edit interfaces] user@R2# set ge-0/0/0 unit 0 family inet address 10.8.64.104/24 user@R2# set ge-0/0/0 unit 0 family iso user@R2# set ge-0/0/0 unit 0 family mpls user@R2# set ge-0/0/1 unit 0 family inet address 10.8.42.104/24 user@R2# set ge-0/0/1 unit 0 family iso user@R2# set ge-0/0/1 unit 0 family mpls user@R2# set lo0 unit 0 family inet address 10.255.105.139/32 user@R2# set lo0 unit 0 family iso address 47.0005.0102.5502.4211.00
-
라우터 R2의 라우터 ID와 AS(Autonomous System)를 구성합니다.
[edit routing-options]user@R2# set router-id 10.255.105.139 user@R2# set autonomous-system 65534 -
라우터 R2의 모든 인터페이스에서(관리 인터페이스 제외) RSVP를 활성화합니다.
[edit routing-options]user@R2# set rsvp interface all user@R2# set rsvp interface fxp0.0 disable -
라우터 R2의 모든 인터페이스에서(관리 인터페이스 제외) MPLS를 활성화합니다.
[edit routing-options]user@R2# set mpls interface all user@R2# set mpls interface fxp0.0 disable -
ted2nlri 정책을 사용하여 트래픽 엔지니어링 데이터베이스 매개 변수 가져오기를 활성화합니다.
[edit protocols]user@R2# set mpls traffic-engineering database import policy ted2nlri -
라우터 R2가 라우터 R3와 피어링되도록 BGP(Border Gateway Protocol) 그룹을 구성하고 로컬 주소와 neighbor 주소를 할당합니다.
[edit protocols]user@R2# set bgp group ibgp type internal user@R2# set bgp group ibgp local-address 10.255.105.139 user@R2# set bgp group ibgp neighbor 10.255.105.135 -
ibgp BGP 그룹에 BGP-TE 신호 전송 NLRI(Network Layer Reachability Information)를 포함합니다.
[edit protocols]user@R2# set bgp group ibgp family traffic-engineering unicast -
라우터 R2에서 정책 nlri2bgp 내보내기를 활성화합니다.
[edit protocols]user@R2# set bgp group ibgp export nlri2bgp -
라우터 R2가 라우터 R1과 피어링하도록 BGP 그룹을 구성합니다.
[edit protocols]user@R2# set bgp group ebgp type external -
ebgp BGP 그룹에 BGP-TE 신호 전송 NLRI를 포함합니다.
[edit protocols]user@R2# set bgp group ebgp family traffic-engineering unicast -
ebgp BGP 그룹에 로컬 주소와 neighbor AS(Autonomous System)를 할당합니다.
[edit protocols]user@R2# set bgp group ebgp peer-as 65533 user@R2# set bgp group ebgp neighbor 10.8.42.102 -
라우터 R2에서 정책 nlri2bgp 내보내기를 활성화합니다.
[edit protocols]user@R2# set bgp group ebgp export nlri2bgp -
라우터 R2를 라우터 R3과 연결하는 인터페이스와 라우터 R2의 루프백 인터페이스에서 IS-IS(Intermediate System to Intermediate System)를 활성화합니다.
[edit protocols]user@R2# set isis level 1 disable user@R2# set isis interface ge-0/0/0.0 user@R2# set isis interface lo0.0 -
라우터 R2를 라우터 R1과 연결하는 인터페이스에서 IS-IS 광고만 활성화합니다.
[edit protocols]user@R2# set isis interface ge-0/0/1.0 passive remote-node-iso 0102.5501.8181 user@R2# set isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.102 -
라우터 R2에서 트래픽 엔지니어링 기능을 구성합니다.
[edit protocols]user@R2# set ospf traffic-engineering -
라우터 R2를 라우터 R1과 연결하는 인터페이스에서 최단 경로 우선(OSPF) 광고만 활성화합니다.
[edit protocols]user@R2# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.102 user@R2# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.141 -
BGP-TE NLRI에서 오는 트래픽을 허용하도록 정책을 구성합니다.
[edit policy-options]user@R2# set policy-statement accept-all from family traffic-engineering user@R2# set policy-statement accept-all then accept user@R2# set policy-statement nlri2bgp term 1 from family traffic-engineering user@R2# set policy-statement nlri2bgp term 1 then accept user@R2# set policy-statement ted2nlri term 1 from protocol isis user@R2# set policy-statement ted2nlri term 1 from protocol ospf user@R2# set policy-statement ted2nlri term 1 then accept user@R2# set policy-statement ted2nlri term 2 then reject
결과
구성 모드에서 show interfaces, show routing-options, show protocols 및 show policy-options 명령을 입력하여 구성을 확인합니다. 출력 결과가 의도한 구성대로 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정하십시오.
user@R2# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 10.8.64.104/24;
}
family iso;
family mpls;
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.8.42.104/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.105.139/32;
family iso {
address 47.0005.0102.5502.4211.00;
}
family iso;
}
}
user@R2# show routing-options router-id 10.255.105.139; autonomous-system 65534;
user@R2# show protocols
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
traffic-engineering {
database {
import {
policy ted2nlri;
}
}
}
interface all;
interface fxp0.0 {
disable;
}
}
bgp {
group ibgp {
type internal;
local-address 10.255.105.139;
family traffic-engineering {
unicast;
}
export nlri2bgp;
neighbor 10.255.105.135;
}
group ebgp {
type external;
family traffic-engineering {
unicast;
}
export nlri2bgp;
peer-as 65533;
neighbor 10.8.42.102;
}
}
isis {
level 1 disable;
interface ge-0/0/0.0;
interface ge-0/0/1.0 {
passive {
remote-node-iso 0102.5501.8181;
remote-node-id 10.8.42.102;
}
}
interface lo0.0;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/1.0 {
passive {
traffic-engineering {
remote-node-id 10.8.42.102;
remote-node-router-id 10.255.105.141;
}
}
}
}
}
user@R2# show policy-options
policy-statement accept-all {
from family traffic-engineering;
then accept;
}
policy-statement nlri2bgp {
term 1 {
from family traffic-engineering;
then {
accept;
}
}
}
policy-statement ted2nlri {
term 1 {
from protocol [ isis ospf ];
then accept;
}
term 2 {
then reject;
}
}
검증
구성이 올바르게 작동하고 있는지 확인합니다.
BGP 요약 상태 확인
목적
라우터 R0 및 R1에서 BGP가 제대로 실행되는지 확인합니다.
작업
운영 모드에서 show bgp summary 명령을 실행합니다.
user@R0> show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
lsdist.0
10 10 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.255.105.141 65533 20 14 0 79 5:18 Establ
lsdist.0: 10/10/10/0운영 모드에서 show bgp summary 명령을 실행합니다.
user@R1> show bgp summary
Groups: 2 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
lsdist.0
10 10 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.8.42.104 65534 24 17 0 70 6:43 Establ
lsdist.0: 10/10/10/0
10.255.105.137 65533 15 23 0 79 6:19 Establ
lsdist.0: 0/0/0/0의미
라우터 R0이 라우터 R1과 피어링됩니다.
MPLS LSP 상태 확인
목적
라우터 R0에서 MPLS LSP의 상태를 확인합니다.
작업
운영 모드에서 show mpls lsp 명령을 실행합니다.
user@R0> show mpls lsp Ingress LSP: 1 sessions To From State Rt P ActivePath LSPname 10.255.105.135 10.255.105.137 Up 0 * to-R3-inter-as Total 1 displayed, Up 1, Down 0 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0
의미
라우터 R0에서 라우터 R3으로의 MPLS LSP가 설정되었습니다.
lsdist.0 라우팅 테이블 항목 확인
목적
라우터 R0, R1 및 R2에서 lsdist.0 라우팅 테이블 항목을 확인합니다.
작업
운영 모드에서 show route table lsdist.0 명령을 실행합니다.
user@R0> show route table lsdist.0
lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
NODE { AS:65534 ISO:0102.5502.4211.00 ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
NODE { AS:65534 ISO:0102.5502.4250.00 ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
NODE { AS:65534 ISO:0102.5502.4250.02 ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
NODE { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 OSPF:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:8.42.1.104 } Remote { AS:65534 ISO:0102.5501.8181.00 }.{ IPv4:10.8.42.102 } ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.64.104 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:02:03, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4250.00 }.{ IPv4:10.8.64.106 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4211.00 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4250.00 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 }.{ IPv4:10. 8.42.104 } Remote { AS:65534 Area:0.0.0.0 IPv4:10.255.105.141 }.{ IPv4:10.8.42.102 } OSPF:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0운영 모드에서 show route table lsdist.0 명령을 실행합니다.
user@R1> show route table lsdist.0
lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
NODE { AS:65534 ISO:0102.5502.4211.00 ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
NODE { AS:65534 ISO:0102.5502.4250.00 ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
NODE { AS:65534 ISO:0102.5502.4250.02 ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
NODE { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 OSPF:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.42.104 } Remote { AS:65534 ISO:0102.5501.8181.00 }.{ IPv4:10.8.42.102 } ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.64.104 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:02:19, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4250.00 }.{ IPv4:10.8.64.106 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4211.00 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4250.00 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 }.{ IPv4:10.8.42.104 } Remote { AS:65534 Area:0.0.0.0 IPv4:10.255.105.141 }.{ IPv4:10.8.42.102 } OSPF:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0운영 모드에서 show route table lsdist.0 명령을 실행합니다.
user@R2> show route table lsdist.0
lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
NODE { AS:65534 ISO:0102.5502.4211.00 ISIS-L2:0 }/1152
*[IS-IS/18] 1d 00:24:39
Fictitious
NODE { AS:65534 ISO:0102.5502.4250.00 ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
NODE { AS:65534 ISO:0102.5502.4250.02 ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
NODE { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 OSPF:0 }/1152
*[OSPF/10] 1d 00:24:39
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.42.104 } Remote { AS:65534 ISO:0102.5501.8181.00 }.{ IPv4:10.8.42.102 } ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:58
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.64.104 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[IS-IS/18] 00:02:34
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4250.00 }.{ IPv4:10.8.64.106 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4211.00 }.{ } ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4250.00 }.{ } ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
LINK { Local { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 }.{ IPv4:10.8.42.104 } Remote { AS:65534 Area:0.0.0.0 IPv4:10.255.105.141 }.{ IPv4:10.8.42.102 } OSPF:0 }/1152
*[OSPF/10] 00:20:57
Fictitious의미
경로가 lsdist.0 라우팅 테이블에 나타납니다.
트래픽 엔지니어링 데이터베이스 항목 확인
목적
라우터 R0에서 트래픽 엔지니어링 데이터베이스 항목을 확인합니다.
작업
운영 모드에서 show ted database 명령을 실행합니다.
user@R0> show ted database
TED database: 5 ISIS nodes 5 INET nodes
ID Type Age(s) LnkIn LnkOut Protocol
0102.5501.8168.00(10.255.105.137) Rtr 1046 1 1 OSPF(0.0.0.0)
To: 10.8.31.101-1, Local: 10.8.31.101, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
0102.5501.8181.00 --- 1033 1 0
0102.5502.4211.00(10.255.105.139) Rtr 3519 2 3 Exported ISIS-L2(1)
To: 0102.5502.4250.02, Local: 10.8.64.104, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
To: 0102.5501.8181.00, Local: 10.8.42.104, Remote: 10.8.42.102
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
Exported OSPF(2)
To: 10.255.105.141, Local: 10.8.42.104, Remote: 10.8.42.102
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
0102.5502.4250.00(10.255.105.135) Rtr 1033 1 1 Exported ISIS-L2(1)
To: 0102.5502.4250.02, Local: 10.8.64.106, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
0102.5502.4250.02 Net 1033 2 2 Exported ISIS-L2(1)
To: 0102.5502.4211.00(10.255.105.139), Local: 0.0.0.0, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
To: 0102.5502.4250.00(10.255.105.135), Local: 0.0.0.0, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
10.8.31.101-1 Net 1046 2 2 OSPF(0.0.0.0)
To: 0102.5501.8168.00(10.255.105.137), Local: 0.0.0.0, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
To: 10.255.105.141, Local: 0.0.0.0, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
10.255.105.141 Rtr 1045 2 2 OSPF(0.0.0.0)
To: 0102.5502.4211.00(10.255.105.139), Local: 10.8.42.102, Remote: 10.8.42.104
Local interface index: 0, Remote interface index: 0
To: 10.8.31.101-1, Local: 10.8.31.103, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0의미
경로가 트래픽 엔지니어링 데이터베이스에 나타납니다.
BGP를 사용하는 link-state 배포 구성
처음에 IGP를 사용하여 획득한 link-state 정보를 전달하도록 BGP 프로토콜을 확장하여 여러 영역 및 AS(Autonomous System)에 토폴리지 정보를 배포할 수 있습니다. IGP 프로토콜은 대규모 데이터베이스를 배포하는 데 있어 확장 제한이 있습니다. BGP는 다중 영역 및 다중 AS 토폴로지 정보를 전달하기 위한 보다 확장 가능한 수단일 뿐만 아니라 다중 AS 토폴로지 배포에 유용할 수 있는 정책 제어를 제공합니다. BGP link-state 토폴로지 정보는 영역 간 TE LSP와 같은 여러 도메인에 걸친 MPLS LSP의 경로를 계산하고 ALTO 및 PCE와 같은 외부 경로 컴퓨팅 엔터티가 네트워크 토폴로지를 획득할 수 있도록 확장 가능하고 정책 제어된 수단을 제공하는 데 사용됩니다.
시작하기 전에:
디바이스 인터페이스를 구성합니다.
디바이스의 라우터 ID 및 AS(Autonomous System) 번호를 구성합니다.
다음과 같은 프로토콜을 구성합니다.
RSVP
MPLS
IS-IS
OSPF
BGP를 사용하여 link-state 배포를 활성화하려면:
BGP 클래스풀 전송 플레인 개요
- BGP 클래스풀 전송 플레인의 이점
- BGP 클래스풀 전송 플레인 용어
- BGP 클래스풀 전송 플레인 이해하기
- BGP 클래스풀 전송 플레인의 AS내 구현
- BGP 클래스 풀 전송 플레인의 AS 간 구현
- 기본 색상의 SR-TE 터널을 사용한 BGP 클래스풀 전송(BGP-CT) 개요
- 기본 색상의 SR-TE 터널을 사용한 BGP-CT의 이점
BGP 클래스풀 전송 플레인의 이점
-
네트워크 슬라이싱–서비스 계층과 전송 계층이 서로 분리되어 여러 도메인에 걸친 엔드 투 엔드 슬라이싱을 통해 네트워크 슬라이싱 및 가상화의 기반이 마련되므로 자본 비용이 크게 절감됩니다.
- 도메인 간 상호 운용성–각 도메인의 서로 다른 전송 신호 프로토콜이 상호 운용되도록 공동 운영 도메인 간에 전송 클래스 배치를 확장합니다. 각 도메인에서 사용 중인 확장 커뮤니티 네임스페이스 간의 차이를 조정합니다.
-
폴백이 있는 컬러 해상도-최상위 터널 또는 다른 컬러 터널에 대해 유연한 폴백 옵션을 사용하여 컬러 터널(RSVP, IS-IS 유연성 알고리즘)을 통한 해상도를 활성화합니다.
- 서비스 품질– 네트워크를 사용자 정의하고 최적화하여 엔드 투 엔드 SLA 요구사항을 충족합니다.
- 기존 구축 활용-RSVP와 같은 잘 구축된 터널링 프로토콜과 IS-IS 유연성 알고리즘과 같은 새로운 프로토콜을 지원하여 ROI를 유지하고 운영 비용을 절감합니다.
BGP 클래스풀 전송 플레인 용어
이 섹션에서는 BGP 클래스풀 전송 플레인을 이해하기 위해 일반적으로 사용되는 용어를 개괄적으로 설명합니다.
-
서비스 노드–서비스 경로(인터넷 및 계층 3 VPN)를 보내고 받는 PE(수신 공급자 에지) 디바이스입니다.
-
경계 노드–서로 다른 도메인(IGP 영역 또는 AS)의 연결 지점에 있는 디바이스입니다.
-
전송 노드 – BGP 레이블링 유니캐스트(LU) 경로를 보내고 받는 디바이스입니다.
-
BGP-VPN-RFC 4364 메커니즘을 사용하여 구축된 VPN입니다.
-
RT(Route Target)-VPN 구성원 자격을 정의하는 데 사용되는 확장 커뮤니티 유형입니다.
-
RD(Route Distinguisher)-경로가 속한 VPN 또는 VPLS(Virtual Private LAN Service)를 구별하는 데 사용되는 식별자입니다. 각 라우팅 인스턴스에는 고유한 경로 식별자가 연결되어 있어야 합니다.
- 해상도 체계-폴백을 제공하는 해상도 RIB에서 프로토콜 다음 홉 주소(PNH)를 해결하는 데 사용됩니다.
매핑 커뮤니티를 기반으로 시스템의 서로 다른 전송 RIB에 경로를 매핑합니다.
-
서비스 제품군-터널과는 반대로 데이터 트래픽에 대한 경로를 보급하는 데 사용되는 BGP 주소 제품군입니다.
-
전송 제품군-BGP 주소 패밀리는 터널을 보급하는 데 사용되며, 서비스 경로에 의해 해결됩니다.
-
전송 터널-서비스가 트래픽을 배치할 수 있는 터널(예: GRE, UDP, LDP, RSVP, SR-TE, BGP-LU)입니다.
-
터널 도메인– 서비스 노드 및 경계 노드를 포함하는 네트워크의 도메인으로, 이들 사이에 터널이 있습니다. 여러 인접 터널 도메인에 걸친 종단 간 터널은 레이블을 사용하여 노드를 함께 연결함으로써 생성될 수 있습니.
-
전송 클래스-동일한 유형의 서비스를 제공하는 전송 터널 그룹입니다.
전송 클래스 RT-특정 전송 클래스를 식별하는데 사용되는 새로운 형식의 경로 대상입니다.
특정 전송 클래스를 식별하는 데 사용되는 새 형식의 경로 대상입니다.-
트랜스포트 RIB–서비스 노드 및 경계 노드에서 트랜스포트 클래스는 터널 경로를 유지하는 연관된 트랜스포트 RIB를 가집니다.
-
전송 RTI–라우팅 인스턴스, 전송 RIB 컨테이너 및 관련 전송 클래스 RT(Route Target) 및 RD(Route Distinguisher)입니다.
-
전송 플레인– 동일한 전송 클래스 RT를 가져오는 전송 RTI의 집합입니다. 차례로 Inter-AS 옵션-b와 유사한 메커니즘을 사용하여 터널 도메인 경계를 가로질러 함께 연결되며, 경계 노드(다음 홉 자체)에서 레이블을 교환하여 종단 간 전송 평면을 형성합니다.
-
매핑 커뮤니티-전송 클래스를 통해 해결되도록 매핑되는 서비스 경로의 커뮤니티입니다.
BGP 클래스풀 전송 플레인 이해하기
BGP 클래스풀 전송 플레인을 사용하여 트래픽 엔지니어링 특성을 기반으로 AS 내 네트워크에서 전송 터널 집합을 분류하기 위한 전송 클래스를 구성하고 이러한 전송 터널을 사용하여 원하는 SLA 및 예상 폴백을 사용하여 서비스 경로를 매핑할 수 있습니다.
BGP 클래스풀 전송 플레인은 전송 클래스를 유지하면서 여러 도메인(AS 또는 IGP 영역)에 걸쳐 있는 도메인 간 네트워크로 이러한 터널을 확장할 수 있습니다. 이렇게 하려면 경계 노드와 서비스 노드 간에 BGP 클래스 풀 전송 전송 계층 BGP 패밀리를 구성해야 합니다.
Inter-AS 및 Intra-AS 구현 모두에서 서비스 및 보더 노드에서 생성된 많은 전송 터널(MPLS LSP, IS-IS 유연성 알고리즘, SR-TE)이 있을 수 있습니다. LSP는 서로 다른 도메인에서 서로 다른 신호 프로토콜을 사용하여 신호될 수 있으며, 서로 다른 트래픽 엔지니어링 특성(클래스 또는 색상)으로 구성될 수 있습니다. 전송 터널 엔드포인트는 서비스 엔드포인트 역할도 하며 서비스 수신 노드와 동일한 터널 도메인에 있거나 인접 또는 비인접 도메인에 있을 수 있습니다. BGP 클래스풀 전송 플레인을 사용하여 단일 도메인 내부 또는 여러 도메인에 걸쳐 특정 트래픽 엔지니어링 특성을 가진 LSP를 통해 서비스를 제거할 수 있습니다.
BGP 클래스풀 전송 플레인은 BGP-VPN 기술을 재사용하여 터널링 도메인을 느슨하게 결합하고 조정합니다.
- 네트워크 계층 도달 가능성 정보(NLRI)는 경로 숨기기에 사용되는 RD: 터널 엔드포인트입니다.
- 경로 대상은 LSP의 전송 클래스를 나타내며, 대상 장치의 해당 전송 RIB로 경로를 누출합니다.
- 모든 전송 터널링 프로토콜은 transport-class.inet.3 라우팅 테이블에 입력 경로를 설치하고 터널 전송 클래스를 VPN 경로 대상으로 모델링하고 transport-class.inet.3 transport-rib 라우팅 테이블에 동일한 전송 클래스의 LSP를 수집합니다.
-
이 라우팅 인스턴스의 경로는 RFC-4364와 유사한 절차에 따라 BGP 클래스 풀 전송 플레인(inet transport) AFI-SAFI에 보급됩니다.
-
Inter-AS 링크 경계를 넘을 때는 옵션-b 절차를 따라 이러한 인접 도메인의 전송 터널을 연결해야 합니다.
마찬가지로, AS 내 영역을 교차할 때 다른 TE 도메인에서 전송 터널을 연결하려면 옵션 b 절차를 따라야 합니다.
-
다양한 전송 클래스에 대한 의도를 폴백 순서로 지정하는 분해능 체계를 정의할 수 있습니다.
- 이러한 전송 클래스에 매핑 커뮤니티를 전송하여 서비스 경로 및 BGP 클래스 풀 전송 경로를 확인할 수 있습니다.
BGP 클래스풀 전송 패밀리는 BGP-LU 전송 레이어 패밀리와 함께 실행됩니다. BGP-LU를 실행하는 원활한 MPLS 네트워크에서 터널의 트래픽 엔지니어링 특성이 도메인 경계를 넘어 알려져 있거나 보존되지 않기 때문에 5G의 엄격한 SLA 요구 사항을 충족하는 것은 어려운 과제입니다. BGP 클래스풀 전송 플레인은 원활한 MPLS 아키텍처에서 전송 클래스 정보와 함께 원격 루프백에 대한 여러 경로를 보급하는 운영상 쉽고 확장 가능한 수단을 제공합니다. BGP 클래스풀 전송 제품군 경로에서는 전송 클래스 색상을 전달하는 전송 경로-대상 확장 커뮤니티를 사용하여 다양한 SLA 경로가 표현됩니다. 이 전송 경로 대상은 수신 BGP 라우터에서 BGP 클래스 풀 전송 경로를 적절한 전송 클래스와 연결하는 데 사용됩니다. BGP 클래스풀 전송 경로를 재보급할 때 MPLS는 경로를 스왑하고 동일한 전송 클래스의 AS 내 터널을 상호 연결하여 전송 클래스를 보존하는 종단 간 터널을 형성합니다.
BGP 클래스풀 전송 플레인의 AS내 구현
그림 4에서는 AS 내 도메인에 BGP 클래스 풀 전송 플레인을 구현하는 전후 시나리오를 사용한 네트워크 토폴로지를 보여 줍니다. 디바이스 PE11 및 PE12는 RSVP LSP를 전송 터널로 사용하며 모든 전송 터널 경로는 inet.3 RIB에 설치됩니다. BGP 클래스풀 전송 플레인을 구현하면 RSVP 전송 터널이 세그먼트 라우팅 터널과 유사하게 색상을 인식할 수 있습니다.
AS 내 설정에서 전송 터널을 BGP 전송 클래스로 분류하려면,
- 서비스 노드(입력 PE 장치)에서 전송 클래스를 정의하고(예: 골드 및 브론즈) 정의된 전송 클래스에 색상 커뮤니티 값을 할당합니다.
샘플 구성:
pe11# show routing-options route-distinguisher-id 172.16.1.1; transport-class { name gold { color 100; } name bronze { color 200; - 터널의 입력 노드에 있는 특정 전송 클래스에 전송 터널을 연결합니다.
샘플 구성:
pe11# show protocols mpls label-switched-path toPE12-bronze { transport-class bronze; } label-switched-path toPE12-gold { transport-class gold; }
AS BGP 내 클래스풀 전송 플레인 기능:
- BGP 클래스풀 전송은 명명된 전송 클래스(골드 및 브론즈)별로 미리 정의된 전송 RIB를 생성하고 색상 값(100 및 200)에서 매핑 커뮤니티를 자동으로 도출합니다.
- AS 내 전송 경로는 전송 클래스와 연결될 때 터널링 프로토콜에 의해 전송 RIB에 채워집니다.
이 예에서, RSVP감수성이 덜한 사람 노선 수송 부문 금(색 100)과 수송 부문 동메달(색 200)와 관련된 전송 RIB junos-rti-tc <100>.inet.3과 junos-rti-tc <200>.inet.3에 각각 설치되어 있습니다.
- 서비스 노드(입력 PE)는 사전 정의된 해상도 RIB에서 매핑 커뮤니티에 대한 서비스 경로의 확장 컬러 커뮤니티(color:0:100 및 color:0:200)를 일치시키고 해당 전송 RIB(junos-rti-tc- <100>.inet.3 또는 junos-rti-tc- <200>.inet.3)에서 프로토콜 다음 홉(PNH)을 해결합니다.
- BGP 경로는 연관된 매핑 커뮤니티를 전송하여 해상도 체계에 바인딩됩니다.
- 각 전송 클래스는 자동으로 두 개의 미리 정의된 해상도 체계를 만들고 매핑 커뮤니티를 자동으로 도출합니다.
한 가지 해결방안은 색: 0<val>을 매핑 커뮤니티로 사용하는 서비스 경로를 해결하는 것이다.
다른 해결방안은 운송-대상:0:<val>을 매핑 커뮤니티로 사용하는 수송로를 해결하는 것이다.
- 서비스 경로 PNH가 사전 정의된 해상도 체계에 나열된 RIB를 사용하여 해결될 수 없는 경우 inet.3 라우팅 테이블로 폴백할 수 있습니다.
- 또한 [edit routing-options resolution scheme] 구성 계층에서 사용자 정의 해상도 체계를 사용하여 서로 다른 색상의 전송 RIB 간에 폴백을 구성할 수 있습니다.
BGP 클래스 풀 전송 플레인의 AS 간 구현
AS 간 네트워크에서, BGP-LU는 모든 서비스 노드 또는 PE 장치 및 경계 노드(ABR 및 ASBR)에 최소 두 개의 전송 클래스(골드와 브론즈)를 구성한 후 BGP 클래스풀 전송 네트워크로 변환됩니다.
전송 터널을 BGP 클래스풀 전송으로 변환하려면,
- 서비스 노드(입력 PE 디바이스)와 경계 노드(ABR 및 ASBR)에서 전송 클래스를 정의합니다(예: 골드 및 브로즈).
샘플 구성:
pe11# show routing-options route-distinguisher-id 172.16.1.1; transport-class { name gold { color 100; } name bronze { color 200; - 터널의 입력 노드(입력 PE, ABR 및 ASBR)의 특정 전송 클래스에 전송 터널을 연결합니다.
샘플 구성:
RSVP LSP:
abr23# show protocols mpls label-switched-path toASBR21-bronze { transport-class bronze; } label-switched-path toASBR22-gold { transport-class gold;IS-IS 플렉서블 알고리즘:
asbr13# show routing-options flex-algorithm 128 { … color 100; use-transport-class; } flex-algorithm 129 { … color 200; use-transport-class; } - 네트워크에서 BGP 클래스 풀 전송(inet transport) 및 BGP-LU(inet labeled-unicast)에 대해 새 패밀리를 사용하도록 설정합니다.
샘플 구성:
abr23# show protocols bgp group toAs2-RR27 { family inet { labeled-unicast { … } transport { … } cluster 172.16.2.3; neighbor 172.16.2.7; } - 적절한 확장 컬러 커뮤니티를 사용하여 출력 PE 장치에서 서비스 경로를 보급합니다.
샘플 구성:
pe11# show policy-options policy-statement red term 1 { from { route-filter 192.168.3.3/32 exact; } then { community add map2gold; next-hop self; accept; } } term 2 { from { route-filter 192.168.33.33/32 exact; } then { community add map2bronze; next-hop self; accept; } } community map2bronze members color:0:200; community map2gold members color:0:100;
AS 내 BGP 클래스 풀 전송 플레인 기능:
- BGP 클래스풀 전송 평면은 명명된 전송 클래스(골드 및 브론즈)별로 미리 정의된 전송 RIB를 생성하고 색상 값에서 매핑 커뮤니티를 자동으로 도출합니다.
-
AS 내 전송 경로는 전송 클래스와 연결될 때 터널링 프로토콜을 통해 전송 RIB에 채워집니다.
예를 들어, 수송 등급의 금과 청동과 관련된 수송 터널 경로는 수송 RIBs <100>junos-rti-tc- .inet.3 및 junos-rti-tc- <200>.inet.33에 각각 설치됩니다.
- BGP 클래스풀 전송 플레인은 각 전송 RIB에서 bgp.transport.3 라우팅 테이블로 전송 터널 경로를 복사할 때 고유한 RD(Route Distinguisher) 및 RT(Route Target)를 사용합니다.
- BGP 세션에서 패밀리 인터넷 전송이 협상되는 경우 경계 노드는 bgp.transport.3 라우팅 테이블의 경로를 다른 도메인의 해당 피어에 알립니다.
- 수신 경계 노드는 이러한 bgp-ct 경로를 bgp.transport.3 라우팅 테이블에 설치하고 전송 경로 대상을 기준으로 이러한 경로를 적절한 전송 RIB로 복사합니다.
- 서비스 노드는 서비스 경로의 색상 커뮤니티를 해상도 체계에서 매핑 커뮤니티와 일치시키고 해당 전송 RIB(junos-rti-tc-<100> .inet.3 또는 junos-rti-tc-<200> .inet.3)에서 PNH를 해결합니다.
- 경계 노드는 전송 경로 PNH 해상도를 위해 미리 정의된 해상도 체계를 사용합니다.
- 사전 정의 또는 사용자 정의의 두 해상도 체계는 모두 서비스 경로 PNH 해상도를 지원합니다. 미리 정의된 et.3은 폴백으로 사용되며, 사용자 정의 해상도 체계는 PNH를 해결하는 동안 지정된 순서대로 전송 RIB 목록을 사용할 수 있게 합니다.
- 사용자 정의 해결 방식에 나열된 RIB를 사용하여 서비스 경로 PNH를 해결할 수 없는 경우 경로가 삭제됩니다.
기본 색상의 SR-TE 터널을 사용한 BGP 클래스풀 전송(BGP-CT) 개요
기본 색상의 SR-TE 터널을 사용한 BGP-CT의 이점
- 네트워크가 성장함에 따라 미래에 발생할 수 있는 확장 문제를 해결합니다.
- 서로 다른 기술을 사용하는 도메인에 상호 연결을 제공합니다.
- 서비스와 전송 계층을 분리하여 네트워크를 완전히 분산시킵니다.
- SR-TE용 도메인 내 트래픽 엔지니어링 컨트롤러를 통해 독립적인 대역폭 관리를 제공합니다.
지속적으로 성장하고 발전하는 대규모 네트워크에는 원활한 세그먼트 라우팅 아키텍처가 필요합니다. Junos OS 릴리스 21.2, R1부터는 컬러 SR-TE 터널로 기본 전송과 함께 BGP-CT를 지원합니다. BGP-CT는 전송 RIB를 사용하여 서비스 경로를 해결하고 다음 홉을 계산할 수 있습니다. BGP-CT를 통해 현재 지원되는 서비스는 경로 확인을 위해 기본 SR-TE 색 터널을 사용할 수도 있습니다. 이제 서비스는 정적 색 터널, BGP SR-TE, 프로그래밍 가능한 rpd 및 PCEP 색 터널과 같은 기본 SR-TE 색 터널을 사용할 수 있습니다. BGP-CT는 다음 홉 도달 가능성을 사용하여 원하는 전송 클래스를 통해 서비스 경로를 해결합니다.
기본 SR-TE 컬러 터널에서 BGP-CT 서비스 경로 확인을 활성화하려면 [edit protocols source-packet-routing] 계층 수준에서 use-transport-class문을 포함합니다.
use-transport-class문을[edit protocols source-packet-routing]계층 수준에서 활성화합니다.[edit routing-options transport-class]계층 수준의auto-create문을 함께 사용합니다.use-transport-class컬러 SR-TE와 이 기능이 있는 컬러 전용 SR-TE 터널에 대한 RIB 그룹을 지원하지 않습니다.
RSVP 경로 오류 메시지를 통한 트래픽 엔지니어링 데이터베이스 정확도 향상
RSVP 기반 트래픽 엔지니어링의 필수 요소는 트래픽 엔지니어링 데이터베이스입니다. 트래픽 엔지니어링 데이터베이스에는 트래픽 엔지니어링에 참여하는 모든 네트워크 노드 및 링크의 전체 목록과 각 링크가 보유할 수 있는 속성 집합이 포함되어 있습니다. (트래픽 엔지니어링 데이터베이스에 대한 자세한 내용은 제한 경로 LSP 계산을 참조하십시오.) 가장 중요한 링크 속성 중 하나는 대역폭입니다.
RSVP LSP가 설정 및 종료됨에 따라 링크의 대역폭 가용성이 빠르게 변경됩니다. 트래픽 엔지니어링 데이터베이스는 실제 네트워크와 관련하여 불일치를 가져올 가능성이 높습니다. 이러한 불일치는 IGP 업데이트 속도를 증가시켜 해결할 수 없습니다.
링크 가용성은 동일한 불일치 문제를 공유할 수 있습니다. 사용할 수 없는 링크로 기존의 모든 RSVP LSP가 중단될 수 있습니다. 그러나 네트워크에서는 이러한 가용성을 쉽게 알 수 없습니다.
rsvp-error-hold-time문을 구성하면 소스 노드(RSVP LSP의 입력)는 다운스트림 노드에서 전송된 PathErr 메시지를 모니터링하여 LSP의 장애로부터 학습합니다. PathErr 메시지의 정보는 후속 LSP 계산에 통합되어 LSP 설정의 정확성과 속도를 향상할 수 있습니다. 일부 PathErr 메시지는 트래픽 엔지니어링 데이터베이스 대역폭 정보를 업데이트하는 데에도 사용되며 트래픽 엔지니어링 데이터베이스와 네트워크 간의 불일치를 줄입니다.
update-threshold문을 사용하여 IGP 업데이트 빈도를 제어할 수 있습니다. 인터페이스에서 RSVP 업데이트 임계값 구성을 참조하십시오.
이 섹션은 다음 주제에 대해 설명합니다.
PathErr 메시지
PathErr 메시지는 다양한 코드와 서브코드 번호를 사용하여 다양한 문제를 보고합니다. RFC 2205, 리소스 예약 프로토콜(RSVP), 버전 1, 기능 사양 1 및 RFC 3209, RSVP-TE에서 다음과 같은 경로 오류 메시지의 전체 목록을 확인할 수 있습니다. LSP 터널용 RSVP 확장.
rsvp-error-hold-time문을 구성할 때, 링크 장애를 구체적으로 나타내는 두 가지 범주의 PathErr 메시지가 검사됩니다.
이 LSP에 대한 링크 대역폭이 낮습니다. 요청된 대역폭을 사용할 수 없음 - 코드 1, 하위 코드 2
이 유형의 PathErr 메시지는 링크를 통과하는 모든 LSP에 영향을 미치는 전역 문제를 나타냅니다. 이는 실제 링크 대역폭이 LSP가 요구하는 것보다 낮으며 트래픽 엔지니어링 데이터베이스의 대역폭 정보가 과대평가되었을 가능성이 있음을 나타냅니다.
이러한 유형의 오류가 수신되면 로컬 트래픽 엔지니어링 데이터베이스에서 사용 가능한 링크 대역폭이 감소하여 향후 모든 LSP 계산에 영향을 미칩니다.
이 LSP에 사용할 수 없는 링크:
승인 제어 오류—코드 1, 2를 제외한 모든 하위 코드
정책 제어 실패 - 코드 2
서비스 대체—코드 12
라우팅 문제—목적지에 사용할 수 있는 경로가 없음—코드 24, 하위 코드 5
이러한 유형의 PathErr 메시지는 일반적으로 지정된 LSP와 관련이 있습니다. 이 LSP의 실패가 다른 LSP도 실패할 수 있다는 것을 반드시 의미하는 것은 아닙니다. 이러한 오류는 MTU(최대 전송 유닛) 문제, 서비스 대체(운영자에 의해 수동으로 시작되거나 더 높은 우선 순위를 가진 다른 LSP에 의해 시작됨), 다음 홉 링크가 중단되었거나 넥스트홉 네이버가 중단되었거나 정책 고려 사항 때문에 서비스가 거부되었음을 나타낼 수 있습니다. 링크에서 이 특정 LSP를 라우팅하는 것이 가장 좋습니다.
문제 링크 식별
각 PathErr 메시지는 발신인의 IP 주소를 포함합니다. 이 정보는 변경되지 않고 수신 라우터에 전송됩니다. 트래픽 엔지니어링 데이터베이스의 조회는 PathErr 메시지를 생성한 노드를 식별할 수 있습니다.
각 PathErr 메시지는 메시지를 트리거한 RSVP 세션을 식별하기에 충분한 정보를 전달합니다. 중계 라우터인 경우 메시지를 전달하기만 하면 됩니다. 이 라우터가 수신 라우터인 경우(이 RSVP 세션의 경우) 모든 노드의 전체 목록과 세션이 통과해야 하는 링크가 있습니다. 링크는 발신 노드 정보와 결합하여 고유하게 식별될 수 있습니다.
트래픽 엔지니어링 데이터베이스 정확도 향상을 위한 라우터 구성
트래픽 엔지니어링 데이터베이스의 정확도를 높이려면 rsvp-error-hold-time문을 구성하십시오. 이 문이 구성되면 소스 노드(RSVP LSP의 입력)는 다운스트림 노드에서 전송된 PathErr 메시지를 모니터링하여 LSP의 장애로부터 학습합니다. PathErr 메시지의 정보는 후속 LSP 계산에 통합되어 LSP 설정의 정확성과 속도를 향상할 수 있습니다. 일부 PathErr 메시지는 트래픽 엔지니어링 데이터베이스 대역폭 정보를 업데이트하기 위해 사용되며 트래픽 엔지니어링 데이터베이스와 네트워크 간의 불일치를 줄입니다.
MPLS가 RSVP PathErr 메시지를 기억하고 CSPF 계산에서 이를 고려해야 하는 기간을 구성하려면, rsvp-error-hold-time문을 포함합니다.
rsvp-error-hold-time seconds;
다음 계층 수준에서 이 문을 포함시킬 수 있습니다:
[edit protocols mpls][edit logical-systems logical-system-name protocols mpls]
시간은 1~240초 사이의 값일 수 있습니다. 기본값은 25초입니다. 값을 0으로 설정하면 PathErr 메시지의 모니터링이 비활성화됩니다.
변경 내역 표
기능 지원은 사용 중인 플랫폼과 릴리스에 따라 결정됩니다. Feature Explorer 를 사용하여 플랫폼에서 기능이 지원되는지 확인하세요.