Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
이 페이지에서
 

기본 LSP 구성

LSP 메트릭 구성

LSP 메트릭은 특정 LSP를 통한 트래픽 전송의 용이성 또는 어려움을 나타내는 데 사용됩니다. LSP 메트릭 값이 낮을수록(낮은 비용) LSP가 사용될 가능성이 증가합니다. 반대로, 높은 LSP 메트릭 값(높은 비용)은 LSP가 사용될 가능성이 감소합니다.

LSP 메트릭은 라우터에 의해 동적으로 지정되거나 다음 섹션에서 설명하는 대로 사용자가 명시적으로 지정할 수 있습니다:

동적 LSP 메트릭 구성

특정 메트릭이 구성되지 않은 경우, LSP는 동일한 목적지(LSP의 to주소)를 향해 IGP 메트릭 추적을 시도합니다. IGP에는 최단 경로 우선(OSPF), IS-IS(Intermediate System to Intermediate System), RIP(Routing Information Protocol) 및 정적 경로가 포함됩니다. BGP 및 기타 RSVP 또는 LDP 경로는 제외됩니다.

예를 들어, 라우터에 대한 최단 경로 우선(OSPF) 메트릭이 20인 경우, 라우터에 대한 모든 LSP는 자동으로 메트릭 20을 상속합니다. 라우터에 대한 최단 경로 우선(OSPF)가 나중에 다른 값으로 변경되면 모든 LSP 메트릭이 그에 따라 변경됩니다. 라우터에 대한 IGP 경로가 없는 경우, LSP는 메트릭을 65,535로 높입니다.

이 경우, LSP 메트릭은 IGP에 의해 완전히 결정되며, LSP가 현재 통과하는 실제 경로와는 관계가 없습니다. LSP가 재라우팅되는 경우(재최적화를 통해), 해당 메트릭은 변경되지 않으므로 사용자에게 투명하게 유지됩니다. 동적 메트릭은 기본 동작이며 구성이 필요하지 않습니다.

정적 LSP 메트릭 구성

고정 메트릭 값을 LSP에 수동으로 할당할 수 있습니다. LSP 메트릭은 metric문으로 구성되면 고정이 되어 변경할 수 없습니다:

다음 계층 수준에서 이 문을 포함시킬 수 있습니다:

LSP 메트릭은 여러 가지 용도로 사용됩니다:

  • 동일한 송신 라우터를 가진 병렬 LSP가 있을 때, 메트릭을 비교하여 가장 낮은 메트릭 값(가장 낮은 비용)을 가진 LSP를 결정하고 목적지까지의 선호 경로를 결정합니다. 메트릭이 동일하면, 트래픽이 공유됩니다.

    메트릭 값을 조정하면 트래픽이 기본 IGP 메트릭에 관계없이 일부 LSP를 다른 LSP보다 선호하도록 할 수 있습니다.

  • IGP 바로 가기가 활성화된 경우(IGP 바로 가기를 계산을 위해 SPF를 확장하는 LSP를 사용 보기), LSP가 목적지까지의 최단 경로에 있는 경우 다음 홉으로 LSP를 사용하여 IGP 경로가 라우팅 테이블에 설치될 수 있습니다. 이런 경우, LSP 메트릭이 다른 IFP 메트릭에 추가되어 총 경로 메트릭을 결정합니다. 예를 들어, 수신 라우터가 X이고 송신 라우터가 Y인 LSP가 목적지 Z로 가는 최단 경로에 있는 경우, Y에서 Z로 가는 IGP 경로의 메트릭에 LSP 메트릭이 추가되어 경로의 총비용을 결정합니다. 여러 LSP가 잠재적인 다음 홉인 경우, 경로의 총 메트릭을 비교하여 선호되는 경로(즉, 전체 메트릭이 가장 낮은 경로)를 결정합니다. 또는, 동일한 목적지로 연결되는 IGP 경로와 LSP 메트릭 값을 사용하여 비교해 선호 경로를 결정할 수 있습니다.

    LSP 메트릭을 조정함으로써, 트래픽이 LSP를 선호하거나 IGP 경로를 선호하거나 그들 간에 로드를 공유하도록 할 수 있습니다.

  • 라우터 X와 Y가 BGP 피어이고 이들 사이에 LSP가 있는 경우, LSP 메트릭은 X에서 Y에 도달하는 데 필요한 총비용을 나타냅니다. 어떤 이유로든 LSP가 재루팅되는 경우, 기본 경로 비용은 크게 변경될 수 있지만, Y에 도달하는 X의 비용은 동일하게 유지되므로, X는 BGP MED(Multiple Exit Discriminator)를 통해 다운스트림 인접 라우터에 안정적인 메트릭을 보고할 수 있습니다. Y가 LSP를 통해 도달 가능한 상태로 유지되는 한 다운스트림 BGP 인접 라우터에는 변경 사항이 표시되지 않습니다.

[edit protocols isis traffic-engineering shortcuts]계층 레벨에서 ignore-lsp-metrics문을 포함함으로써 구성된 LSP 메트릭을 무시하도록 IS-IS(Intermediate System to Intermediate System)를 구성할 수 있습니다. 이 문은 경로 계산을 위해 IS-IS(Intermediate System to Intermediate System)와 MPLS 사이의 상호 의존성을 제거합니다. 자세한 내용은 라우팅 장치를 위한 Junos OS 라우팅 프로토콜 라이브러리 를 참조하십시오.

RSVP LSP 조건부 메트릭 구성

조건부 메트릭은 로컬 정적으로 구성된 LSPs(Label Switched Paths)에 대해 조건부로 다른 메트릭 값을 사용할 수 있는 기능을 제공합니다. 조건부 메트릭은 동적으로 변화하는 IGP 메트릭을 기반으로 합니다. Junos OS는 LSP 메트릭을 IGP 메트릭이 도달한 가장 높은 임계치에 해당하는 구성된 조건부 메트릭으로 변경합니다. 일치하는 조건이 없는 경우, LSP는 경로의 IGP 메트릭을 사용합니다. LSP에 대한 조건부 메트릭을 최대 4개를 구성할 수 있으며 정렬된 순서대로 구성됩니다.

조건부 메트릭 구성으로 track-igp-metric문을 구성하는 경우, Junos OS는 설치된 경로의 IGP 메트릭을 사용하여 구성된 조건부 메트릭을 평가합니다. 정적 메트릭은 조건부 메트릭과 함께 구성할 수 없습니다.

RSVP LSP 경로에서 IGP 메트릭 보존

conditional-metric 문을 사용하여 RSVP LSP를 구성할 때, 그 결과 메트릭은 LSP 대상에 대한 실제 IGP 메트릭과 다를 수 있습니다. RSVP는 이 조건부 메트릭을 경로의 메트릭으로 하여 LSP 수신 경로를 프로그래밍합니다. 그러나 특정 상황에서는 BGP MED 값 계산처럼 조건부 메트릭에서 사용되는 실제 IGP 메트릭을 나중에 사용하기 위해 보존해야 할 수도 있습니다.

conditional-metric문과 함께 include-igp-metric문을 사용하여 RSVP 경로에 IGP 메트릭 정보를 포함합니다.

show route protocol rsvp extensive 명령을 실행하여 업데이트된 실제 IGP 비용을 확인합니다.

주:

이것은 조건부 메트릭을 사용하는 RSVP 경로에만 적용됩니다. 동적 IGP를 사용하는 RSVP 경로는 기본적으로 IGP 메트릭을 포함합니다.

보다 자세한 정보는 include-igp-metric 구성 문을 참조하십시오.

LSP에 대한 텍스트 설명의 구성

인용 부호(" ")안에 공백을 포함하는 설명 텍스트를 첨부하여 LSP에 대한 텍스트 설명을 할 수 있습니다. 포함한 설명 텍스트는 show mpls lsp 또는 show mpls container-lsp명령어의 세부 정보 출력에 표시됩니다.

LSP에 대한 텍스트 설명을 추가해도 LSP의 작동에 아무런 영향을 미치지 않습니다. LSP 텍스트 설명의 문자 길이는 80자 이하여야 합니다.

LSP에 대한 텍스트 설명을 하려면, 다음 계층 수준 중 어느 하나에 description문을 포함시킵니다.

시작하기 전에:

  • 디바이스 인터페이스를 구성합니다.

  • 네트워크 통신 디바이스를 구성합니다.

  • 디바이스 인터페이스에 MPLS 활성화합니다.

  • MPLS 도메인에 LSP를 구성합니다.

LSP에 대한 텍스트 설명 추가

  1. LSP를 설명하는 텍스트를 입력합니다.

    예:

  2. 구성을 확인하고 커밋합니다.

    예:

  3. 구성된 LSP의 유형에 따라 show mpls lsp detail 또는 show mpls container-lsp detail명령어를 사용하여 LSP에 대한 설명을 봅니다.

MPLS 소프트 선점 구성

소프트 선점은 원래 LSP를 삭제하기 전에 선점된 LSP에 대해 새 경로를 설정하려고 합니다. 기본 동작은 먼저 선점된 LSP를 삭제하고, 새 경로를 신호로 전송한 다음, 새 경로를 통해 LSP를 다시 설정하는 것입니다. 경로가 중단되고 새 LSP가 설정되는 중간에 LSP를 사용하려는 모든 트래픽이 손실됩니다. 소프트 선점은 이러한 유형의 트래픽 손실을 방지합니다. 절충안은 LSP가 소프트 선점되는 동안 원래 경로가 삭제될 때까지 해당 대역폭 요구 사항을 가진 두 개의 LSP가 사용되는 것입니다.

MPLS 소프트 선점은 네트워크 유지에 도움이 됩니다. 예를 들어, 모든 LSP를 특정 인터페이스에서 멀리 보낸 다음, 트래픽을 중단하지 않고 유지 보수를 위해 인터페이스를 분리할 수 있습니다. MPLS 소프트 선점은 RFC 5712, MPLS 트래픽 엔지니어링 소프트 선점에 자세히 설명되어 있습니다.

소프트 선점은 LSP의 속성이며 기본적으로 비활성화됩니다. soft-preemption 문을 포함하여 LSP 수신 시 구성합니다.

다음 계층 수준에서 이 문을 포함시킬 수 있습니다:

또한 소프트 선점에 대한 타이머를 구성할 수도 있습니다. 타이머는 LSP의 하드 선점을 시작하기 전에 라우터가 대기해야 하는 기간을 지정합니다. 지정된 시간이 끝나면 LSP가 중단되어 Resignal됩니다. soft-preemption 정리 타이머의 기본 값은 30초이며, 허용 값의 범위는 0~180초입니다. 0의 값은 소프트 선점이 비활성화된다는 것을 의미합니다. soft-preemption 정리 타이머는 모든 LSP에 대해 전역으로 사용됩니다.

cleanup-timer 문을 포함하여 타이머를 구성합니다.

다음 계층 수준에서 이 문을 포함시킬 수 있습니다:

주:

소프트 선점은 Fast Reroute가 구성된 LSP에 구성될 수 없습니다. 구성이 커밋되지 않습니다. 그러나 노드 및 링크 보호와 함께 소프트 선점을 활성화할 수 있습니다.

주:

SoftPreemptionCnt에 대한 카운터 값은 0(제로) 값으로 초기화되며, show rsvp interface detail 명령 출력에 표시됩니다.

LSP의 우선 순위 및 선점 구성

더 중요한 LSP를 설정하는 데 대역폭이 충분하지 않은 경우, 덜 중요한 기존 LSP를 나눠서 대역폭에 여유분을 만들고 싶을 수 있습니다. 기존 LSP를 선점함으로써 이 작업을 수행합니다.

LSP가 선점될 수 있는지 여부는 LSP와 관련된 두 가지 특성에 의해 결정됩니다.

  • 우선 순위 설정 - 기존 LSP를 선점하는 새로운 LSP가 설정될 수 있는지 결정합니다. 선점이 발생하려면 새로운 LSP의 설정 우선 순위가 기존 LSP보다 더 높아야 합니다. 또한 기존 LSP를 선점하는 행위가 새로운 LSP를 지원하는 데 충분한 대역폭을 만들어야 합니다. 즉, 새로운 LSP가 성공적으로 설정될 수 있는 경우에만 선점이 발생합니다.

  • 예약 우선 순위 - LSP가 성공적으로 설정된 후 LSP가 세션 예약을 유지할 수 있는 정도를 결정합니다. 예약 우선 순위가 높으면 기존 LSP가 예약을 포기할 가능성이 적기 때문에 LSP가 선점될 수 없을 것입니다.

높은 설정 우선 순위와 낮은 예약 우선 순위를 가진 LSP를 구성할 수 없는 이유는 두 LSP가 서로 선점하도록 허용된다면 영원한 선점 루프로 이어질 것이기 때문입니다. 따라서 예약 우선 순위는 설정 우선 순위보다 크거나 같도록 구성해야 합니다.

또한 설정 우선 순위는 동일한 수신 라우터에서 LSP의 상대적 중요성을 정의합니다. 소프트웨어가 시작될 때, 새로운 LSP가 설정될 때 또는 오류 복구 중에는 설정 우선 순위가 LSP가 서비스되는 순서를 결정합니다. 높은 우선 순위 LSP는 먼저 설정되는 경향이 있으므로 최적의 경로 선택을 누릴 수 있습니다.

LSP의 선점 속성을 구성하기 위해 priority 문을 포함합니다.

이 명령문을 포함할 수 있는 계층 수준의 목록은 이 명령문에 대한 요약 섹션을 참조하십시오.

setup-priority 및 reservation-priority 둘 다 0에서 7까지의 값일 수 있습니다. 0 값은 가장 높은 우선 순위, 7 값은 가장 낮은 우선 순위에 해당합니다. 기본적으로 LSP는 7(즉, 다른 LSP를 선점할 수 없음)과 0(즉, 다른 LSP가 이를 선점할 수 없음)의 설정 우선 순위입니다. 이러한 기본 값에서는 선점이 일어나지 않습니다. 이러한 값을 구성할 때, 설정 우선 순위는 보류 우선 순위보다 작거나 같아야 합니다.

LSP의 관리 그룹 구성하기

링크 색상 또는 리소스 클래스라고도 하는 관리 그룹은 링크의 '색상'을 설명하는 수동으로 할당 된 속성으로, 같은 색상의 링크는 개념적으로 동일한 클래스에 속합니다. 관리 그룹을 사용하여 다양한 정책 기반 LSP 설정을 구현할 수 있습니다.

관리 그룹은 제약 경로 LSP 계산이 활성화되어 있을 때만 의미있습니다.

일련의 이름과 해당 값을 정의하는 최대 32개의 이름과 값을 지정(0~31 범위)할 수 있습니다. 관리 이름과 값은 단일 도메인 내의 모든 라우터마다 반드시 동일해야 합니다.

주:

관리 가치는 우선 순위와 다릅니다. priority 명령문을 사용해 LSP의 우선 순위를 구성합니다. LSP의 우선 순위 및 선점 구성하기를 참조하세요.

관리 그룹을 구성하기 위해 다음 단계를 따르세요.

  1. admin-groups 명령문을 포함하여 여러 수준의 서비스 품질을 다음과 같이 정의합니다.

    다음 계층 수준에서 이 문을 포함시킬 수 있습니다:

    • [edit protocols mpls]

    • [edit logical-systems logical-system-name protocols mpls]

    다음의 구성 예시는 도메인의 관리 이름과 값을 설정할 수 있는 방법을 보여줍니다.

  2. 인터페이스가 속한 관리 그룹을 정의합니다. 여러 그룹을 인터페이스에 할당할 수 있습니다. interface 명령문을 포함합니다.

    다음 계층 수준에서 이 문을 포함시킬 수 있습니다:

    • [edit protocols mpls]

    • [edit logical-systems logical-system-name protocols mpls]

    admin-group 명령문을 포함하지 않는 경우 인터페이스는 아무 그룹에도 속하지 않습니다.

    IGP는 그룹 정보를 사용하여 링크 상태 패킷을 구축하며, 이는 네트워크 전반에 플러딩 된 다음 네트워크의 모든 노드에게 정보를 제공합니다. 모든 라우터에서 IGP 토폴로지와 모든 링크의 관리 그룹이 가능합니다.

    인터페이스의 관리 그룹을 변경하는 것은 새로운 LSP에만 영향을 미칩니다. 인터페이스의 기존 LSP는 네트워크를 안정적으로 유지하기 위해 선점되거나 재계산되지 않습니다. 그룹 변경으로 LSP를 제거해야 하는 경우 clear rsvp session 명령을 실행합니다.

    주:

    링크에 대해 관리 그룹과 확장 관리 그룹을 함께 구성할 때 두 가지 유형의 관리 그룹을 모두 인터페이스에서 구성해야 합니다.

  3. 각 LSP 또는 각 기본이나 2차 LSP 경로에 대한 관리 그룹 제약 조건을 구성합니다. label-switched-path 명령문을 포함합니다.

    다음 계층 수준에서 label-switched-path 명령문을 포함시킬 수 있습니다.

    • [edit protocols mpls]

    • [edit logical-systems logical-system-name protocols mpls]

    include-all, include-any 또는 exclude 명령문을 생략하는 경우 경로 계산의 변경 없이 진행합니다. 경로 계산은 제약 된 경로 LSP 계산을 기반으로 합니다. 제약된 경로 LSP 계산이 어떻게 산출되는지에 대한 자세한 정보는 CSPF가 경로를 선택하는 방법을 참조하세요.

    주:

    LSP의 관리 그룹을 변경하면 경로의 즉각적인 재계산이 발생하므로 LSP가 다시 라우팅될 수 있습니다.

LSP에 대한 확장 관리 그룹 구성

MPLS 트래픽 엔지니어링에서 링크는 일련의 관리 그룹(색상 또는 리소스 클래스라고도 함)으로 구성될 수 있습니다. 관리 그룹은 각 링크에 할당된 32비트 값으로 내부 게이트웨이 프로토콜(IGP)(OSPFv2 및 IS-IS)로 전송됩니다. 주니퍼 네트웍스 라우터는 일반적으로 이 32비트 값을 각 비트가 그룹을 나타내는 비트 마스크로 해석하여 각 네트워크를 총 32개의 별개의 관리 그룹으로 제한합니다(값 범위 0 ~ 31).

32비트 값으로 표시되는 확장 관리 그룹을 구성하여 네트워크에서 지원되는 관리 그룹의 수를 32개 이상으로 확장할 수 있습니다. 이전 버전과의 호환성을 위해 관리 그룹에 사용할 수 있는 원래 값 범위가 여전히 지원됩니다.

확장 관리 그룹 구성은 해당 확장 관리 그룹 이름 집합이 있는 인터페이스 집합을 수락합니다. 이름을 32비트 값 집합으로 변환하고 이 정보를 IGP로 전송합니다. 확장된 관리 그룹 값은 전역적이며 네트워크에 참여하는 지원되는 모든 라우터에서 동일하게 구성되어야 합니다. IGP 플래딩을 통해 다른 라우터에서 학습된 도메인 전체 확장 관리 그룹 데이터베이스는 경로 계산을 위해 CSPF(Constrained Shortest Path First)에 의해 사용됩니다.

다음 절차에서는 확장 관리 그룹을 구성하는 방법을 설명합니다.

  1. admin-groups-extended-range문 구성:

    다음 계층 수준에서 이 문을 포함시킬 수 있습니다:

    • [edit routing-options]

    • [edit logical-systems logical-system-name routing-options]

    admin-groups-extended-range문은 minimum과(와) maximum 옵션을 포함합니다. 범위 최대값은 범위 최소값보다 커야 합니다.

  2. admin-groups-extended문 구성:

    다음 계층 수준에서 이 문을 포함시킬 수 있습니다:

    • [edit routing-options]

    • [edit logical-systems logical-system-name routing-options]

    admin-groups-extended문을 사용하면 관리 그룹의 그룹 이름과 그룹 값을 구성할 수 있습니다. 그룹 값은 admin-groups-extended-range 문을 사용하여 구성된 값의 범위 내에 있어야 합니다.

  3. MPLS 인터페이스의 확장 관리 그룹은 인터페이스에 할당된 확장 관리 그룹 이름 집합으로 구성됩니다. 글로벌 확장 관리 그룹에 대해 인터페이스 확장 관리 그룹 이름을 구성해야 합니다.

    MPLS 인터페이스에 대해 확장 관리 그룹을 구성하려면 admin-groups-extended 문을 사용하여 MPLS 인터페이스 구성 내에서 관리 그룹 이름을 지정합니다.

    다음 계층 수준에서 이 문을 포함시킬 수 있습니다:

    • [edit protocols mpls interface interface-name]

    • [edit logical-systems logical-system-name protocols mpls interface interface-name]

  4. LSP 확장 관리 그룹은 LSP와 경로의 기본 및 보조 경로에 대한 포함 및 제외 제약 조건 집합을 정의합니다. 전역 확장 관리 그룹에 대해 확장 관리 그룹 이름을 구성해야 합니다.

    LSP에 대한 확장 관리 그룹을 구성하려면 LSP 계층 수준에서 admin-group-extended 문을 포함합니다.

    admin-group-extended 문에는 다음과 같은 옵션이 포함됩니다. apply-groups, apply-groups-except, exclude, include-all 및 include-any. 각 옵션을 사용하여 하나 이상의 확장 관리 그룹을 구성할 수 있습니다.

    이 문을 구성할 수 있는 계층 수준 목록은 이 문의 문 요약을 참조하십시오.

  5. 현재 구성된 확장 관리 그룹을 표시하려면 show mpls admin-groups-extended 명령을 실행합니다.
주:

링크에 대해 관리 그룹과 확장 관리 그룹을 함께 구성할 때 두 가지 유형의 관리 그룹을 모두 인터페이스에서 구성해야 합니다.

LSP에 대한 선호 값 구성

옵션으로, 수신 및 송신 라우터의 동일한 쌍 사이에 여러 LSP를 구성할 수 있습니다. 이것은 기본적으로 모든 LSP가 동일한 선호 수준을 가지므로, LSP 사이의 부하를 분산하는 데 유용합니다. 하나의 LSP를 선호하려면, 개별 LSP에 대해 다른 선호 수준을 설정합니다. 선호 값이 가장 낮은 LSP를 사용합니다. 기본 선호 값은 RSVP LSP가 7, LDP LSP는 9입니다. 이러한 선호 값은 직접 인터페이스 경로를 제외한 모든 학습된 경로보다 낮습니다(더 선호).

기본 선호 값을 변경하려면, preference 문을 포함합니다:

이 명령문을 포함할 수 있는 계층 수준의 목록은 이 명령문에 대한 요약 섹션을 참조하십시오.

LSP에 의한 경로 루트 기록 비활성화

RSVP의 Junos 구현은 기록 루트 객체를 지원하며, 이는 LSP가 전송되는 라우터를 적극적으로 기록하도록 허용합니다. 문제 해결 및 라우팅 루프 방지에 이 정보를 사용할 수 있습니다. 기본적으로 경로 루트 정보가 기록됩니다. 기록을 비활성화하려면, no-record 문을 포함합니다:

record 및 no-record 문을 포함할 수 있는 계층 수준의 목록은 문에 대한 요약 섹션을 참조하십시오.

LSP를 위한 단절 전 채널 접속(MBB) 방식의 무중단 전환 실현하기

적응형 레이블 스위치 경로(LSP)는 기존 LSP 인스턴스를 삭제하기 전에 새 LSP 인스턴스를 설정하고 기존 LSP 인스턴스에서 새 LSP 인스턴스로 트래픽을 전송해야 할 수 있습니다. 이러한 유형의 구성을 단절 전 채널 접속(MBB)라고 합니다.

RSVP-TE는 MPLS 네트워크에서 LSP를 구축하는 데 사용되는 프로토콜입니다. 무중단(트래픽 손실 없음) MBB 전환을 실현하기 위한 RSVP-TE의 Junos OS 구현은 다음 구성 문에서 타이머 값을 구성하는 데 의존합니다.

  • optimize-switchover-delay—새 LSP 인스턴스로 전환하기 전에 대기해야 하는 시간.

  • optimize-hold-dead-delay—전환 이후 기존 LSP 인스턴스를 삭제하기 전에 대기해야 하는 시간.

optimize-switchover-delay 및 optimize-hold-dead-delay 문은 optimize-timer 문이 구성된 LSP뿐만 아니라 LSP 설정과 삭제를 위해 MBB 동작을 사용하는 모든 LSP에 적용됩니다. 다음 MPLS 기능을 통해 MBB 동작을 사용하여 LSP를 설정 및 삭제할 수 있습니다.

  • 적응형 LSP

  • 자동 대역폭 할당

  • LSP용 BFD

  • 그레이스풀 라우팅 엔진 스위치오버

  • 링크 및 노드 보호

  • NSR(Nonstop Active Routing)

  • 최적화된 LSP

  • P2MP(Point-to-multipoint) LSP

  • 소프트 선점

  • 대기 보조 경로

구성 시 optimize-switchover-delay 및 optimize-hold-dead-delay 문은 모두 MBB 프로세스에 인위적인 지연을 추가합니다. optimize-switchover-delay 문의 값은 ERO(Explicit Route Objects) 크기에 따라 다릅니다. ERO는 RSVP PATH 메시지가 기존의 최단 경로 IP 라우팅과 별도인 라우터의 명시적 시퀀스를 트래버스하도록 허용하는 RSVP에 대한 확장입니다. 또한 optimize-switchover-delay 문의 값은 경로에 있는 각 라우터의 CPU 사용량에 따라 다릅니다. 고객은 optimize-switchover-delay 문을 무작위 대입으로 설정합니다.

optimize-hold-dead-delay 문의 값은 수신 라우터가 새 LSP를 가리키도록 모든 애플리케이션 접두사를 이동시키는 속도에 따라 다릅니다. 이것은 플랫폼마다 다를 수 있는 패킷 전달 엔진 로드로 결정됩니다. 고객은 optimize-hold-dead-delay 문을 무작위 대입으로 설정해야 합니다.

하지만 릴리스 15.1부터 Junos OS는 이러한 타이머 값이 도입하는 인위적인 지연을 구성하기 않고 무중단 MBB 전환을 실현할 수 있습니다.

이 주제는 Junos OS를 사용하여 기존 LSP에서 새 LSP로 MBB 전환을 실현하는 3가지 방법에 대해 요약합니다.

라우터가 새 경로로 전환하기 위해 대기하는 시간 지정

새롭게 최적화된 경로로 LSP 인스턴스를 전환하기 위해 라우터가 대기하는 시간을 지정하려면 optimize-switchover-delay 문을 사용합니다. 영향을 받는 LSP의 수신 역할을 하는 라우터에서만 이 문을 구성해야 합니다. 전송 또는 송신 라우터에서 이 문을 구성할 필요는 없습니다. 이 문의 타이머는 트래픽이 이전 경로에서 전환되기 전에 최적화된 새 경로가 설정되었는지 확인하는 데 도움이 됩니다. 이 타이머는 라우터에서 구성된 모든 LSP에 대해 활성화 또는 비활성화만 가능합니다.

새롭게 최적화된 경로로 LSP 인스턴스를 전환하기 위해 라우터가 대기하는 시간을 구성하려면 optimize-switchover-delay 문을 사용하여 시간을 초 단위로 지정합니다.

다음 계층 수준에서 이 문을 포함시킬 수 있습니다:

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

이전 경로 삭제를 지연하기 위한 시간 지정

라우터가 트래픽을 최적화된 새 경로로 전환한 이후에 이전 경로가 삭제되는 것을 지연하는 시간을 지정하려면 optimize-hold-dead-delay 문을 사용합니다. 영향을 받는 LSP의 수신 역할을 하는 라우터에서만 이 문을 구성해야 합니다. 전송 또는 송신 라우터에서 이 문을 구성할 필요는 없습니다. 이 문의 타이머는 모든 라우팅이 최적화된 새 경로로 전환되기 전에 이전 경로가 삭제되지 않도록 하는 데 도움이 됩니다. 이 타이머는 특정 LSP 또는 라우터에서 구성된 모든 LSP에 대해 활성화할 수 있습니다.

라우터가 새롭게 최적화된 경로로 트래픽을 전환한 이후에 이전 경로가 삭제되는 것을 지연하기 위해 시간을 초 단위로 구성하려면 optimize-hold-dead-delay 문을 사용합니다.

이 명령문을 포함할 수 있는 계층 수준의 목록은 이 명령문에 대한 요약 섹션을 참조하십시오.

인위적인 지연 없이 무중단 MBB 전환 실현하기

Junos OS 릴리스 15.1부터 optimize-switchover-delay 또는 optimize-hold-dead-delay 문으로 설정된 임의의 시간 간격에 의존하지 않고 MBB 전환 이후 기존 LSP 인스턴스를 포기하는 또 다른 방법이 있습니다. 예를 들어 optimize-hold-dead-delay 문을 사용하는 경우, MBB 이후 기존 LSP 인스턴스를 삭제하기 전에 안전하다고 판단되는 대기 시간을 구성합니다. 그러나 여전히 일부 라우팅은 새 인스턴스로 이동하는 중일 수 있습니다. 기존 LSP 인스턴스를 너무 빨리 삭제하면 전송 노드 중 하나가 새 LSP 인스턴스로 이동하지 않은 해당 라우팅에 대한 트래픽을 삭제하게 됩니다.

트래픽 손실을 방지하려면 optimize-switchover-delay 문을 사용하는 대신 LSP 데이터 플레인이 종단 간 설정되었음을 확인하는 MPLS-OAM (lsp ping)을 사용할 수 있습니다. optimize-hold-dead-delay 문을 사용하는 대신 기존 LSP를 참조하는 모든 접두사가 전환되었음을 확인하는 rpd 인프라의 피드백 메커니즘을 사용할 수 있습니다. 피드백 메커니즘은 태그 라이브러리에서 소싱되고 MBB 전환 이후 기존 LSP 인스턴스를 사용하는 모든 라우팅이 새 LSP 인스턴스로 완전히 이동한 시점을 확인하기 위해 라우팅 프로토콜 프로세스(rpd) 인프라에 의존합니다.

피드백 메커니즘은 항상 준비가 되어 있으며 선택 사항입니다. MBB 전환 중에 피드백 메커니즘이 사용되도록 optimize-adaptive-teardown 문을 구성합니다. 이 기능은 RSVP P2MP(Point-to-multipoint) LSP 인스턴스에는 지원되지 않습니다. optimize-adaptive-teardown 문의 전역 구성은 시스템에서 구성된 지점 간 LSP에만 영향을 미칩니다.

영향을 받는 LSP의 수신 역할을 하는 라우터에서만 optimize-adaptive-teardown 문을 구성해야 합니다. 전송 또는 송신 라우터에서 이 문을 구성할 필요는 없습니다. 이 피드백 메커니즘은 모든 라우팅이 최적화된 새 경로로 전환되기 전에 기존 경로가 삭제되지 않도록 합니다. 이 구성 문의 전역 구성은 시스템에서 구성된 지점 간 LSP에만 영향을 미칩니다.

[edit protocols mpls] 계층 수준에서 이 문을 포함할 수 있습니다.

신호 LSP 최적화

LSP가 설정되면 시간이 지남에 따라 토폴로지 또는 리소스 변경으로 경로가 최적화되지 않을 수 있습니다. 혼잡도가 적고 메트릭이 낮으며 더 적은 홉을 통과하는 새 경로를 사용할 수 있게 되었을 수 있습니다. 라우터를 구성하여 경로를 주기적으로 재계산하여 보다 최적의 경로를 사용할 수 있는지 여부를 확인할 수 있습니다.

최적화가 설정된 경우 제한된 경로 재계산을 통해 LSP를 다른 경로를 통해 재라우팅할 수 있습니다. 그러나 최적화가 실행 중지된 경우 LSP에는 고정 경로가 있으므로 새로 사용할 수 있는 네트워크 리소스를 활용할 수 없습니다. LSP는 다음 토폴로지 변경 시 LSP가 중단되고 강제로 재계산될 때까지 고정됩니다.

최적화는 페일오버와 관련이 없습니다. 설정된 경로를 방해하는 토폴로지 오류가 발생할 경우 항상 새 경로가 계산됩니다.

시스템 오버헤드가 발생할 수 있으므로 최적화 빈도를 신중하게 제어해야 합니다. 최적화가 사용되도록 설정되면 네트워크 안정성이 저하될 수 있습니다. 기본적으로 optimize-timer문은 0으로 설정됩니다(즉, 비활성화됨).

LSP 최적화는 기본 동작인 제한된 경로 LSP 계산이 활성화된 경우에만 의미가 있습니다. 제한된 경로 LSP 계산에 대한 자세한 내용은 제한된 경로 LSP 계산 비활성화를 참조하십시오. 또한 LSP 최적화는 입력 LSP에만 적용 가능하므로 입력 라우터에서 optimize-timer문만 구성하면 됩니다. 전송 라우터와 출력 라우터는 LSP 최적화를 지원하기 위한 특정 구성이 필요하지 않습니다(MPLS를 사용하도록 설정하는 것 제외).

경로 최적화를 활성화하려면 optimize-timer문을 포함합니다.

이 명령문을 포함할 수 있는 계층 수준의 목록은 이 명령문에 대한 요약 섹션을 참조하십시오.

optimize-timer문을 구성했으면 구성에서 optimize-timer문을 삭제하더라도 최적화 타이머가 구성된 값으로 카운트다운을 계속합니다. 다음 최적화에서는 새 값이 사용됩니다. 이전 값을 삭제하고 구성을 커밋한 다음 optimize-timer문에 대한 새 값을 구성한 다음 구성을 다시 커밋하여 Junos OS가 새 값을 즉시 사용하도록 강제할 수 있습니다.

최적화가 실행된 후 다음 기준을 충족하는 경우에만 결과가 수락됩니다.

  1. IGP 메트릭에서 새 경로가 더 높지 않습니다. (이전 경로에 대한 메트릭은 계산 중에 업데이트되므로, 최근 링크 메트릭이 이전 경로를 따라 변경된 경우 해당 메트릭이 고려됩니다.)

  2. 새 경로에 동일한 IGP 메트릭이 있는 경우 더 이상 홉 떨어져 있지 않습니다.

  3. 새 경로는 선점을 유발하지 않습니다. (더 많은 선점을 유발하는 선점의 리플 효과를 감소시키기 위함입니다.)

  4. 새로운 경로는 전반적으로 혼잡을 악화시키지 않습니다.

    새 경로의 상대적인 혼잡은 다음과 같이 결정됩니다.

    1. 새 경로가 통과하는 각 링크에서 사용 가능한 대역폭의 백분율을 가장 혼잡한 링크에서 시작하여 이전 경로의 대역폭 백분율과 비교합니다.

    2. 소프트웨어는 각 현재(이전) 경로에 대해 오름차순으로 통과하는 링크의 대역폭 가용성에 대한 최소 4개의 값을 저장합니다.

    3. 소프트웨어는 또한 오름차순으로 통과한 링크에 해당하는 새 경로에 대한 최소 대역폭 가용성 값 4개를 저장합니다.

    4. 사용 가능한 4개의 새로운 대역폭 값 중 하나가 해당하는 이전 대역폭 가용성 값 중 하나보다 작은 경우, 새 경로에는 이전 경로에서 사용하는 링크보다 더 혼잡한 링크가 하나 이상 있습니다. 링크를 사용하면 더 많은 혼잡이 발생할 수 있으므로 트래픽이 이 새 경로로 전환되지 않습니다.

    5. 사용 가능한 4개의 새로운 대역폭 값 중 해당 이전 대역폭 가용성 값보다 작은 값이 없으면 새 경로가 이전 경로보다 덜 혼잡합니다.

위의 모든 조건이 충족되면 다음과 같이 됩니다.

  1. 새 경로에 더 낮은 IGP 메트릭이 있으면 허용됩니다.

  2. 새 경로에 동일한 IGP 메트릭이 있고 더 낮은 홉 카운트가 있으면 해당 경로가 허용됩니다.

  3. 로드 밸런싱 알고리즘으로 least-fill을(를) 선택하면 LSP는 다음과 같이 로드 밸런싱됩니다.

    1. LSP가 현재 경로보다 10% 이상 적게 사용되는 새 경로로 이동되었습니다. 이렇게 하면 현재 경로의 혼잡을 약간만 줄일 수 있습니다. 예를 들어 대역폭이 1MB인 LSP를 최소 200MB를 전송하는 경로에서 이동하면 원래 경로의 혼잡이 1% 미만으로 줄어듭니다.

    2. random 또는 most-fill 알고리즘의 경우, 이 규칙은 적용되지 않습니다.

    다음 예제에서는 least-fill 로드 밸런싱 알고리즘의 작동 방식을 보여 줍니다.

    그림 1: 최소 채우기 로드 밸런싱 알고리즘 예제최소 채우기 로드 밸런싱 알고리즘 예제

    그림 1에 나타난 바와 같이, LSP가 라우터 A에서 라우터 H로 통과할 수 있는 두 가지 잠재적 경로가 있습니다. 즉, L1에서 L13까지의 홀수 링크와 L2에서 L14까지의 짝수 링크입니다. 현재 라우터는 LSP의 활성 경로로 짝수 링크를 사용하고 있습니다. 동일한 두 라우터(예: 라우터 A와 라우터 B) 사이의 각 링크는 동일한 대역폭을 가집니다.

    • L1, L2 = 10GE

    • L3, L4 = 1GE

    • L5, L6 = 1GE

    • L7, L8 = 1GE

    • L9, L10 = 1GE

    • L11, L12 = 10GE

    • L13, L14 = 10GE

    1GE 링크는 혼잡할 가능성이 더 높습니다. 이 예에서 홀수 1GE 링크의 사용 가능한 대역폭은 다음과 같습니다.

    • L3 = 41%

    • L5 = 56%

    • L7 = 66%

    • L9 = 71%

    1GE 링크도 다음과 같은 대역폭을 사용할 수 있습니다.

    • L4 = 37%

    • L6 = 52%

    • L8 = 61%

    • L10 = 70%

    이 정보를 기반으로 라우터는 홀수 링크와 짝수 링크 사이의 사용 가능한 대역폭의 차이를 다음과 같이 계산합니다.

    • L4 - L3 = 41% - 37% = 4%

    • L6 - L5 = 56% - 52% = 4%

    • L8 - L7 = 66% - 61% = 5%

    • L10 - L9 = 71% - 70% = 1%

    홀수 링크에서 사용할 수 있는 총 추가 대역폭은 14%(4% + 4% + 5% + 1%)입니다. 14%가 10%(최소 채우기 알고리즘 최소 임계값)보다 크기 때문에, LSP는 짝수 링크를 사용하여 원래 경로에서 홀수 링크를 통해 새 경로로 이동됩니다.

  4. 그렇지 않으면 새 경로가 거부됩니다.

다음과 같은 최적화 기준(앞서 나열한 기준의 하위 집합)을 비활성화할 수 있습니다.

  • 새 경로에 동일한 IGP 메트릭이 있는 경우 더 이상 홉 떨어져 있지 않습니다.

  • 새 경로는 선점을 유발하지 않습니다. (더 많은 선점을 유발하는 선점의 리플 효과를 감소시키기 위함입니다.)

  • 새로운 경로는 전반적으로 혼잡을 악화시키지 않습니다.

  • 새 경로에 동일한 IGP 메트릭이 있고 더 낮은 홉 카운트가 있으면 해당 경로가 허용됩니다.

비활성화하려면 clear mpls lsp optimize-aggressive 명령을 실행하거나 optimize-aggressive문을 포함하십시오.

다음 계층 수준에서 이 문을 포함시킬 수 있습니다:

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

구성에 optimize-aggressive문을 포함하면 최적화 절차가 더 자주 트리거됩니다. 경로가 더 자주 재루팅됩니다. 또한 최적화 알고리즘을 IGP 메트릭으로만 제한합니다.

LSP를 위한 Smart Optimize Timer 구성

네트워크와 라우터 리소스 제약으로 인해 optimize timer에 대해 짧은 간격을 구성하는 것은 일반적으로 바람직하지 않습니다. 그러나 특정 상황에서는 optimize timer를 통해 일반적으로 제공하는 것보다 경로를 더 빠르게 다시 최적화하는 것이 바람직할 수 있습니다.

예를 들어 LSP는 이후에 실패하는 선호 경로를 트래버스합니다. 그런 다음 LSP는 동일한 대상에 도달하기 위해 덜 바람직한 경로로 전환합니다. 원래 경로가 신속하게 복원되더라도 optimize timer가 네트워크 경로를 다시 최적화할 때까지 기다려야 하므로 LSP가 해당 경로를 다시 사용하는 데 오랜 시간이 걸릴 수 있습니다. 이러한 상황에서 smart optimize timer를 구성하려고 할 수 있습니다.

smart optimize timer를 활성화하면 다운된 후 3분 이내에 원래 경로가 복원되는 한 LSP가 원래 경로로 다시 전환됩니다. 또한 원래 경로가 60분 이내에 다시 다운되면 smart optimize timer가 비활성화되고, optimize timer만 사용하도록 설정된 경우처럼 경로 최적화가 정상적으로 작동합니다. 이렇게 하면 라우터가 플래핑 링크를 사용할 수 없습니다.

smart optimize timer는 제대로 작동하기 위해 다른 MPLS 기능에 의존합니다. 원래 경로에서 오류가 발생할 경우 LSP가 대체 경로로 전환되는 이 시나리오의 경우, fast reroute, 링크 보호, 대기 보조 경로와 같은 MPLS 트래픽 보호 기능 중 하나 이상을 구성했다고 가정합니다. 이러한 기능은 트래픽이 오류 발생 시 대상에 도달할 수 있도록 하는 데 도움이 됩니다.

최소한 smart optimize timer 기능이 제대로 작동하려면 대기 보조 경로를 구성해야 합니다. Fast Reroute 및 링크 보호는 네트워크 가동 중단에 대한 보다 임시적인 솔루션입니다. 보조 경로는 기본 경로가 실패할 경우 안정적인 대체 경로가 있는지 확인합니다. LSP에 대한 어떤 종류의 트래픽 보호도 구성하지 않은 경우, smart optimize timer 자체는 트래픽이 해당 대상에 도달할 수 있도록 보장하지 않습니다. MPLS 트래픽 보호에 대한 자세한 내용은 MPLS 및 트래픽 보호를 참조하십시오.

기본 경로가 실패하고 smart optimize timer가 트래픽을 보조 경로로 전환하면 라우터는 기본 경로가 복원된 이후에도 보조 경로를 계속 사용할 수 있습니다. 수신 라우터가 CSPF 계산을 완료하면 보조 경로가 더 나은 경로인지 결정할 수 있습니다.

기본 경로가 활성 경로여야 하고 보조 경로를 백업용으로만 사용해야 하는 경우에는 바람직하지 않을 수 있습니다. 또한 (기본 경로가 다시 설정되었더라도) 보조 경로가 활성 경로로 사용되고 보조 경로가 실패한 경우, smart optimize timer 기능은 트래픽을 기본 경로로 자동 전환하지 않습니다. 그러나 노드 및 링크 보호 또는 추가 대기 보조 경로를 구성하여 보조 경로에 대한 보호 기능을 활성화할 수 있으며, 이때 smart optimize timer가 효과적일 수 있습니다.

smart-optimize-timer 명령문을 사용하여 smart optimize timer의 시간을 초 단위로 지정합니다.

주:

optimize-timer 명령문을 사용하여 주기적인 LSP를 다시 최적화하려는 경우에만 smart-optimize-timer 구성 명령문을 적용할 수 있습니다.

다음 계층 수준에서 이 명령문을 포함시킬 수 있습니다:

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

LSP에서 홉 수 제한

기본적으로 각 LSP는 수신 및 송신 라우터를 포함하여 최대 255개의 홉을 트래버스할 수 있습니다. 이 값을 수정하려면 hop-limit 문을 포함시킵니다:

이 명령문을 포함할 수 있는 계층 수준의 목록은 이 명령문에 대한 요약 섹션을 참조하십시오.

홉 수는 2~255입니다. (두 개의 홉을 가진 경로는 수신 및 송신 라우터로만 구성됩니다.)

LSP에 대한 대역폭 값 구성

각 LSP는 대역폭 값을 가지고 있습니다. 이 값은 RSVP 경로 설정 메시지에서 보낸 발신자의 Ttspec 필드에 포함됩니다. 초당 비트(bit)의 대역폭 값을 지정할 수 있습니다. LSP에 대한 더 많은 대역폭을 구성한다면 트래픽 양을 더 많이 운반할 수 있어야 합니다. 기본 대역폭은 초당 0비트입니다.

0이 아닌 대역폭은 전송 및 송신 라우터가 경로에 대한 아웃바운드 링크를 따라 용량을 예약해야 합니다. RSVP 예약 체계는 이 용량을 예약하는 데 사용됩니다. 대역폭 예약 실패 (RSVP 정책 제어 또는 승인 제어의 실패와 같은 경우) 때문에 LSP 설정이 실패할 수 있습니다. 전송 또는 송신 라우터의 인터페이스에 대한 대역폭이 충분하지 않은 경우 LSP가 설정되지 않습니다.

시그널링된 LSP에 대한 대역폭 값을 지정하는 경우, bandwidth문을 포함시킵니다:

이 명령문을 포함할 수 있는 계층 수준의 목록은 이 명령문에 대한 요약 섹션을 참조하십시오.

LSP에 대한 자동 대역폭 할당

자동 대역폭 할당을 통해 MPLS 터널은 터널을 따라 흐르는 트래픽 양을 기반으로 대역폭 할당을 자동으로 조정해줍니다. 최소 대역폭으로 LSP를 구성할 수 있으며, 이 기능을 통해 현재 트래픽 패턴에 따라 LSP의 대역폭 할당을 동적으로 조정할 수 있습니다. 대역폭 조정은 터널을 통해 트래픽 플로우를 방해하지 않습니다.

자동 대역폭 할당을 통해 구성된 LSP에서 샘플링 간격을 설정합니다. 이 간격 동안 평균 대역폭이 모니터링됩니다. 간격이 끝날 때, 이전 샘플링 간격의 최대 평균 값에 설정된 대역폭 할당을 사용해 LSP의 새로운 경로를 알리려는 시도가 발생합니다. 새로운 경로가 성공적으로 설정되어 원래 경로가 제거되면 LSP는 새로운 경로로 바뀝니다. 새로운 경로가 생성되지 않은 경우, LSP는 새로운 경로를 설정하려고 할 때 다음 샘플링 간격이 끝날 때까지 현재 경로를 계속 사용합니다. LSP의 최소 및 최대 대역폭 값을 설정할 수 있습니다.

자동 대역폭 할당 간격 동안 라우터는 LSP에서 트래픽(대역폭 사용률 증가)이 꾸준히 증가하여 잠재적인 혼잡 또는 패킷 손실을 일으킬 수 있습니다. 이를 방지하기 위해 현재 조정 간격이 끝나기 전에 자동 대역폭 조정 타이머를 조기에 만료하는 두 번째 트리거를 정의할 수 있습니다.

LSP에 대한 자동 대역폭 할당 구성하기

자동 대역폭 할당을 통해 MPLS 터널은 터널을 따라 흐르는 트래픽 양을 기반으로 대역폭 할당을 자동으로 조정해줍니다. 최소한의 대역폭으로 LSP를 구성할 수 있으며, 이 기능은 현재 트래픽 패턴에 따라 동적으로 LSP의 대역폭 할당을 조정할 수 있습니다. 대역폭 조정은 터널을 통해 트래픽 플로우를 방해하지 않습니다.

자동 대역폭 할당 시간 간격의 끝에서, 현재 최대 평균 대역폭 사용은 LSP에 대한 할당된 대역폭과 비교됩니다. LSP가 더 많은 대역폭이 필요한 경우, 대역폭은 현재 최대 평균 사용과 동일한 새로운 경로를 구성하기 위한 시도를 합니다. 시도가 성공하면, LSP의 트래픽은 새로운 경로를 통해 라우팅되며 오래된 경로는 제거됩니다. 시도가 실패하면, LSP는 현재 경로를 계속 사용합니다.

주:

Max AvgBW에 대한 값을 계산할 때(LSP 수신과 상대적인), MBB(make before break) 동안 수집된 샘플은 부정확한 결과를 방지하기 위해 무시됩니다. 대역폭 조정 후 첫 번째 샘플 또는 LSP ID의 변화 후(경로 변경과는 무관)는 또한 무시됩니다.

LSP에 대한 링크 및 노드 보호를 구성한 경우와 트래픽이 우회 LSP로 전환된 경우, 자동 대역폭 할당 기능은 계속 작동하고 우회 LSP에서 대역폭 샘플을 가져갑니다. 첫 번째 대역폭 조정 사이클의 경우, 원본 링크 및 노드 보호 LSP에서 가져온 최대 평균 대역폭 사용은 더 많은 대역폭이 필요한 경우 우회 LSP를 재신호하는데 사용됩니다. (링크 및 노드 보호는 QFX 시리즈 스위치 상에서 지원되지 않습니다.)

LSP에 대한 fast-reroute를 구성한 경우, 이 기능을 사용하여 대역폭을 조정하지 못할 수 있습니다. LSP는 고정 필터(FF) 예약 스타일을 사용하기 때문에 새로운 경로가 신호를 보내면 대역폭은 이중 카운팅 될 수 있습니다. 이중 카운팅은 자동 대역폭 할당을 사용할 때 fast-reroute LSP가 대역폭을 조정하지 못하게 할 수 있습니다. (Fast Reroute은 QFX 시리즈 스위치 상에서 지원되지 않습니다.)

자동 대역폭 할당을 구성하기 위해서는 다음의 섹션과 같이 단계를 완료하세요.

주:

QFX10000 스위치에서 edit protocols mpls 계층 수준에서 자동 대역폭 할당만 구성할 수 있습니다. 논리 시스템은 지원되지 않습니다.

MPLS LSP에 최적화된 자동 대역폭 조정 구성

자동 대역폭 기능의 사용으로 자동 메시를 사용해 직접 구성되거나 자동으로 생성된 RSVP-TE LSP가 트래픽 속도에 따라 크기를 조정할 수 있습니다. 각 LSP에 전달되는 트래픽 속도는 트래픽 속도의 샘플을 주기적으로 수집하여 측정됩니다. 트래픽 통계 수집 빈도는 set protocols mpls statistics interval구성 문을 통해 제어됩니다. LSP의 리사이징을 조정이라고 하며 조정 빈도는 adjust-interval문을 통해 제어됩니다. adjust-interval의 최소 구성 값은 1초입니다.

Junos OS 릴리스 20.4R1부터는 또는 adjust-threshold-underflow-limit문이 구성된 오버플로우 또는 언더플로우 임곗값을 교차하는 adjust-threshold-overflow-limit경우, 조정에 adjust-interval대한 최소 auto-bandwidth이 150초로 감소합니다.

그러나 오버플로우 또는 언더플로우 샘플이 검출되지 않을 경우 auto-bandwidth조정의 최소 adjust-interval은 300초입니다.

Junos OS 릴리스 20.4R1 이전에 출시된 릴리스에서 adjust-interval은(는) 오버플로우 또는 언더플로우 조건에서 300초입니다.

자동 대역폭 조정 최적화의 구현을 통해 auto-bandwidth은(는) LSP의 대역폭을 더 빠르게 감소시킵니다. 수신 레이블 에지 라우터(LER)는 이전 LSP 인스턴스 MBB(Make Before Break)의 분해가 150초 이내에 완료되는 경우 adjust-threshold-overflow-limit의 감소로 인해 150초 이내에 크기를 조정할 수 있습니다.

자동 대역폭 최적화를 위한 요구 사항은 다음과 같습니다:

  • LSP 경로 변경 확률 감소. 이는 자동 대역폭 조정이 발생할 때 LSP 경로가 변경될 확률을 줄이기 위한 것입니다.

  • LSP 재루팅 확률 감소. 이는 동일한 리소스를 요구하는 우선순위가 높은 LSP 때문에 LSP 재루팅의 확률을 줄이기 위한 것입니다.

이러한 요구 사항을 충족시키기 위해 자동 대역폭 조정 최적화는 다음을 지원합니다:

  1. In-place LSP Bandwidth Update: 도메인 내 LSP에서 대역폭을 변경할 때 수신 레이블 에지 라우터(LER)가 LSP ID를 재사용할 수 있도록 합니다.

    주:

    도메인 간 LSP에는 인플레이스 LSP 대역폭 업데이트가 적용되지 않습니다.

    특정 시나리오에서 LSP 경로 다음 홉은 직접 또는 간접적으로 LSP 대역폭을 전달합니다. 이러한 시나리오에서 인플레이스 LSP 대역폭 업데이트는 지원되지만 LSP 경로 변경으로 인해 기능에서의 성능 향상은 제한적입니다. 이는, 자동 대역폭(MPLS 터널) 이후 inet.3 경로 테이블의 변경 때문입니다. 예를 들어, 다음 중 하나 또는 둘 모두를 구성할 경우, 성능 향상이 제한됩니다:

    • MPLS에 따라 auto-policing이(가) 구성됩니다.

    • RSVP에 따라 load-balance구성된 문에 bandwidth따른 옵션 .

    주:

    다음과 같은 경우 LSP-ID 재사용을 통한 인플레이스 LSP 대역폭 업데이트가 실패하고 수신 LER가 즉시 새 LSP ID로 MBB를 트리거 합니다:

    • LSP에 대해 no-cspf이(가) 구성됩니다.

    • LSP는 PCE(Path Computation Element)에 의해 제어됩니다.

    • LSP 최적화 타이머가 작동합니다.

    • clear mpls lsp optimize-aggressive명령이 실행됩니다.

  2. Per-priority Subscription: 네트워크 리소스를 보다 효율적으로 활용하기 위해, 우선순위별 구독을 통해 우선순위가 낮은 LSP에 대해 더 낮은 RSVP 구독 비율을 구성하고 우선순위가 높은 LSP에 대해 더 높은 RSVP 구독 비율을 구성할 수 있습니다.

    예를 들어, 모든 우선순위의 LSP에 대해 RSVP 구독 비율을 90%로 설정하는 대신, 우선순위가 낮은 LSP에 대해 더 낮은 RSVP 구독 비율(예: 75%)을 구성할 수 있습니다

주:

우선순위별 구독은 DiffServ(Differentiated Services) 인식 트래픽 엔지니어링(TE)와 상호 운용되지 않습니다. DiffServ(Differentiated Services) 인식 트래픽 엔지니어링은 우선순위별 구독보다 트래픽 엔지니어링(TE) 링크 대역폭을 더 유연하고 통계적으로 공유합니다.

To Configure In-place LSP Auto-bandwidth Resizing:

  1. MPLS를 활성화하도록 디바이스 인터페이스를 구성합니다.
  2. 인터페이스에서 MPLS 프로토콜을 구성합니다.
  3. MPLS 및 LSP를 구성하고 LSP에 대한 링크 보호를 구성합니다.
  4. LSP에 대해 in-place-bandwidth-update을(를) 구성하여 자동 대역폭 LSP 크기 조정을 활성화합니다.
  5. 구성 모드에서 커밋을 입력하십시오.

Verification

구성 모드에서 show protocolsshow interfaces명령을 입력하여 구성을 확인합니다. 출력 결과가 의도한 구성대로 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정하십시오.

To Configure Per-priority Subscription:

  1. 인터페이스에서 RSVP 프로토콜을 구성합니다.

  2. 인터페이스의 대역폭 구독 값을 구성합니다. 0에서 65,000% 사이의 값이 될 수 있습니다. 기본 구독 값은 100%입니다.

  3. 인터페이스에서 구독 우선순위를 구성합니다.

  4. 우선순위에 대한 구독 비율을 구성합니다.

  5. 구성 모드에서 커밋을 입력하십시오.

Verification

구성 모드에서 show protocolsshow interfaces명령을 입력하여 구성을 확인합니다. 출력 결과가 의도한 구성대로 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정하십시오.

참조

LSP에 대한 자동 대역폭 할당 통계 구성

자동 대역폭 할당을 통해 MPLS 터널은 터널을 따라 흐르는 트래픽 양을 기반으로 대역폭 할당을 자동으로 조정해줍니다. 다음 단계를 완료하여 자동 대역폭 할당과 관련된 통계를 수집하도록 디바이스를 구성할 수 있습니다.

  1. 자동 대역폭 할당과 관련된 통계를 수집하려면 [edit protocols mpls] 계층 수준에서 statistics 명령문에 대한 auto-bandwidth 옵션을 구성합니다. 이러한 설정은 [edit protocols mpls label-switched-path label-switched-path-name] 계층 수준에서 auto-bandwidth 명령문을 구성한 라우터에 구성된 모든 LSP에 적용됩니다.
  2. file옵션을 사용하여 MPLS 추적 작업 출력을 저장하는 데 사용되는 파일에 filename을(를) 지정합니다. 모든 파일은 /var/log 디렉터리에 배치됩니다. MPLS 추적 출력을 mpls-log 파일에 배치하는 것을 권장합니다.
  3. files number 옵션을 사용하여 최대 추적 파일 수를 지정합니다. trace-file(으)로 지정된 추적 파일이 최대 크기에 도달하면 trace-file.0(으)로 이름이 바뀐 다음, trace-file.1(으)로 바뀌어 최대 추적 파일 수에 도달할 때까지 계속됩니다. 그런 다음 가장 오래된 추적 파일을 덮어씁니다.
  4. interval옵션을 사용하여 시간을 초 단위로 구성하여 평균 대역폭 사용을 계산하는 간격을 지정합니다. 또한 [edit protocols mpls label-switch-path label-switched-path-name statistics] 계층 수준에서 interval 옵션을 구성하여 특정 LSP에서 조정 간격을 설정할 수 있습니다.
    주:

    LSP의 불필요한 재신호를 방지하기 위해 MPLS 자동 대역폭 통계 간격보다 최소 3배 긴 LSP 조정 간격을 구성하는 것이 좋습니다. 예를 들어, MPLS 자동 대역폭 통계 간격([edit protocols mpls statistics] 계층 수준에서 interval 명령문)에 대해 30초의 값을 구성한 경우, LSP 조정 간격([edit protocols mpls label-switched-path label-switched-path-name auto-bandwidth] 계층 수준에서 adjust-interval 명령문)에 대해 90초 이상의 값을 구성해야 합니다.

  5. 자동 대역폭 할당을 추적하려면 [edit protocols mpls] 계층 수준에서 MPLS traceoptions 명령문에 autobw-stateflag을(를) 포함합니다.

    다음 구성으로 자동 대역폭 할당을 위한 MPLS 추적 옵션을 활성화합니다. 추적 기록은 auto-band-trace이라는 파일에 저장됩니다(파일명은 사용자 구성 가능).

  6. show log 명령어를 사용하여 auto-bandwidth (MPLS Statistics) 명령문을 구성할 때 생성되는 자동 대역폭 할당 통계 파일을 표시할 수 있습니다. 다음은 E-D이라는 이름의 LSP로 구성된 라우터의 MPLS 통계 파일 auto-band-stats에서 가져온 기록 파일 출력 예시를 보여 줍니다. 기록 파일은 LSP E-D이 처음에 예약한 대역폭 제한을 초과해 작동한다는 것을 보여줍니다. Oct 30 17:14:57이전에 라우터는 자동 대역폭 조정을 촉발시켰습니다(자동 대역폭 조정을 받는 LSP에 대해 두 개의 session을 볼 수 있습니다). Oct 30 17:16:57에 의해 LSP는 더 높은 대역폭으로 재설정되었으며, 현재 Reserved Bw(예약 대역폭)의 100% 미만을 사용하는 것으로 표시됩니다.
  7. show mpls lsp autobandwidth 명령어를 실행해 자동 대역폭 할당에 대한 현재 정보를 표시합니다. 다음은 이전에 표시된 기록 파일과 거의 동시에 실행된 show mpls lsp autobandwidth 명령어의 출력 예시입니다.
  8. MPLS 추적 파일을 표시하려면 file show 명령어를 실행합니다. 파일 위치 및 파일 이름을 지정해야 합니다(파일은 /var/log/에 있습니다). 다음은 E-D이라는 이름의 LSP로 구성된 라우터에 있는 MPLS 추적 파일 auto-band-trace.0.gz에서 출력되는 샘플 추적 파일을 보여줍니다. 추적 파일은 LSP E-D이 처음에 예약한 대역폭 제한을 초과해 작동한다는 것을 보여줍니다. Oct 30 17:15:26에서 라우터는 자동 대역폭 조정을 촉발시킵니다(자동 대역폭 조정을 받는 LSP에 대해 두 개의 session을 볼 수 있습니다). Oct 30 17:15:57에 의해 LSP는 더 높은 대역폭으로 재설정되었으며, 현재 Reserved Bw(예약 대역폭)의 100% 미만을 사용하는 것으로 표시됩니다.

AS에 걸쳐 LSP 구성

LSP 구성의 일부로 inter-domain문을 포함하여 네트워크의 여러 영역을 가로지르도록 LSP를 구성할 수 있습니다. 이 명령문을 이용하면 라우터가 IGP 데이터베이스에서 경로를 검색할 수 있습니다. 경로를 찾지 못할 수 있는 라우터에서는 (TED(트래픽 엔지니어링 데이터베이스)를 참조하여) 도메인 내 CSPF를 사용하여 이 명령문을 구성해야 합니다 영역 간 LSP를 구성할 때는 inter-domain문이 필요합니다.

시작하기 전에:

  • 제품군 MPLS로 디바이스 인터페이스를 구성합니다.

  • 디바이스 라우터 ID 및 자율 시스템(AS) 번호를 구성합니다.

  • 라우터 및 전송 인터페이스에 MPLS 및 RSVP를 활성화합니다.

  • 트래픽 엔지니어링 지원을 위해 IGP를 구성합니다.

  • 수신 라우터에서 송신 라우터로 LSP를 구성합니다.

수신 레이블 스위치 라우터 (LER)의 여러 AS에 걸쳐 LSP 구성

  1. 모든 인터페이스에 MPLS (관리 인터페이스를 제외)를 활성화합니다.
  2. 모든 인터페이스에 RSVP(관리 인터페이스를 제외)를 활성화합니다
  3. 영역 간 LSP를 구성합니다.
  4. 구성을 확인하고 커밋합니다.

LSP 상태 변경의 댐핑 통보

LSP가 업에서 다운으로 또는 다운에서 업으로 변경되면 이 전환은 라우터 소프트웨어 및 하드웨어에서 바로 적용됩니다. 그러나 LSP를 IS-IS(Intermediate System to Intermediate System) 및 최단 경로 우선(OSPF) 으로 통보할 때 LSP 전환을 댐핑하여 특정 기간(보류 시간이라고 함)이 발생할 때까지 전환을 통보하지 않을 수 있습니다. 이 경우 LSP가 업에서 다운으로 이동하면 LSP가 보류 시간 기간 동안 다운을 유지할 때까지 LSP가 다운된 것으로 통보되지 않습니다. 다운에서 업으로 전환은 즉시 IS-IS(Intermediate System to Intermediate System) 및 최단 경로 우선(OSPF)에 통보됩니다. LSP 댐핑은 LSP의 IS-IS(Intermediate System to Intermediate System) 및 최단 경로 우선(OSPF) 통보에만 영향을 미친다는 점에 유의하세요. 다른 소프트웨어 및 하드웨어는 LSP 전환에 즉시 반응합니다.

LSP 전환을 댐핑하려면, advertisement-hold-time문을 포함합니다:

seconds은(는) 0~65,535초 사이의 값이 될 수 있습니다. 기본값은 5초입니다.

다음 계층 수준에서 이 문을 포함시킬 수 있습니다:

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

공동 라우팅 된 양방향 LSP 구성

공동 라우팅 된 양방향 LSP는 그림 2에서 보이는 것과 같이 한 쌍의 수신 및 송신 노드 간에 동일한 경로를 공유하는 두 LSP의 조합입니다. 이는 RSVP-TE에 대한 GMPLS 확장을 사용하여 설정됩니다. 이러한 유형의 LSP는 Layer 2 VPN, Layer 2 회로 및 Layer 3 VPN을 포함하여 모든 표준 유형의 MPLS 기반 트래픽을 전송하는 데 사용될 수 있습니다. 양방향 LSP에 대한 단일 BFD 세션을 구성할 수 있습니다(각 방향의 각 LSP에 대한 BFD 세션을 구성할 필요는 없습니다). 또한 단일 대기 양방향 LSP를 구성하여 기본 양방향 LSP에 대한 백업을 제공할 수 있습니다. 공동 라우팅 된 양방향 LSP는 penultimate hop popping(PHP) 및 ultimate hop popping(UHP) 모두 지원됩니다.

양방향 LSP에는 고가용성을 사용할 수 있습니다. Graceful restart 및 nonstop active routing을 활성화할 수 있습니다. 재시작 라우터가 양방향 LSP의 수신, 송신, 또는 트랜싯 라우터인 경우 graceful restart 및 nonstop active routing이 지원됩니다.

그림 2: 공동 라우팅 된 양방향 LSP공동 라우팅 된 양방향 LSP

공동 라우팅 된 양방향 LSP를 구성하려면:

  1. 구성 모드에서 LSP에 대한 수신 라우터 구성하고 corouted-bidirectional 명령문을 포함시켜 LSP가 공동 라우팅 된 양방향 LSP로 설정되도록 지정합니다.

    경로는 CSPF를 사용하여 계산되고 RSVP 신호를 사용하여 시작됩니다(단방향 RSVP 신호 LSP와 같이). 이 구성이 커밋될 때 송신 라우터에 대한 경로 및 송신 라우터의 역방향 경로 모두가 생성됩니다.

  2. (선택사항) 역방향 경로의 경우, 송신 라우터에서 LSP를 구성하고 LSP를 다른 LSP와 연결하는 corouted-bidirectional-passive 명령문을 포함합니다.

    이 LSP는 수신 LSP에서 제공하는 경로 계산 및 신호에 의존하기 때문에 경로 계산 또는 신호가 사용되지 않습니다. corouted-bidirectional 명령문과 corouted-bidirectional-passive 명령문을 모두 동일한 LSP에 구성할 수 없습니다.

    또한 이 명령문을 통해 라우팅 된 양방향 LSP를 보다 쉽게 디버그할 수 있습니다. corouted-bidirectional-passive 명령문(송신 라우터에서)을 구성하는 경우, ping mpls lsp-end-point, ping mpls ldp, ping mpls rsvp, traceroute mpls ldp 및 traceroute mpls rsvp 명령문을 실행해 송신 라우터에서 공동 라우팅 된 양방향 LSP를 테스트할 수 있습니다.

  3. show mpls lsp extensive 및 show rsvp session extensive 명령어를 사용하여 양방향 LSP에 대한 정보를 표시합니다.

    다음은 양방향 LSP가 구성된 수신 라우터에서 실행될 때 show rsvp session extensive 명령어에 대한 출력을 보여줍니다.

LSP에 대한 엔트로피 레이블 구성

LSP에 엔트로피 레이블을 삽입하면 전송 라우터가 심층 패킷 검사에 의존하지 않고도 MPLS 레이블 스택을 해시 입력으로 사용하여 ECMP 경로 또는 링크 어그리게이션 그룹에 걸쳐 MPLS 트래픽의 부하를 분산할 수 있습니다. 심층 패킷 검사에는 더 많은 라우터의 처리 능력이 필요하며 라우터마다 심층 패킷 검사 기능이 다릅니다.

LSP에 대해 엔트로피 레이블을 구성하려면 다음 단계를 수행합니다.

  1. 수신 라우터에서 [edit protocols mpls labeled-switched-path labeled-switched-path-name] 계층 수준 또는 [edit protocols mpls static-labeled-switched-path labeled-switched-path-name ingress] 계층 수준에 entropy-label 문을 포함합니다. 엔트로피 레이블은 MPLS 레이블 스택에 추가되며 포워딩 플레인에서 처리될 수 있습니다.
    주:

    이는 RSVP 및 정적 LSP에만 적용됩니다.

  2. 수신 라우터에서 LDP 신호 LSP에 대한 수신 정책을 구성할 수 있습니다.

    [edit policy-options] 계층 수준에서 수신 정책을 구성합니다.

    다음은 엔트로피 레이블 수신 정책의 예를 보여줍니다.

  3. (선택 사항) 기본적으로 엔트로피 레이블의 푸시 및 팝핑을 지원하는 라우터는 [edit forwarding-options] 계층 수준에서 load-balance-label-capability 문을 사용하여 LSP별로 레이블을 전송하도록 구성합니다. 피어 라우터가 부하 분산 레이블을 처리할 수 없는 경우 [edit forwarding-options] 계층 수준에서 no-load-balance-label-capability 문을 구성하여 PE(provider edge) 라우터가 엔트로피 레이블 기능을 전송하는 것을 방지할 수 있습니다.

전송 라우터는 구성이 필요하지 않습니다. 엔트로피 레이블이 존재하면 전송 라우터가 MPLS 레이블 스택만을 기반으로 부하 분산을 수행함을 나타냅니다.

끝에서 두 번째 홉 라우터는 기본적으로 엔트로피 레이블을 팝핑합니다.

예: BGP Labeled Unicast에 대한 엔트로피 레이블 구성

이 예는 엔트로피 레이블을 사용하여 종단 간 로드 밸런싱을 달성할 수 있도록 BGP labeled unicast에 엔트로피 레이블을 구성하는 방법에 대해 보여줍니다. IP 패킷에 목적지에 도달하는 경로가 여러 개 있는 경우 Junos OS는 패킷 헤더의 특정 필드를 사용하여 패킷을 확정적 경로에 해시합니다. 이를 위해서는 flow 정보를 전달할 수 있는 특수한 로드 밸런싱 레이블인 엔트로피 레이블이 필요합니다. 코어의 LSR은 엔트로피 레이블을 키로 사용하여 패킷을 올바른 경로로 해시합니다. 엔트로피 레이블은 16~1048575(정규 20비트 레이블 범위) 사이의 레이블 값일 수 있습니다. 이 범위는 기존의 정규 레이블 범위와 겹치기 때문에 엔트로피 레이블 앞에 엔트로피 레이블 표시기(ELI)라는 특수 레이블을 삽입합니다. ELI는 IANA가 지정했으며, 값이 7인 특수 레이블입니다.

BGP labeled unicast는 일반적으로 여러 IGP 영역 또는 여러 AS(Autonomous System)에 걸쳐 RSVP 또는 LDP LSP를 연결합니다. RSVP 또는 LDP 엔트로피 레이블은 RSVP 또는 LDP 레이블과 함께 두 번째 최종 홉 노드에서 표시됩니다. 이 기능을 사용하면 BGP 트래픽에 대해 종단 간 엔트로피 레이블 로드 밸런싱을 달성하기 위해서 연결 지점에서 엔트로피 레이블을 사용하여 두 번째 홉 노트와 연결 지점 사이의 공백을 메울 수 있습니다.

요구 사항

이 예에서 사용되는 하드웨어 및 소프트웨어 구성 요소는 다음과 같습니다.

  • MPC가 있는 MX 시리즈 라우터 7개

  • 모든 디바이스에서 Junos OS 릴리스 15.1 이상 실행

    • Junos OS 릴리스 22.4를 사용하여 재검증됨

BGP labeled unicast에 대한 엔트로피 레이블을 구성하기 전에 다음을 확인하십시오.

  1. 디바이스 인터페이스를 구성합니다.

  2. OSPF 또는 기타 IGP 프로토콜을 구성합니다.

  3. BGP를 구성합니다.

  4. RSVP를 구성합니다.

  5. MPLS를 구성합니다.

개요

BGP labeled unicast가 여러 IGP 영역이나 AS(Autonomous System)에서 RSVP 또는 LDP LSP를 연결하면 RSVP 또는 LDP 엔트로피 레이블이 RSVP 또는 LDP 레이블과 함께 두 번째 홉 노드에 표시됩니다. 그러나 연결 지점, 즉 두 영역 사이의 라우터에는 엔트로피 레이블이 없습니다. 따라서 연결 지점의 라우터는 BGP 레이블을 사용하여 패킷을 전달할 수 있습니다.

Junos OS 릴리스 15.1부터 BGP labeled unicast에 엔트로피 레이블을 구성하여 종단 간 엔트로피 레이블 로드 밸런싱을 달성할 수 있습니다. 이 기능을 사용하면 BGP 트래픽에 대한 종단 간 엔트로피 레이블 로드 밸런싱을 달성하기 위해 연결 지점에서 엔트로피 레이블을 사용할 수 있습니다. Junos OS를 통해 BGP labeled unicast LSP 수신 시 엔트로피 레이블을 삽입할 수 있습니다.

기본적으로, 엔트로피 레이블을 지원하는 라우터는 [edit forwarding-options]계층 수준에서 load-balance-label-capability문으로 구성되어 LSP 기준으로 레이블에 신호를 보낼 수 있습니다. 피어 라우터에 로드 밸런싱 레이블을 처리할 수 있는 장치가 없는 경우 [edit forwarding-options]계층 수준에서 no-load-balance-label-capability을 구성하여 엔트로피 레이블 기능의 신호 전송을 방지할 수 있습니다.

주:

[edit policy-options policy-statement policy name then]계층 수준에서 no-entropy-label-capability옵션을 사용하여 정책에 지정된 경로에 대해 송신될 때 엔트로피 레이블 보급 기능을 명시적으로 비활성화할 수 있습니다.

토폴로지

그림 3에서 라우터 PE1은 수신 라우터, 라우터 PE2는 송신 라우터입니다. 라우터 P1과 P2는 전송 라우터입니다. 라우터 ABR은 영역 0과 영역 1 사이의 영역 브리지 라우터입니다. 두 개의 LSP는 트래픽 로드 밸런싱을 위해 ABR에서 PE2로 구성됩니다. BGP labeled unicast에 대한 엔트로피 레이블 기능은 수신 라우터 PE1에서 활성화됩니다. 호스트 1은 패킷 캡처를 위해 P1에 연결되어 있어 엔트로피 레이블을 표시할 수 있습니다.

그림 3: BGP labeled unicast에 대한 엔트로피 레이블 구성BGP labeled unicast에 대한 엔트로피 레이블 구성

구성

CLI 빠른 구성

이 예를 빠르게 구성하려면, 아래 명령을 복사하여 텍스트 파일로 붙여 넣은 다음 모든 라인브레이크를 제거하고, 네트워크 구성을 일치하는 데 필요한 세부 사항을 바꾸고 [edit] 계층 수준에서 명령을 CLI로 복사해 붙여 넣은 다음, 구성 모드에서 commit을 입력합니다.

라우터 CE1

라우터 PE1

라우터 P1

라우터 ABR

라우터 P2

라우터 PE2

라우터 CE2

라우터 PE1 구성

단계별 절차

다음 예는 구성 계층에서 다양한 수준의 탐색이 필요합니다. CLI 탐색에 관한 정보는 CLI 사용자 가이드에서 구성 모드에서 CLI 편집기 사용을 참조하십시오.

다음을 참조하여 라우터 PE1을 구성하십시오.

주:

적절한 인터페이스 이름, 주소 및 기타 매개 변수를 수정한 후 라우터 PE2에 대해 이 절차를 반복합니다.

  1. 물리적 인터페이스를 구성합니다. 코어 페이싱 인터페이스에서 family mpls을(를) 구성해야 합니다.

  2. 루프백 인터페이스를 구성합니다. 보조 루프백은 선택 사항이며 이후 단계에서 라우팅 인스턴스 아래에 적용됩니다.

  3. 라우터 ID 및 AS(Autonomous System) 번호를 구성합니다.

  4. 최단 경로 우선(OSPF) 프로토콜을 구성합니다.

  5. RSVP 프로토콜을 구성합니다.

  6. MPLS 프로토콜과 ABR을 향한 LSP를 구성합니다. MPLS 레이블 스택에 엔트로피 레이블을 추가하려면 entropy-label 옵션을 포함합니다.

  7. ABR 피어링에 대해서 을(를), PE2 피어링에 대해서family inet-vpn는 을(를) 사용하여 family inet labeled-unicastIBGP를 구성합니다. BGP 레이블이 지정된 유니캐스트에 대한 엔트로피 레이블 기능을 활성화합니다.

  8. BGP VPN 경로를 최단 경로 우선(OSPF)으로 내보내는 정책을 정의합니다. 이 정책은 라우팅 인스턴스의 최단 경로 우선(OSPF) 아래에 적용됩니다.

  9. 로드 밸런싱 정책을 정의하고 routing-options forwarding-table 아래에 적용합니다. PE1은 예시에서 하나의 경로만 있으므로 이 단계는 필요하지 않지만 이 예시에서는 모든 디바이스에 동일한 로드 밸런싱 정책을 적용합니다.

  10. 레이어 3 VPN 라우팅 인스턴스를 구성합니다.

  11. 라우팅 인스턴스에 인터페이스를 할당합니다.

  12. 라우팅 인스턴스에 대한 경로 식별자를 구성합니다.

  13. 라우팅 인스턴스에 대한 VPN 라우팅 및 포워딩(VRF) 대상을 구성합니다.

  14. 라우팅 인스턴스 아래에 프로토콜 최단 경로 우선(OSPF)을 구성하고 이전에 구성된 bgp-to-ospf 정책을 적용합니다.

라우터 P1 구성

단계별 절차

다음 예는 구성 계층에서 다양한 수준의 탐색이 필요합니다. CLI 탐색에 관한 정보는 CLI 사용자 가이드에서 구성 모드에서 CLI 편집기 사용을 참조하십시오.

라우터 P1 구성 방법:

주:

적절한 인터페이스 이름, 주소, 기타 매개 변수를 수정한 후 라우터 P2에 이 절차를 반복합니다.

  1. 물리적 인터페이스를 구성합니다.

  2. 루프백 인터페이스를 구성합니다.

  3. 라우터 ID를 구성합니다.

  4. 최단 경로 우선(OSPF) 프로토콜을 구성합니다.

  5. RSVP 프로토콜을 구성합니다.

  6. MPLS 프로토콜을 구성합니다.

라우터 ABR 구성

단계별 절차

다음 예는 구성 계층에서 다양한 수준의 탐색이 필요합니다. CLI 탐색에 관한 정보는 CLI 사용자 가이드에서 구성 모드에서 CLI 편집기 사용을 참조하십시오.

다음을 참조하여 라우터 ABR을 구성하십시오.

  1. 물리적 인터페이스를 구성합니다.

  2. 루프백 인터페이스를 구성합니다.

  3. 라우터가 로드 밸런싱을 위해 패킷을 목적지으로 해싱하는 데 사용하는 MPLS 레이블을 구성합니다.

  4. 라우터 ID 및 AS(Autonomous System) 번호를 구성합니다.

  5. 최단 경로 우선(OSPF) 프로토콜을 구성합니다.

  6. RSVP 프로토콜을 구성합니다.

  7. MPLS 프로토콜을 구성하고 PE1 및 PE2를 향한 LSP를 지정합니다. 로드 밸런싱 트래픽을 위해 두 개의 LSP가 PE2를 향해 생성되어 다른 LSP와 인터페이스가 사용되고 있음을 보여줍니다.

  8. family inet labeled-unicast을(를) 사용하여 PE1 및 PE2 모두에 IBGP를 구성합니다. PE1 및 PE2 모두에서 inet.3 루프백 경로를 알리기 위해 정책을 적용합니다. 다음 단계에서 정책을 보여줍니다.

  9. PE1 및 PE2에 대한 루프백 주소에서 일치하는 정책을 정의합니다.

  10. 로드 밸런싱을 위한 정책을 정의하고 이를 routing-options forwarding-table 아래에 적용합니다.

(선택 사항) 포트 미러링 구성

적용된 엔트로피 레이블을 보려면 트래픽을 캡처할 수 있습니다. 이 예시에서는 P1의 PE1 페이싱 인터페이스에 필터가 적용되어 CE1에서 CE2 간 트래픽을 캡처합니다. 트래픽은 보기 위해 호스트 1로 전송됩니다. 이 예시에서 사용하는 것과는 다른 트래픽 캡처 방법이 있습니다. 자세한 내용은 포트 미러링 및 분석기 이해하기을(를) 참조하십시오.

단계별 절차

다음 예는 구성 계층에서 다양한 수준의 탐색이 필요합니다. CLI 탐색에 관한 정보는 CLI 사용자 가이드에서 구성 모드에서 CLI 편집기 사용을 참조하십시오.

라우터 P1 구성 방법:

  1. 인터페이스를 구성합니다. 이 예시에서는 브리지 도메인에 Host1에 연결된 인터페이스를 넣고 Host1에 대한 연결을 확인하기 위해 IRB 인터페이스를 생성합니다.

  2. 브리지 도메인을 구성합니다.

  3. 트래픽을 캡처할 필터를 구성합니다. 이 예시에서는 모든 트래픽을 캡처합니다.

  4. PE1 페이싱 인터페이스에 필터를 적용합니다.

  5. 포트 미러링 옵션을 구성합니다. 이 예시에서는 모든 트래픽을 미러링하고 인터페이스 ge-0/0/4에 연결된 Host1로 보냅니다.

검증

구성이 올바르게 작동하고 있는지 확인합니다.

엔트로피 레이블 기능이 보급되고 있는지 확인

목적

PE2에 대한 경로에 대해 엔트로피 레이블 기능 경로 속성이 ABR에서 PE1로 보급되고 있는지 확인합니다.

작업

운영 모드에서 라우터 ABR에 show route advertising-protocol bgp 10.1.255.2 detail 명령을 실행합니다.

의미

출력은 IP 주소가 10.1.255.6인 호스트 PE2가 엔트로피 레이블 기능과 사용되는 경로 레이블을 가지고 있음을 보여줍니다. 호스트는 BGP 인접 라우터에 엔트로피 레이블 기능을 보급합니다.

라우터 PE1이 엔트로피 레이블 보급을 수신하는지 확인

목적

라우터 PE1이 라우터 PE2에 대한 엔트로피 레이블 보급을 수신하는지 확인합니다.

작업

운영 모드의 라우터 PE1에서 show route protocol bgp 10.1.255.6 extensive 명령을 실행합니다.

의미

라우터 PE1은 BGP 인접 라우터로부터 엔트로피 레이블 기능 보급을 수신합니다.

ABR에서 PE2로 ECMP 확인

목적

ECMP(Equal Cost Multipath)를 PE2로 확인합니다.

작업

운영 모드에서 라우터 ABR에 show route table mpls.0 및 show route forwarding-table label <label>명령을 실행합니다.

의미

출력은 BGP 레이블이 지정된 유니캐스트 경로에 사용되는 레이블에 대한 ECMP를 보여줍니다.

PE1에서 CE2에 대한 경로 표시

목적

CE2에 대한 경로를 확인합니다.

작업

운영 모드의 라우터 PE1에서 show route table VPN-l3vpn.inet.0 172.16.255.7 extensive 및 show route table VPN-l3vpn.inet.0 192.168.255.7 extensive 명령을 실행합니다.

의미

출력은 두 경로 모두에 대해 동일한 레이블이 사용되는 것을 보여줍니다.

CE1에서 CE2 ping

목적

연결을 확인하고 로드 밸런싱을 확인하는 데 사용합니다.

작업

운영 모드의 라우터 PE1에서 ping 172.16.255.7 source 172.16.12.1 rapid count 100 및 ping 192.168.255.7 source 192.168.255.1 rapid count 200 명령을 실행합니다.

의미

출력은 ping이 성공적으로 수행되었음을 보여줍니다.

로드 밸런싱 확인

목적

로드 밸런싱을 확인합니다.

작업

운영 모드의 ABR에서 show mpls lsp ingress statistics 명령을 실행합니다.

의미

출력은 LSP abr-pe2-2을(를) 사용한 이전 명령의 첫 번째 ping과 LSP abr-pe2을(를) 사용한 두 번째 ping을 보여줍니다.

엔트로피 레이블 확인

목적

사용된 ping 간에 엔트로피 레이블이 다른지 확인합니다.

작업

호스트 1에서 tcpdump -i eth1 -n을(를) 실행합니다.

의미

출력은 두 개의 다른 ping 명령에 대한 엔트로피 레이블에 대해 다른 값을 보여줍니다.

LSP에 대한 UHP 구성

기본적으로 RSVP 신호 전송 LSP는 PHP(Penultimate-Hop Popping)를 사용합니다. 그림 4에는 라우터 PE1과 라우터 PE2 간의 PHP LSP가 나와 있습니다. 라우터 CE1은 LSP 수신 라우터이기도 한 다음 홉(라우터 PE1)으로 패킷을 전달합니다. 라우터 PE1은 이 패킷의 레이블 1을 푸시하고 레이블 지정된 이 패킷을 라우터 P1로 전달합니다. 라우터 P1은 표준 MPLS 레이블 스와핑 작업을 완료하여 레이블 1과 레이블 2를 교체하고 패킷을 라우터 P2로 전달합니다. 라우터 P2는 LSP에서 라우터 PE2에 대해 끝에서 두 번째 홉 라우터이므로 먼저 해당 레이블을 내보낸 다음 라우터 PE2에 이 패킷을 전달합니다. 라우터 PE2가 수신하면 이 패킷은 서비스 레이블이나 명시적 NULL 레이블을 가질 수 있고 단순히 일반 IP 또는 VPLS 패킷이 될 수도 있습니다. 라우터 PE2는 레이블이 지정되지 않은 패킷을 라우터 CE2로 전달합니다.

그림 4: LSP에 대한 PHP(Penultimate-Hop Popping)LSP에 대한 PHP(Penultimate-Hop Popping)

RSVP 신호 전송 LSP에 대해서도 그림 5에 나온 것과 같이 UHP(Ultimate-Hop Popping)를 구성하실 수 있습니다. 일부 네트워크 애플리케이션에서는 송신 라우터(라우터 PE2)에 도착하는 패킷이 NULL이 아닌 외부 레이블을 포함해야 할 수 있습니다. UHP(Ultimate-Hop Popping) LSP를 위해 끝에서 두 번째 라우터(그림 5의 라우터 P2)는 패킷을 송신 라우터 PE2에 전달하기 전에 표준 MPLS 레이블 스와핑(이 예에서는 레이블 2와 레이블 3 교체) 작업을 수행합니다. 라우터 PE2는 외부 레이블을 내보내고 패킷 주소의 두 번째 조회를 수행하여 최종 대상을 결정합니다. 그런 다음 패킷을 해당 대상(라우터 CE2 또는 라우터 CE4)으로 전달합니다.

그림 5: LSP에 대한 UHP(Ultimate-Hop Popping)LSP에 대한 UHP(Ultimate-Hop Popping)

다음과 같은 네트워크 애플리케이션에서는 UHP LSP를 구성하셔야 합니다.

  • 성능 모니터링 및 인밴드 OAM을 위한 MPLS-TP

  • 에지 보호 가상 서킷

다음과 같은 기능은 UHP 동작을 지원하지 않습니다.

  • LDP 신호 전송 LSP

  • 정적 LSP

  • 포인트 투 멀티포인트 LSP

  • ccc

  • traceroute 명령

UHP 동작에 대한 보다 자세한 내용은 인터넷 초안 draft-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt, RSVP-TE LSP를 위한 아웃오브밴드 매핑 및 PHP가 아닌 동작을 참조하십시오.

포인트 투 포인트 RSVP 신호 전송 LSP의 경우, UHP 동작은 LSP 수신 신호를 받습니다. 수신 라우터 구성을 기반으로 RSVP는 PHP가 아닌 플래그 세트를 포함하는 UHP LSP의 신호를 전송할 수 있습니다. RSVP PATH 메시지는 LSP-ATTRIBUTES 개체의 이 두 개 플래그를 전달합니다. 송신 라우터는 이 PATH 메시지를 수신하면 LSP에 NULL이 아닌 레이블을 할당합니다. RSVP 또한 mpls.0 라우팅 테이블에 두 개의 경로를 생성하여 설치합니다. S는 MPLS 레이블의 S 부분을 의미하며, 레이블 스택의 최하단에 도달했는지 여부를 나타냅니다.

  • Route S=0 - 스택에 레이블이 더 있음을 나타냅니다. 이 경로의 다음 홉은 mpls.0 라우팅 테이블을 가리켜 연동된 MPLS 레이블 조회를 트리거함으로써 스택에 남아 있는 MPLS 레이블을 찾습니다.

  • Route S=1 - 레이블이 더 이상 없음을 나타냅니다. 플랫폼에서 연동된 멀티 패밀리 조회가 지원되는 경우, 다음 홉은 inet.0 라우팅 테이블을 가리킵니다. 또는 레이블 경로가 VT 인터페이스를 가리켜 IP 전달을 시작할 수도 있습니다.

UHP LSP를 활성화하면 레이어 3 VPN, VPLS, 레이어 2 VPN, 레이어 2 서킷 등과 같은 MPLS 애플리케이션이 UHP LSP를 사용할 수 있습니다. 아래에는 UHP LSP가 여러 유형의 MPLS 애플리케이션에 어떻게 영향을 미치는지에 대한 설명이 나와 있습니다.

  • 레이어 2 VPN 및 레이어 2 서킷 - PE 라우터(UHP LSP의 송신 라우터)에 두 개의 레이블을 포함하는 패킷이 도착합니다. 외부 레이블(S=0)은 UHP 레이블이고, 내부 레이블(S=1)은 VC 레이블입니다. 전송 레이블을 기반으로 하는 조회에 따라 mpls.0 라우팅 테이블에 대한 테이블 처리가 발생합니다. mpls.0 라우팅 테이블에 내부 레이블에 해당하는 추가 경로가 있습니다. 내부 레이블을 기반으로 하는 조회에 따라 고객 에지(CE) 라우터 다음 홉이 발생합니다.

  • 레이어 3 VPN - PE 라우터(UHP LSP의 송신 라우터)에 두 개의 레이블을 포함하는 패킷이 도착합니다. 외부 레이블(S=0)은 UHP 레이블이고, 내부 레이블은 VPN 레이블(S=1)입니다. 전송 레이블을 기반으로 하는 조회에 따라 mpls.0 라우팅 테이블에 대한 테이블 처리가 발생합니다. 이 시나리오에서는 두 가지 경우가 있습니다. 기본적으로 레이어 3 VPN은 다음 홉별 레이블을 광고합니다. 내부 레이블을 기반으로 하는 조회에 따라 고객 에지(CE) 라우터로 향하는 다음 홉이 발생합니다. 그러나 레이어 3 VPN 라우팅 인스턴스에 대해 vrf-table-label 명령문을 구성하신 경우, 내부 LSI 레이블은 VRF 라우팅 테이블을 가리킵니다. VRF 라우팅 테이블에 대해 IP 조회도 완료됩니다.

    주:

    vrf-table-label 명령문으로 구성한 레이어 3 VPN에 대한 UHP는 MX 시리즈 5G 유니버설 라우팅 플랫폼에서만 지원됩니다.

  • VPLS - PE 라우터(UHP LSP의 송신 라우터)에 두 개의 레이블을 포함하는 패킷이 도착합니다. 외부 레이블은 전송 레이블(S=0)이고, 내부 레이블은 VPLS 레이블(S=1)입니다. 전송 레이블을 기반으로 하는 조회에 따라 mpls.0 라우팅 테이블에 대한 테이블 처리가 발생합니다. 터널 서비스가 구성되지 않았거나 VT 인터페이스를 사용할 수 없는 경우 mpls.0 라우팅 테이블의 내부 레이블을 기반으로 하는 조회에 따라 VPLS 라우팅 인스턴스의 LSI 터널 인터페이스가 발생합니다. MX 3D 시리즈 라우터는 연동 조회 및 멀티 패밀리 조회를 지원합니다.

    주:

    no-tunnel-service 명령문으로 구성한 VPLS에 대한 UHP는 MX 3D 시리즈 라우터에서만 지원됩니다.

  • MPLS를 통한 IPv4 - PE 라우터(UHP LSP의 송신 라우터)에 한 개 레이블(S=1)을 포함하는 패킷이 도착합니다. 이 레이블을 기반으로 하는 조회가 VT 터널 인터페이스를 반환합니다. 패킷을 어디로 전달할지 결정하기 위해 VT 인터페이스에서 또 다른 IP 조회가 완료됩니다. 라우팅 플랫폼이 멀티 패밀리 조회와 연동 조회를 지원하는 경우(예: MX 3D 라우터 및 PTX 시리즈 패킷 전송 라우터), 레이블 경로(S=1)를 기반으로 하는 조회가 inet.0 라우팅 테이블을 가리킵니다.

  • MPLS를 통한 IPv6 - MPLS를 통한 IPv6 터널링의 경우, PE 라우터는 레이블 값 2를 이용해 서로에게 IPv6 경로를 광고합니다. 이것이 IPv6에 대한 명시적 NULLL 레이블입니다. 그 결과 원격 PE 라우터에서 학습된 IPv6 경로에 대한 포워딩 다음 홉은 보통 두 개의 레이블을 푸시합니다. 내부 레이블은 2(광고하는 PE 라우터가 다른 벤더 제품인 경우 다를 수 있음)이고, 라우터 레이블은 LSP 레이블입니다. PE 라우터(UHP LSP의 송신 라우터)에 두 개의 레이블을 포함하는 패킷이 도착합니다. 외부 레이블은 전송 레이블(S=0)이고, 내부 레이블은 IPv6 명시적 NULL 레이블(레이블 2)입니다. mpls.0 라우팅 테이블의 내부 레이블을 기반으로 하는 조회가 mpls.0 라우팅 테이블로 다시 리디렉션됩니다. MX 3D 시리즈 라우터에서는 내부 레이블(레이블 2)이 제거되고 inet6.0 라우팅 테이블을 사용하여 IPv6 조회가 수행됩니다.

  • PHP 및 UHP LSP 모두 활성화 - 동일한 네트워크 경로에서 PHP 및 UHP LSP를 모두 구성하실 수 있습니다. install-nexthop 명령문을 포함하는 정규식을 사용하여 포워딩 LSP 다음 홉을 선택하면 PHP 트래픽과 UHP 트래픽을 분리하실 수 있습니다. 또한 단순히 LSP 이름을 적절히 지정하는 방법으로도 트래픽 분리가 가능합니다.

다음의 명령문은 LSP에 대한 UHP(Ultimate-Hop Popping)를 활성화해줍니다. 이 기능은 특정 LSP에 대해 또는 라우터에서 구성된 모든 수신 LSP에 대해 활성화하실 수 있습니다. LSP 수신 라우터에서 다음의 명령문을 구성하십시오.

  1. UHP(Ultimate-Hop Popping)를 활성화하려면 다음과 같은 ultimate-hop-popping 명령문을 포함합니다.

    특정 LSP에서 UHP(Ultimate-Hop Popping)를 활성화하려면 [edit protocols mpls label-switched-path label-switched-path-name] 계층 수준에서 이 명령문을 포함하십시오. 라우터에 구성된 모든 수신 LSP에서 UHP(Ultimate-Hop Popping)를 활성화하려는 경우에는 [edit protocols mpls] 계층 수준에서 이 명령문을 포함하시면 됩니다. 또한 해당하는 [edit logical-routers] 계층 수준 아래에서 ultimate-hop-popping 명령문을 구성하실 수도 있습니다.

    주:

    UHP(Ultimate-Hop Popping)를 활성화할 때 RSVP는 단절 전 접속 방식을 이용해 기존 LSP 신호를 UHP(Ultimate-Hop Popping) LSP로 다시 보내려 합니다. 송신 라우터가 UHP(Ultimate-Hop Popping)를 지원하지 않는 경우, 기존 LSP는 제거됩니다(RSVP가 LSP의 경로를 따라 PathTear 메시지를 보내 경로 상태와 종속된 예약 상태를 제거하고 연관된 네트워킹 리소스를 릴리스합니다).

    UHP(Ultimate-Hop Popping)를 비활성화할 경우, RSVP는 단절 전 접속 방식을 이용해 기존 LSP 신호를 PHP(Penultimate-Hop Popping) LSP로 다시 보냅니다.

  2. MX 3D 시리즈 라우터에서만 UHP(Ultimate-Hop Popping) 및 연동되는 다음 홉을 모두 활성화하려면 network-services 명령문에 대해 enhanced-ip 옵션도 구성하셔야 합니다.

    이 명령문은 [edit chassis] 계층 수준에서 구성합니다. network-services 명령문을 구성했으면 라우터를 재부팅하여 UHP 동작을 활성화하셔야 합니다.

Explicit-Path LSP 구성

Constrained-Path LSP 계산 비활성화에 설명된 대로 Constrained-path LSP(label-switched path) 계산을 비활성화하면 LSP를 수동으로 구성하거나 LSP가 IGP 경로를 따르도록 할 수 있습니다.

explicit-path LSP가 구성되면, LSP는 지정한 경로를 따라 설정됩니다. 네트워크가 분할되어 있거나 경로의 일부를 따라 사용 가능한 리소스가 부족하여 경로가 토폴로지 방식으로 실현 가능하지 않으면 LSP가 실패합니다. 대체 경로는 사용할 수 없습니다. 설정이 성공하면 LSP는 정의된 경로에 무기한으로 유지됩니다.

explicit-path LSP를 구성하려면 다음 단계를 따르십시오.

  1. 지정 경로 생성에 설명된 것처럼 지정 경로에 경로 정보를 구성합니다. 완전한 경로 정보를 구성하려면 strict 속성을 사용하여 수신 라우터와 송신 라우터 사이에 모든 라우터 홉을 지정합니다. 불완전한 경로 정보를 구성하려면 경로가 불완전한 위치에 있는 loose 속성을 사용하여 라우터 홉의 하위 집합만 지정합니다.

    불완전한 경로의 경우, MPLS 라우터는 로컬 라우팅 테이블을 쿼리히여 경로를 완료합니다. 이 쿼리는 홉 단위 기준으로 수행되며, 각 라우터는 다음 explicit 홉에 도달하기에 충분한 정보만 파악할 수 있습니다. 다음 (loose) explicit 홉에 도달하기 위해 여러 개의 라우터를 트래버스해야 할 수도 있습니다.

    불완전한 경로 정보를 구성하면 현재 라우팅 테이블에 종속된 경로의 일부를 생성하고, 경로의 이 부분은 토폴로지가 변경될 때 자체적으로 경로를 조정할 수 있습니다. 따라서 불완전한 경로 정보를 포함하는 explicit-path LSP는 완전히 고정되지 않습니다. 이러한 유형의 LSP는 스스로 복구하는 기능이 제한되어 있으며, 로컬 라우팅 테이블의 내용에 따라 루프나 플랩을 생성하는 경향이 있습니다.

  2. LSP를 구성하고 지정 경로를 가리키려면 기본 및 보조 LSP 구성에 설명된 것처럼 primary 또는 secondary 문을 사용합니다.

  3. no-cspf 문을 LSP의 일부로 포함하거나 primary 또는 secondary 문의 일부로 포함하여 constrained-path LSP 계산을 비활성화합니다. 자세한 정보는 Constrained-Path LSP 계산 비활성화를 참조하십시오.

  4. 다른 LSP 속성을 구성합니다.

주:

송신 노드에 속하는 두 개 이상의 strict 홉을 사용하여 constrained-path LSP를 정의할 때, RSVP 경로 메시지를 수신하는 인터페이스의 송신 노드에 할당된 IP 주소와 일치하도록 첫 번째 strict 홉을 설정해야 합니다. 들어오는 RSVP 경로 메시지가 다른 IP 주소를 가진 인터페이스에 도달하면 LSP가 거부됩니다.

Junos OS 20.3X75-D20 또는 22.2R1 이전에는 RSVP 경로 메시지를 수신하는 인터페이스의 IP 주소와 일치하는 strict 홉 이후의 모든 추가적인 strict 홉이 송신 노드에 할당된 루프백 주소와 일치하도록 반드시 설정해야 합니다. 이후 Junos 릴리스에서는 송신 노드의 모든 인터페이스에 할당된 IP 주소와 일치하는 추가적인 strict 홉을 허용하도록 이 동작이 변경됩니다.

explicit-path LSP 사용 시 다음과 같은 제약 조건이 있습니다.

  • 더 많은 구성 노력이 필요합니다.

  • 구성된 경로 정보는 동적 네트워크 대역폭 예약을 고려할 수 없으므로 LSP는 리소스가 고갈될 때 실패하는 경향이 있습니다.

  • explicit-path LSP가 실패하면 수동으로 복구해야 합니다.

이러한 제약 때문에 오프라인 시뮬레이션 소프트웨어 패키지를 사용한 계산으로 최적화된 LSP 배치 전략 시행과 같은 제어된 상황에서만 explicit-path LSP를 사용하는 것이 좋습니다.

예: 명시적 경로의 LSP 구성

수신 라우터에서 명시적 경로의 LSP를 생성하고, 송신 및 수신 라우터 사이의 전송 라우터를 지정합니다. 이 구성에서는 제약된 경로 계산은 수행되지 않습니다. 기본 경로의 경우, 모든 중간 홉은 엄격하게 지정되어 그 경로는 변경되지 못합니다. 보조 경로는 먼저 라우터 14.1.1을 통해 이동해야 하며, 어떤 경로든 목적지에 도달할 수 있는 경로를 택합니다. 보조 경로에 의해 취해진 나머지 경로는 일반적으로 IGP에 의해 계산된 최단 경로입니다.

주:

송신 노드에 속하는 두 개 이상의 strict 홉을 사용하여 constrained-path LSP를 정의할 때, RSVP 경로 메시지를 수신하는 인터페이스의 송신 노드에 할당된 IP 주소와 일치하도록 첫 번째 strict 홉을 설정해야 합니다. 들어오는 RSVP 경로 메시지가 다른 IP 주소를 가진 인터페이스에 도달하면 LSP가 거부됩니다.

Junos OS 20.3X75-D20 또는 22.2R1 이전에는 RSVP 경로 메시지를 수신하는 인터페이스의 IP 주소와 일치하는 strict 홉 이후의 모든 추가적인 strict 홉이 송신 노드에 할당된 루프백 주소와 일치하도록 설정해야 합니다. 이후 Junos 릴리스에서는 송신 노드의 모든 인터페이스에 할당된 IP 주소와 일치하는 추가적인 strict 홉을 허용하도록 이 동작이 변경됩니다.

LSP 대역폭 오버서브스크립션 개요

LSP는 LSP를 트래버스할 것으로 예상하는 최대 트래픽 양에 대해 구성된 대역폭 예약으로 설정됩니다. 모든 LSP가 항상 링크를 통해 최대 트래픽 양을 전달하는 것은 아닙니다. 예를 들어, 링크 A의 대역폭이 완전히 예약되어 있더라도 실제 대역폭을 계속 사용할 수 있지만 현재 사용되지 않습니다. 이 초과 대역폭은 다른 LSP가 링크를 오버서브스크립션하는 링크 A를 사용하도록 허용함으로써 사용할 수 있습니다. 개별 클래스 유형에 대해 구성된 대역폭을 오버서브스크립션하거나 인터페이스를 사용하여 모든 클래스 유형에 대해 단일 값을 지정할 수 있습니다.

오버서브스크립션을 사용하여 트래픽 패턴의 통계 특성을 통해 링크 활용도를 높일 수 있습니다.

다음 예는 대역폭 오버서브스크립션과 언더서브스크립션을 사용하는 방법을 설명합니다.

  • 트래픽의 피크 기간이 시간과 일치하지 않는 클래스 유형에 오버서브스크립션을 사용합니다.

  • best-effort 트래픽을 전달하는 클래스 유형의 오버서브스크립션을 사용합니다. 네트워크 리소스의 활용도를 높이는 대가로 트래픽이 일시적으로 지연되거나 중단될 수 있습니다.

  • 다른 클래스 유형에 대해 다양한 수준의 오버서브스크립션 또는 언더서브스크립션을 제공합니다. 예를 들어, 다음과 같이 트래픽 클래스의 서브스크립션을 구성합니다.

    • Best effort—ct0 1000

    • Voice—ct3 1

다중 클래스 LSP의 클래스 유형을 언더서브스크립션할 때, 모든 RSVP 세션의 총 수요는 항상 클래스 유형의 실제 용량보다 적습니다. 클래스 유형의 활용도를 제한하기 위해 언더서브스크립션을 사용할 수 있습니다.

대역폭 오버서브스크립션 계산은 로컬 라우터에서만 발생합니다. 네트워크의 다른 라우터에서 신호 전송이나 기타 상호 작용이 필요하지 않기 때문에 이 기능이 지원되지 않는 다른 라우터에서 활성화되거나 사용하도록 설정하지 않고도 개별 라우터에서 해당 기능을 사용할 수 있습니다. 인접 라우터는 오버서브스크립션 계산에 대해 파악할 필요가 없으며 IGP에 의존합니다.

다음 섹션에서는 Junos OS에서 사용할 수 있는 대역폭 오버서브스크립션 유형에 대해 설명합니다.

LSP 크기 오버서브스크립션

LSP 크기 초과 구독의 경우 LSP에 대해 예상되는 피크 속도보다 더 적은 구성하기만 하면 됩니다. 자동 폴리서에 대한 구성을 조정해야 할 수도 있습니다. 자동 폴리서는 LSP에 할당된 트래픽을 관리하여 구성된 대역폭 값을 초과하지 않도록 보장합니다. LSP 크기 초과 구독을 하려면 LSP가 구성된 대역폭 할당을 초과할 수 있어야 합니다.

폴리싱은 여전히 가능합니다. 그러나 폴리서는 구성된 값이 아닌 LSP에 대해 계획된 최대 대역폭을 감당할 수 있도록 수동으로 구성해야 합니다.

클래스 유형 초과 구독 및 로컬 초과 구독 승수

로컬 초과 구독 승수 (LOM)는 다른 클래스 유형에 대한 다른 초과 구독 값을 허용합니다. LOM은 다른 링크에 대해 초과 구독 비율을 다르게 구성할 필요가 있고 다른 클래스에 대해 초과 구독 값이 필요한 네트워크에 유용합니다. 이 기능을 사용하여 최선의 트래픽을 처리하는 클래스 유형을 초과 구독할 수 있지만 음성 트래픽을 처리하는 클래스 유형에는 초과 구독을 사용하지 않습니다. LOM은 라우터에서 국소적으로 계산됩니다. LOM과 관련된 정보는 네트워크의 다른 라우터에 시그널링되지 않습니다.

LOM은 각 링크 및 각 클래스 유형에 대해 구성할 수 있습니다. 클래스별 유형 LOM은 초과 구독 비율을 증가하거나 줄일 수 있습니다. 클래스 유형별 LOM은 허용 제어 및 예약되지 않은 대역폭의 IGP 표시를 위하여 모든 로컬 대역폭 계정의 계산에 포함됩니다.

LOM 계산은 클래스 유형 전체에 걸친 초과 구독 효과가 정확하게 설명되어야 하기 때문에 사용되는 대역폭 모델(MAM, 확장MAM 및 러시아 인형)과 관련이 있습니다.

주:

모든 LOM 계산은 Junos OS에 의해 수행되며 사용자의 개입을 필요로 하지 않습니다.

클래스 유형의 초과 구독 관련 공식은 다음 섹션에서 설명합니다.

LSP에 대한 대역폭 구독 백분율 구성하기

RSVP는 기본 설정으로 모든 클래스 유형의 대역폭(100%)을 RSVP 예약에 사용하도록 허용합니다. 다중 클래스 LSP의 클래스 유형을 초과하여 구독하면, 모든 RSVP 세션의 총수요는 클래스 유형의 실제 용량을 초과할 수 있습니다.

동일한 백분율 대역폭을 사용하여 인터페이스에서 모든 클래스 유형을 초과 또는 미만으로 구독하기를 원한다면 subscription 명령문을 사용해 다음과 같이 백분율을 구성합니다.

이러한 명령문을 포함할 수 있는 계층 수준의 목록은 명령문 요약 섹션을 참조하십시오.

각 클래스 유형에 대한 대역폭을 초과 또는 미만으로 구독하려면 각 클래스 유형(ct0, ct1, ct2, ct3)의 백분율을 subscription 명령문에 대한 옵션으로 구성합니다. 클래스 유형을 초과 구독하면 LOM은 예약된 실제 대역폭을 계산하도록 적용됩니다. 자세한 정보는 클래스 유형 초과 구독 및 로컬 초과 구독 승수를 참조하세요.

이러한 명령문을 포함할 수 있는 계층 수준의 목록은 명령문 요약 섹션을 참조하십시오.

percentage은(는) RSVP가 예약에 사용하도록 허용하는 클래스 유형 대역폭의 비율입니다. 0에서 65,000% 사이의 값이 될 수 있습니다. 100보다 큰 값을 지정하면, 인터페이스 또는 클래스 유형을 초과하여 구독하게 됩니다.

클래스 유형을 초과 구독할 때 구성하는 값은 실제로 사용할 수 있는 클래스 유형 대역폭의 비율입니다. 기본 구독 값은 100%입니다.

subscription 명령문을 사용해 하나 이상의 클래스 유형에 대해 새로운 RSVP 세션을 비활성화 할 수 있습니다. 0의 비율을 구성하면, 클래스 유형에 대해 새로운 세션(대역폭 0 요구 사항을 포함)이 허용되지 않습니다.

기존 RSVP 세션은 구독 요소 변경에 대한 영향을 받지 않습니다. 기존 세션을 지우려면 clear rsvp session 명령을 내립니다. clear rsvp session 명령에 대한 자세한 정보는 CLI 익스플로러를 참조하십시오.

대역폭 구독 구성에 대한 제약 조건

대역폭 구독 구성을 할 때 다음의 문제를 주의해야 합니다.

  • [edit class-of-service interface interface-name] 계층 수준에서 대역폭 제약 조건을 구성하면 Diffserv-TE의 [edit protocols rsvp interface interface-name bandwidth] 계층 수준에서 지정한 모든 대역폭 구성을 대체합니다. 또한 CoS(class of service) 또는 RSVP 대역폭 제약 중 하나가 인터페이스 하드웨어 대역폭 제약을 무시할 수 있다는 점에 주의하세요.

  • 모든 인터페이스에 구성된 값과 다른 특정 인터페이스에 대한 대역폭 구독 값을 구성하면([edit protocols rsvp interface interface-name] 및 [edit protocols rsvp interface all] 계층 수준에서 subscription 명령문에 대한 다른 값을 포함하여) 인터페이스에 따른 특정 값은 해당 인터페이스에 사용됩니다.

  • 대역폭 모델을 구성하는 경우에만 각 클래스 유형에 대한 구독 구성을 할 수 있습니다. 대역폭 모델이 설정되지 않은 경우, 커밋 작업은 실패하며 다음의 오류 메시지가 나옵니다.

  • 특정 클래스 유형을 위한 구성과 전체 인터페이스의 구성을 모두에 해당하는 subscription 명령문을 포함할 수 없습니다. 커밋 작업은 실패하며 다음의 오류 메시지가 나옵니다.

관련 항목

변경 내역 표

기능 지원은 사용 중인 플랫폼과 릴리스에 따라 결정됩니다. Feature Explorer 를 사용하여 플랫폼에서 기능이 지원되는지 확인하세요.

릴리스
설명
14.1R9
Junos OS 릴리스 14.1R9, 15.1R7, 16.1R5, 16.1X2, 16.2R3, 17.2R2에서 시작하는 모든 제로 값 대역폭 샘플은 LSP가 처음으로 올라온 후 도착한 제로 값 샘플을 제외한 언더플로 샘플로 간주되며 라우팅 엔진 스위치 후 처음 도착한 제로 값 샘플을 포함합니다.