Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
이 페이지의 내용
 

Junos 노드 슬라이싱 이해

Junos 노드 슬라이싱 개요

Junos Node Slicing을 사용하면 서비스 프로바이더와 대기업이 여러 라우팅 기능을 단일 물리적 디바이스로 통합하는 네트워크 인프라를 구축할 수 있습니다. 이는 관련된 운영 복잡성을 피하면서 단일 물리적 인프라에서 여러 서비스를 호스팅하는 데 도움이 됩니다. 또한 디바이스에서 호스팅되는 기능의 운영, 기능 및 관리 분리를 유지합니다.

Junos Node Slicing을 사용하면 단일 물리적 MX 시리즈 라우터에서 여러 파티션을 생성할 수 있습니다. 이러한 파티션을 게스트 네트워크 기능(GNF)이라고 합니다. 각 GNF는 자체 전용 컨트롤 플레인, 데이터 플레인 및 관리 플레인을 갖춘 독립적인 라우터로 작동합니다. 이를 통해 단일 컨버지드 MX 시리즈 라우터에서 여러 서비스를 실행하는 동시에 서비스 간의 운영 격리를 유지할 수 있습니다. 동일한 물리적 디바이스를 활용하여 컨트롤 플레인이나 포워딩 플레인을 공유하지 않고 동일한 섀시, 공간 및 전원만 공유하는 병렬 파티션을 생성할 수 있습니다.

또한 최고급 이더넷 인터페이스로 작동하는 유사 인터페이스인 추상화된 패브릭(af) 인터페이스를 사용하여 스위치 패브릭을 통해 GNF 간에 트래픽을 전송할 수도 있습니다. 추상화된 패브릭 인터페이스는 GNF 간의 라우팅 제어, 데이터 및 관리 트래픽을 용이하게 합니다.

Junos Node Slicing은 외부 서버 모델과 섀시 내 모델의 두 가지 모델을 제공합니다. 외부 서버 모델에서 GNF는 한 쌍의 업계 표준 x86 서버에서 호스팅됩니다. 섀시 내 모델의 경우, GNF는 MX 시리즈 라우터 자체의 라우팅 엔진에서 호스팅됩니다.

Junos Node Slicing은 다중 버전 소프트웨어 호환성을 지원하므로 GNF를 독립적으로 업그레이드할 수 있습니다.

Junos 노드 슬라이싱의 이점

  • Converged network- 서비스 프로바이더는 Junos Node Slicing을 통해 비디오 에지 및 음성 에지와 같은 여러 네트워크 서비스를 하나의 물리적 라우터로 통합하면서도 이들 간의 운영 분리를 유지할 수 있습니다. 수평적 및 수직적 컨버전스를 모두 달성할 수 있습니다. 수평 컨버전스는 동일한 레이어의 라우터 기능을 단일 라우터로 통합하는 반면, 수직 컨버전스는 서로 다른 레이어의 라우터 기능을 단일 라우터로 축소합니다.

  • Improved scalability- 물리적 디바이스 대신 가상 라우팅 파티션에 초점을 맞추면 네트워크의 프로그래밍 가능성과 확장성이 향상되어 서비스 프로바이더와 기업이 추가 하드웨어를 구입하지 않고도 인프라 요구 사항에 대응할 수 있습니다.

  • Easy risk management- 여러 네트워크 기능이 단일 섀시에 융합되더라도 운영, 기능 및 관리가 분리되기 때문에 모든 기능이 독립적으로 실행됩니다. BNG(Broadband Network Gateway)와 같은 물리적 시스템을 여러 개의 독립적인 논리적 인스턴스로 분할하면 장애가 격리됩니다. 파티션은 컨트롤 플레인이나 포워딩 플레인을 공유하지 않고 동일한 섀시, 공간 및 전원만 공유합니다. 즉, 한 파티션에서 장애가 발생하더라도 광범위한 서비스 중단이 발생하지 않습니다.

  • Reduced network costs- Junos Node Slicing은 내부 스위칭 패브릭을 통해 GNF의 상호 연결을 가능하게 하며, 이는 일류 이더넷 인터페이스 동작을 나타내는 유사 인터페이스인 추상화된 패브릭(af) 인터페이스를 활용합니다. 인터페이스가 구축되면 af 기업은 더 이상 GNF를 연결하기 위해 물리적 인터페이스에 의존할 필요가 없으므로 상당한 절감 효과를 얻을 수 있습니다.

  • Reduced time-to-market for new services and capabilities—각 GNF는 서로 다른 Junos 소프트웨어 버전에서 작동할 수 있습니다. 이러한 이점을 통해 기업은 각 GNF를 각자의 속도에 맞춰 발전시킬 수 있습니다. 특정 GNF에 새로운 서비스 또는 기능을 배포해야 하고 새 소프트웨어 릴리스가 필요한 경우 관련된 GNF만 업데이트하면 됩니다. 또한, Junos Node Slicing은 향상된 민첩성을 통해 서비스 프로바이더와 기업이 매우 유연한 Everything-as-a-service 비즈니스 모델을 도입하여 끊임없이 변화하는 시장 상황에 신속하게 대응할 수 있도록 해줍니다.

Junos 노드 슬라이싱의 구성 요소

Junos Node Slicing을 사용하면 단일 MX 시리즈 라우터를 분할하여 여러 개의 독립적인 라우터로 보이게 할 수 있습니다. 각 파티션에는 가상 머신(VM)으로 실행되는 자체 Junos OS 컨트롤 플레인과 전용 라인 카드 세트가 있습니다. 각 파티션을 게스트 네트워크 기능(GNF)이라고 합니다.

MX 시리즈 라우터는 기본 시스템(BSYS)으로 작동합니다. BSYS는 라인 카드와 스위칭 패브릭을 포함하여 라우터의 모든 물리적 구성 요소를 소유합니다. BSYS는 라인 카드를 GNF에 할당합니다.

주니퍼 장치 관리자(JDM) 소프트웨어는 GNF VM을 오케스트레이션합니다. JDM에서 GNF VM은 가상 네트워크 기능(VNF)이라고 합니다. 따라서 GNF는 VNF와 라인 카드 집합으로 구성됩니다.

BSYS에서의 구성을 통해 섀시의 라인 카드를 다른 GNF에 할당할 수 있습니다. 또한 라인 카드 유형에 따라 라인 카드 내의 PFE 세트를 다른 GNF에 할당할 수도 있습니다. 자세한 내용은 하위 라인 카드 개요 를 참조하십시오.

Junos Node Slicing은 다음 두 가지 모델을 지원합니다.

  • 외부 서버 모델

  • 섀시 내 모델

외부 서버 모델에서 JDM 및 VNF는 한 쌍의 외부 업계 표준 x86 서버에서 호스팅됩니다.

그림 1에는 외부 서버에서 실행되는 전용 라인 카드가 있는 3개의 GNF가 나와 있습니다.

그림 1: 외부 서버 High-level network architecture diagram showing an x86 server with Juniper Device Manager managing GNFs and an MX Series chassis with Base System and FPCs linked to GNFs. 의 GNF

MX 시리즈 라우터를 외부 x86 서버 쌍에 연결하는 방법에 대한 자세한 내용은 서버와 라우터 연결을 참조하십시오.

섀시 내 모델에서 모든 구성 요소(JDM, BSYS 및 GNF)는 MX 시리즈 라우터의 라우팅 엔진 내에서 실행됩니다. 그림 2를 참조하십시오.

그림 2: 섀시 내 Junos 노드 슬라이싱 MX Series Chassis diagram showing internal structure. Highlights Routing Engine with JDM, BSYS, GNF 1, GNF 2, GNF 3. GNFs connect to FPCs: FPC 1, 2, 3 for GNF 1; FPC 5, 6 for GNF 2; FPC 7, 8 for GNF 3.

기본 시스템(BSYS)

Junos Node Slicing에서 MX 시리즈 라우터는 기본 시스템(BSYS)으로 작동합니다. BSYS는 모든 라인 카드와 패브릭을 포함하여 라우터의 모든 물리적 구성 요소를 소유합니다. BSYS의 Junos OS 구성을 통해 라인 카드를 GNF에 할당하고 GNF 간에 추상화된 패브릭(af) 인터페이스를 정의할 수 있습니다. BSYS 소프트웨어는 MX 시리즈 라우터의 중복 라우팅 엔진 한 쌍에서 실행됩니다.

게스트 네트워크 기능(GNF)

게스트 네트워크 기능(GNF)은 기본 시스템(BSYS)에 의해 할당된 라인 카드를 논리적으로 소유하고 라인 카드의 포워딩 상태를 유지합니다. MX 시리즈 라우터에서 여러 GNF를 구성할 수 있습니다( 게스트 네트워크 기능 구성 참조). 각 GNF의 Junos OS 컨트롤 플레인은 가상 머신(VM)으로 실행됩니다. 주니퍼 장치 관리자(JDM) 소프트웨어는 GNF VM을 오케스트레이션합니다. JDM 컨텍스트에서 GNF는 가상 네트워크 기능(VNF)이라고 합니다.

GNF는 독립형 라우터와 동일합니다. GNF는 독립적으로 구성 및 관리되며 운영 상 서로 격리됩니다.

GNF를 생성하려면 두 세트의 구성이 필요하며, 하나는 BSYS에서 수행하고 다른 하나는 JDM에서 수행됩니다.

GNF는 ID로 정의됩니다. 이 ID는 BSYS 및 JDM에서 동일해야 합니다.

GNF 구성의 BSYS 부분은 ID와 라인 카드 집합을 제공하는 것으로 구성됩니다.

GNF 구성의 JDM 부분은 다음 속성을 지정하는 것으로 구성됩니다.

  • VNF 이름입니다.

  • A GNF ID. 이 ID는 BSYS에서 사용되는 GNF ID와 동일해야 합니다.

  • MX 시리즈 플랫폼 유형(외부 서버 모델용).

  • VNF에 사용할 Junos OS 이미지입니다.

  • VNF 서버 리소스 템플릿입니다.

서버 리소스 템플릿은 GNF에 할당될 전용(물리) CPU 코어 수와 DRAM의 크기를 정의합니다. GNF에 사용할 수 있는 사전 정의된 서버 리소스 템플릿 목록은 Junos 노드 슬라이싱을 위한 최소 하드웨어 및 소프트웨어 요구 사항의 서버 하드웨어 리소스 요구 사항(GNF당) 섹션을 참조하십시오.

GNF가 구성된 후에는 GNF의 가상 콘솔 포트에 연결하여 액세스할 수 있습니다. 그런 다음 GNF에서 Junos OS CLI를 사용하여 호스트 이름 및 관리 IP 주소와 같은 GNF 시스템 속성을 구성한 다음 관리 포트를 통해 액세스할 수 있습니다.

주니퍼 장치 관리자(JDM)

가상화된 Linux 컨테이너인 주니퍼 장치 관리자(JDM)를 사용하면 GNF VM을 프로비저닝하고 관리할 수 있습니다.

JDM은 구성 및 관리를 위한 Junos OS와 유사한 CLI, NETCONF 및 모니터링을 위한 SNMP를 지원합니다.

참고:

섀시 내 모델에서 JDM은 SNMP를 지원하지 않습니다.

JDM 인스턴스는 외부 서버 모델의 각 x86 서버와 섀시 내 모델의 각 라우팅 엔진에서 호스팅됩니다. JDM 인스턴스는 일반적으로 GNF 구성을 동기화하는 피어로 구성됩니다. GNF VM이 한 서버에서 생성되면 해당 백업 VM이 다른 서버 또는 라우팅 엔진에서 자동으로 생성됩니다.

JDM에서 IP 주소 및 관리자 계정을 구성해야 합니다. 이를 구성한 후 JDM에 직접 로그인할 수 있습니다.

또한보십시오

추상화된 패브릭 인터페이스

추상화된 패브릭(af) 인터페이스는 일류 이더넷 인터페이스 동작을 나타내는 유사 인터페이스입니다. 인터페이스는 af 스위치 패브릭을 통해 게스트 네트워크 기능(GNF) 간의 트래픽 라우팅, 제어 및 관리를 용이하게 합니다. af 두 GNF가 서로 연결되도록 구성되면 피어 GNF와 통신하기 위해 GNF에 인터페이스가 생성됩니다. 추상화된 패브릭 인터페이스는 BSYS에서 생성되어야 합니다. 인터페이스의 af 대역폭은 원격 라인 카드/MPC의 삽입 또는 도달 가능성에 따라 동적으로 변경됩니다. 패브릭은 GNF af 간의 통신 매체이기 때문에 인터페이스는 동등한 WAN 인터페이스로 간주됩니다. 그림 3을 참조하십시오.

그림 3: 추상화된 패브릭 인터페이스 High-level architecture of a networking system showing interconnections: GNF1 with FPC0, GNF2 with FPC4, PFEs linked via green fabric labeled Fabric, central AF point, and data paths as black lines.

추상화된 패브릭 인터페이스 대역폭 이해

추상화된 패브릭(af) 인터페이스는 패브릭을 통해 두 GNF를 연결하고 두 GNF를 연결하는 모든 패킷 전달 엔진(PFE)을 집계합니다. 인터페이스는 af 인터페이스에 속한 각 패킷 포워딩 엔진의 대역폭 합계를 활용할 수 있습니다.af

예를 들어 GNF1에 하나의 MPC8(각각 240Gbps 용량의 패킷 전달 엔진 4개가 있음)이 있고 GNF1이 인터페이스(af1 및 af2)를 사용하여 af GNF2 및 GNF3에 연결된 경우, GNF1의 최대 af 인터페이스 용량은 4x240Gbps = 960Gbps가 됩니다.

GNF1—af1——GNF2

GNF1—af2——GNF3

여기서 af1과 af2는 960Gbps 용량을 공유합니다.

각 MPC에서 지원되는 대역폭에 대한 정보는 표 1을 참조하십시오.

추상화된 패브릭 인터페이스에서 지원되는 기능

추상화된 패브릭 인터페이스는 다음과 같은 기능을 지원합니다.

  • 통합 ISSU(in-service software upgrade)

  • BSYS 수준에서 하이퍼 모드 구성(Junos OS 릴리스 19.3R2부터). 이 기능은 MPC6E, MPC8E, MPC9E 및 MPC11E 라인 카드에서 지원됩니다.

    참고:

    • 개별 GNF는 BSYS에서 구성을 상속하므로 서로 다른 하이퍼 모드 구성을 가질 수 없습니다.

    • SFB3가 탑재된 MX2020 및 MX2010 라우터는 기본적으로 하이퍼 모드로 작동합니다. GNF에서 하이퍼 모드를 비활성화해야 하는 경우 BSYS에서 구성해야 하며 해당 섀시의 모든 GNF에 적용됩니다.

  • 존재하는 원격 GNF 라인 카드를 기반으로 하는 로드 밸런싱

  • CoS(Class of Service) 지원:

    • Inet-precedence classifier 및 재작성

    • DSCP 분류자 및 재작성

    • MPLS EXP 분류자 및 재작성

    • IP v6 트래픽에 대한 DSCP v6 분류자 및 재작성

  • OSPF, IS-IS, BGP, OSPFv3 프로토콜 및 L3VPN 지원

    참고:

    비인터페이스af 는 Junos OS에서 작동하는 모든 프로토콜을 지원합니다.

  • Junos OS 릴리스 24.2R1부터 BGP, IS-IS 및 OSPF에 대한 BFD.

  • 멀티캐스트 포워딩

  • GRES(Graceful 라우팅 엔진 스위치오버)

  • 인터페이스가 af 코어 인터페이스 역할을 하는 MPLS 애플리케이션(L3VPN, VPLS, L2VPN, L2CKT, EVPN 및 IP over MPLS)

  • 지원되는 프로토콜 제품군은 다음과 같습니다.

    • IPv4 포워딩

    • IPv6 포워딩

    • MPLS

    • ISO

    • CCC

  • JTI(Junos Telemetry Interface) 센서 지원

  • Junos OS 릴리스 19.1R1부터 게스트 네트워크 기능(GNF)은 VXLAN(Virtual Extensible LAN protocol) 캡슐화를 통해 이더넷 VPN(EVPN)을 지원합니다. 이 지원은 비af (즉, 물리) 인터페이스 및 af 코어 페이싱 인터페이스인 인터페이스에서 사용할 수 있습니다. MPC11E 라인 카드에서는 이 지원을 사용할 수 없습니다.

  • 인터페이스 구성으로 af GNF는 -capable MPC를 지원합니다 af. 표 1 에는 -capable MPC, MPC당 지원되는 PFE 수 및 MPC당 지원되는 대역폭이 나와 af있습니다.

    표 1: 지원되는 추상화된 패브릭 지원 MPC

    MPC

    초기 릴리스

    PFE 수

    총 대역폭

    MPC7E-MRATE

    17.4R1

    2

    480G(240*2)

    MPC7E-10G

    17.4R1

    2

    480G(240*2)

    MX2K-MPC8E

    17.4R1

    4

    960G(240*4)

    MX2K-MPC9E

    17.4R1

    4

    1.6T(400*4)

    MPC2E

    19.1R1

    2

    80 (40*2)

    MPC2E NG

    17.4R1

    1

    80G

    MPC2E NG 큐

    17.4R1

    1

    80G

    MPC3E

    19.1R1

    1

    130G

    MPC3E NG

    17.4R1

    1

    130G

    MPC3E NG Q

    17.4R1

    1

    130G

    32x10GE MPC4E

    19.1R1

    2

    260G(130*2)

    2x100GE + 8x10GE MPC4E

    19.1R1

    2

    260G(130*2)

    MPC5E-40G10G

    18.3R1

    2

    240G(120*2)

    MPC5EQ-40G10G

    18.3R1

    2

    240G(120*2)

    MPC5E-40G100G

    18.3R1

    2

    240G(120*2)

    MPC5EQ-40G100G

    18.3R1

    2

    240G(120*2)

    MX2K-MPC6E

    18.3R1

    4

    520G(130*4)

    멀티서비스 MPC(MS-MPC)

    19.1R1

    1

    120G

    16x10GE MPC

    19.1R1

    4

    160G(40*4)

    MX2K-MPC11E

    19.3R2

    8

    4T(500G*8)
참고:

인터페이스의 af 최대 전송 단위(MTU) 설정을 XE/GE 인터페이스에서 허용되는 최대 값에 맞추도록 설정하는 것이 좋습니다. 이를 통해 인터페이스를 통한 af 패킷의 단편화를 최소화하거나 전혀 보장하지 않습니다.

추상화된 패브릭 인터페이스 제한

다음은 추상화된 패브릭 인터페이스의 현재 제한 사항입니다.

  • 단일 엔드포인트 af 인터페이스, af 인터페이스-GNF 매핑 불일치 또는 동일한 원격 GNF에 매핑되는 여러 af 인터페이스와 같은 구성은 BSYS에서 커밋하는 동안 확인되지 않습니다. 구성이 올바른지 확인합니다.

  • 대역폭 할당은 MPC 유형에 따라 정적입니다.

  • 원격 GNF에서 호스팅되는 MPC의 오프라인/재시작 중에 최소한의 트래픽 손실(전송 및 호스트 모두)이 있을 수 있습니다.

  • -able인 afMPC와 -able이 아닌 afMPC 간의 상호 운용성은 지원되지 않습니다.

또한보십시오

추상화된 패브릭 인터페이스를 위한 패브릭 경로 최적화

패브릭 경로 최적화 모드를 구성하여 두 게스트 네트워크 기능(GNF) 간의 추상적 패브릭(af) 인터페이스를 통한 트래픽 흐름을 최적화할 수 있습니다. 이 기능은 패킷이 최종 대상 패킷 포워딩 엔진에 도달하기 전에 추가 패브릭 홉(한 패킷 포워딩 엔진에서 다른 으로 트래픽 흐름 전환)을 방지하여 패브릭 대역폭 소비를 줄입니다. MPC9E 및 MX2K-MPC11E가 포함된 MX2008, MX2010 및 MX2020에서 지원되는 패브릭 경로 최적화는 추상화된 패브릭 인터페이스 로드 밸런싱으로 인해 발생하는 단일 추가 트래픽 홉만 방지합니다.

다음 패브릭 경로 최적화 모드 중 하나를 구성할 수 있습니다.

  • monitor- 이 모드를 구성하면 피어 GNF는 트래픽 흐름을 모니터링하고 현재 트래픽이 전달되고 있는 패킷 포워딩 엔진과 최적화된 트래픽 경로를 제공할 수 있는 원하는 패킷 포워딩 엔진에 대한 정보를 소스 GNF에 보냅니다. 이 모드에서 소스 GNF는 원하는 패킷 포워딩 엔진으로 트래픽을 전달하지 않습니다.

  • optimize- 이 모드를 구성하면 피어 GNF는 트래픽 흐름을 모니터링하고 현재 트래픽이 전달되고 있는 패킷 포워딩 엔진과 최적화된 트래픽 경로를 제공할 수 있는 원하는 패킷 포워딩 엔진에 대한 정보를 소스 GNF에 보냅니다. 그런 다음 소스 GNF는 원하는 패킷 포워딩 엔진으로 트래픽을 전달합니다.

패브릭 경로 최적화 모드를 구성하기 위해 BSYS에서 다음 CLI 명령을 사용합니다.

패브릭 경로 최적화를 구성한 후 GNF에서 명령을 show interfaces af-interface-name 사용하여 최적/비최적 경로에서 현재 흐르고 있는 패킷 수를 확인할 수 있습니다.

또한보십시오

외부 서버 모델과 섀시 내 모델 중에서 선택

외부 서버 모델을 사용하면 GNF 요구 사항에 맞는 충분한 용량의 서버를 선택할 수 있으므로 더 높은 규모의 GNF 인스턴스를 더 많이 구성할 수 있습니다. 섀시 내 모델에서 구성할 수 있는 GNF의 수는 구성 GNF의 확장 요구 사항과 라우팅 엔진의 전체 용량의 함수입니다.

Junos Node Slicing의 외부 서버 및 섀시 내 모델은 상호 배타적입니다. MX 시리즈 라우터는 이러한 모델 중 한 번에 하나만 작동하도록 구성할 수 있습니다.

BSYS 및 GNF의 기본 역할 동작

다음 섹션에서는 라우팅 엔진 중복의 맥락에서 BSYS 및 GNF의 기본 역할 동작을 다룹니다.

그림 4 는 라우팅 엔진 중복을 사용하는 GNF 및 BSYS의 기본 역할 동작을 보여줍니다.

그림 4: GNF 및 BSYS(외부 서버 모델) High-level architecture of redundant system with software and hardware mastership arbitration, featuring two x86 servers coordinating mastership roles. 의 기본 역할 동작

BSYS 기본 역할

BSYS 라우팅 엔진의 기본 역할 중재 동작은 MX 시리즈 라우터의 라우팅 엔진 동작과 동일합니다.

GNF 기본 역할

GNF VM 기본 역할 중재 동작은 MX 시리즈 라우팅 엔진의 동작과 유사합니다. 각 GNF는 VM의 기본 백업 쌍으로 실행됩니다. (또는 re0 섀시 내부)에서 server0 실행되는 GNF VM은 MX 시리즈 라우터의 라우팅 엔진 슬롯 0과 동일하며, (또는 re1 섀시 내부)에서 실행 server1 되는 GNF VM은 MX 시리즈 라우터의 라우팅 엔진 슬롯 1과 동일합니다.

GNF 기본 역할은 BSYS 기본 역할 및 기타 GNF의 기본 역할과 독립적입니다. GNF 기본 역할 중재는 Junos OS를 통해 수행됩니다. 연결 장애 조건에서는 GNF 기본 역할이 보수적으로 처리됩니다.

GNF 기본 역할 모델은 외부 서버와 섀시 내 모델 모두에서 동일합니다.

참고:

MX 시리즈 라우팅 엔진과 마찬가지로 각 GNF에서 GRES(Graceful 라우팅 엔진 스위치오버)를 구성해야 합니다. 이는 기본 GNF VM이 실패하거나 재부팅될 때 백업 GNF VM이 자동으로 기본 역할을 인계받기 위한 전제 조건입니다.

Junos 노드 슬라이싱 관리자 역할

다음 관리자 역할을 사용하면 Node Slicing 작업을 수행할 수 있습니다.

  • BSYS 관리자 - 물리적 섀시 및 GNF 프로비저닝(GNF에 라인 카드 할당)을 담당합니다. Junos OS CLI 명령은 이러한 작업에 사용할 수 있습니다.

  • GNF 관리자 - GNF에서 Junos OS의 구성, 운영 및 관리를 담당합니다. GNF 관리자는 이러한 작업에 대해 모든 일반 Junos OS CLI 명령을 사용할 수 있습니다.

  • JDM 관리자 - 외부 서버 모델의 경우 JDM 서버 포트 구성과 VNF(GNF VM)의 프로비저닝 및 수명 주기 관리를 담당합니다. JDM CLI 명령은 이러한 작업에 사용할 수 있습니다.

서브 라인 카드 개요

Junos Node Slicing에서 각 GNF는 일련의 라인 카드(FPC)로 구성됩니다. 기본적으로 GNF가 제공하는 가장 세밀한 세분성은 라인 카드 수준입니다. 각 GNF에는 전체 라인 카드(즉, 각 라인 카드의 전체 패킷 전달 엔진 세트)가 할당되기 때문입니다. SLC(서브 라인 카드) 기능을 사용하면 단일 라인 카드에서 패킷 전달 엔진의 하위 집합을 다른 GNF에 할당하여 파티셔닝의 세분화를 더욱 세밀하게 정의할 수 있습니다.

라인 카드에서 패킷 전달 엔진의 이러한 사용자 정의 하위 집합을 서브 라인 카드(SLC)라고 합니다. 운영 측면에서 SLC는 독립 라인 카드처럼 작동합니다.

라인 카드를 슬라이스할 때, 해당 라인 카드의 모든 SLC는 다른 GNF에 할당되어야 합니다.

여러 라인 카드의 SLC를 동일한 GNF에 할당할 수 있습니다.

SLC 기능이 있는 Junos Node Slicing 설정에서 GNF는 전체 라인 카드 세트와 라인 카드의 슬라이스(SLC) 세트로 구성될 수 있어 더 높은 수준의 유연성을 제공합니다.

라인 카드가 슬라이스되면 두 가지 유형의 소프트웨어 인스턴스가 해당 라인 카드에서 실행됩니다. 즉, 단일 기본 라인 카드(BLC) 인스턴스와 여러 SLC 인스턴스(해당 라인 카드의 슬라이스 수만큼)가 실행됩니다. 현재 SLC 기능은 2개의 SLC를 지원하는 MPC11E에서만 사용할 수 있습니다. BLC 인스턴스는 해당 라인 카드의 모든 SLC에 공통적인 하드웨어를 관리하는 반면, 각 SLC 인스턴스는 독점적으로 할당된 패킷 전달 엔진 세트를 관리할 책임이 있습니다. BLC 인스턴스는 BSYS의 Junos 소프트웨어를 실행하는 반면, 각 SLC 인스턴스는 연결된 GNF의 Junos 소프트웨어를 실행합니다.

그림 5: 외부 서버 기반 Junos Node Slicing 설정에서 GNF에 할당된 SLC High-level architecture diagram of a networking system showing Juniper Device Manager interacting with Guest Network Functions and Flexible PIC Concentrators.

SLC는 추상화된 패브릭 인터페이스 와 축소된 포워딩을 지원합니다( 추상화된 패브릭 인터페이스에 대한 패브릭 경로 최적화 참조). 이 명령을 사용하여 show interface af-interface-name 원격 FPC 슬라이스별 패킷 전달 엔진의 로드 밸런싱 통계를 볼 수 있습니다. 자세한 내용은 show interfaces(추상화된 패브릭)를 참조하십시오.

SLC 기능은 MPC11E(모델 번호: MX2K-MPC11E)에서만 사용할 수 있습니다.

SLC를 위한 라인 카드 리소스

SLC 또는 라인 카드 슬라이스는 함께 작동해야 하는 패킷 전달 엔진 집합(해당 라인 카드의)을 정의합니다. 라인 카드의 패킷 전달 엔진은 숫자 ID로 식별됩니다. 라인 카드에 'n'개의 패킷 전달 엔진이 있는 경우, 개별 패킷 전달 엔진은 0에서 (n-1)으로 번호가 매겨집니다. 또한 라인 카드 컨트롤 보드의 CPU 코어와 DRAM도 분할되어 슬라이스에 할당되어야 합니다. 따라서 SLC를 정의하려면 해당 SLC 전용으로 다음 라인 카드 리소스를 정의해야 합니다.

  • A 패킷 포워딩 엔진 범위

  • 라인 카드의 컨트롤 보드에 있는 CPU 코어 수

  • 라인 카드의 컨트롤 보드에 있는 DRAM 크기(GB)

참고:

일정량의 DRAM은 해당 라인 카드의 BLC 인스턴스에 대해 자동으로 예약되고 나머지는 SLC 인스턴스에 사용할 수 있습니다.

모든 SLC는 사용자가 할당한 숫자 ID로 식별됩니다.

라인 카드가 슬라이스되면 해당 라인 카드의 모든 슬라이스에 대한 리소스 파티션이 완전히 정의되어야 합니다.

SLC를 위한 MPC11E 라인 카드 리소스

MPC11E 라인 카드에는 다음이 있습니다.

  • 8개의 패킷 포워딩 엔진

  • 컨트롤 보드의 CPU 코어 8개

  • 컨트롤 보드의 32GB DRAM

5GB의 DRAM은 BLC 사용을 위해 자동으로 예약되고, 1GB의 DRAM은 라인 카드 호스트에 할당되며, 나머지 26GB는 SLC 슬라이스에 사용할 수 있습니다.

MPC11E는 2개의 SLC를 지원할 수 있습니다.

표 2는 두 개의 SLC에 대해 MPC11E가 지원하는 두 가지 유형의 리소스 할당 프로필을 정의하며, 여기서는 SLC1과 SLC2라고 합니다.

대칭 프로필에서 패킷 전달 엔진 및 기타 라인 카드 리소스는 슬라이스 간에 균등하게 분산됩니다. 비대칭 프로필에서는 표 2 에 표시된 지정된 라인 카드 리소스 조합만 지원됩니다.

참고:

패킷 전달 엔진 [0-7]이 두 SLC 간에 분할되는 방식에 따라 다음 SLC 프로필을 구성할 수 있습니다.

  • 패킷 전달 엔진 한 SLC의 경우 0-3, 다른 SLC의 경우 4-7(대칭 프로파일)

  • 패킷 전달 엔진 한 SLC의 경우 0-1, 다른 SLC의 경우 2-7(비대칭 프로파일)

  • 패킷 전달 엔진 한 SLC의 경우 0-5, 다른 SLC의 경우 6-7(비대칭 프로파일)

비대칭 프로필에서 9GB 또는 17GB의 DRAM을 SLC에 할당할 수 있습니다. 모든 라인 카드 리소스를 완전히 할당해야 하고 SLC에 사용할 수 있는 총 DRAM은 26GB이므로 SLC에 9GB의 DRAM을 할당하려면 나머지 17GB를 다른 SLC에 할당해야 합니다.

표 2: MPC11E가 지원하는 SLC 프로파일
 

대칭 프로파일

비대칭 프로파일

리소스 유형

SLC1

SLC2

SLC1

SLC2

패킷 포워딩 엔진

4

4

2

6

드램

13GB

13GB

17GB/9GB

9GB/17GB

프로세서(CPU)

4

4

4

4

참조: 하위 라인 카드 구성 및 GNF에 할당 및 하위 라인 카드 관리.

멀티버전 소프트웨어 상호 운용성 개요

Junos OS 릴리스 17.4R1부터 Junos Node Slicing은 다중 버전 소프트웨어 호환성을 지원하므로 BSYS는 BSYS의 소프트웨어 버전보다 높은 Junos OS 버전을 실행하는 게스트 네트워크 기능(GNF)과 상호 운용될 수 있습니다. 이 기능은 GNF와 BSYS 사이의 최대 두 가지 버전을 지원합니다. 즉, GNF 소프트웨어는 BSYS 소프트웨어보다 두 가지 더 높은 버전일 수 있습니다. BSYS와 GNF 모두 Junos OS 릴리스 17.4R1의 최소 버전 요구 사항을 충족해야 합니다.

참고:

다중 버전 지원의 제한은 통합 ISSU 업그레이드 프로세스에도 적용됩니다.

JDM 소프트웨어 버전 관리에는 GNF 또는 BSYS 소프트웨어 버전과 관련하여 유사한 제한이 없지만 JDM 소프트웨어를 정기적으로 업데이트하는 것이 좋습니다. JDM 업그레이드는 실행 중인 GNF에 영향을 주지 않습니다.

Junos Node Slicing의 차세대 서비스

Junos Node Slicing은 MX 플랫폼에서 차세대 서비스를 실행하기 위한 추가 처리 성능을 제공하는 보안 서비스 카드인 MX-SPC3 Services Card를 지원합니다. GNF에서 CLI request system enable unified-services 를 사용하여 게스트 네트워크 기능(GNF)에서 차세대 서비스를 활성화할 수 있습니다. MX-SPC3를 지원하려면 GNF에 연결된 라인 카드가 있어야 합니다.

Junos Node Slicing 설정에서는 동일한 섀시에서 MX-SPC3과 MS-MPC를 모두 사용할 수 있지만 서로 다른 GNF 라우팅 엔진에서 사용할 수 있습니다. GNF에서 차세대 서비스를 활성화했다면 를 사용하여 request system enable unified-servicesMX-SPC3가 온라인 상태가 됩니다. 차세대 서비스를 활성화하지 않은 경우 MS-MPC가 온라인으로 전환됩니다.

MX-SPC3 카드의 소프트웨어 설치 또는 업그레이드는 관련 GNF 라우팅 엔진을 설치하거나 업그레이드할 때 발생합니다.

참고:

MX-SPC3는 추상화된 패브릭 인터페이스를 지원하지 않습니다. 따라서 MX-SPC3 카드가 연결된 GNF에는 라인 카드도 연결되어 있어야 합니다.

Junos 노드 슬라이싱과 논리 시스템 비교

Junos Node Slicing은 Junos의 논리적 시스템 아래에 있는 레이어입니다. 두 기술 모두 일부 중복되는 기능을 가지고 있지만 다른 측면에서 다릅니다. Junos Node Slicing을 사용하면 전체 라인 카드와 물리적 인터페이스가 GNF에 할당되는 반면, 논리적 시스템에서는 물리적 인터페이스를 통해 정의된 여러 논리적 인터페이스가 모두 별도의 논리적 시스템에 할당될 수 있기 때문에 단일 물리적 인터페이스 자체를 서로 다른 논리적 시스템 간에 공유할 수 있습니다. 즉, 논리적 시스템은 Junos Node Slicing보다 더 세밀하게 공유할 수 있습니다. 그러나 모든 논리적 시스템은 단일 Junos 커널을 공유하므로 라우팅 엔진과 라인 카드의 물리적 리소스(예: CPU, 메모리, 스토리지)를 공유해야 하는 것 외에도 동일한 Junos 버전을 실행해야 합니다. Junos Node Slicing을 사용하면 각 GNF는 해당 GNF 전용 라인 카드와 마찬가지로 한 쌍의 라우팅 엔진에 해당하는 고유한 기능을 갖게 되므로 GNF는 대부분의 물리적 리소스를 공유하지 않고 섀시와 스위치 패브릭만 공유합니다. 논리적 시스템과 달리 GNF는 MX 독립형 라우터처럼 독립적으로 업그레이드하고 관리할 수 있습니다.

Junos Node Slicing은 GNF 자체에 여러 논리 시스템을 가질 수 있으므로 논리 시스템을 보완하고 심지어 보강하는 기술입니다. 물리적 격리, 보장된 리소스 및 완전한 관리 격리가 가장 중요한 경우 Junos Node Slicing이 더 적합합니다. 그리고 논리적 인터페이스 수준까지 세분화된 공유가 가장 중요한 경우 논리적 시스템이 더 잘 일치할 것입니다.

Junos 노드 슬라이싱에 대한 라이선스

Junos Node Slicing을 운영하려면 BSYS에 설치할 GNF 및 추상화된 패브릭 인터페이스에 대한 라이선스가 필요합니다. BSYS에 설치된 라이선스 없이 GNF를 실행하면 다음과 같은 syslog 메시지와 사소한 알람이 발생합니다.

Junos Node Slicing 라이선스와 관련된 문의 사항이 있는 경우 주니퍼 네트웍스에 문의하십시오.

관련 설명서