MMP(Multichassis Multilink PPP)

소개

이 문서에서는 Cisco Systems의 액세스 서버 플랫폼에서 스택 또는 멀티섀시 환경(MMP라고도 함, 멀티섀시 멀티링크 PPP용)에서 MP(Multilink PPP)를 지원하는 방법에 대해 설명합니다.

사전 요구 사항

요구 사항

이 문서에 대한 특정 요건이 없습니다.

사용되는 구성 요소

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

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

관련 용어

이 문서에서 사용하는 용어 용어집입니다.

• 액세스 서버 - 원격 액세스를 제공하는 ISDN 및 비동기 인터페이스를 포함하는 Cisco 액세스 서버 플랫폼입니다.

• L2F - L2(Layer 2) 전달 프로토콜(실험적 초안 RFC). 이는 멀티섀시 MP 및 VPN 모두에 대한 기본 링크 레벨 기술입니다.

• Link(링크) - 시스템이 제공하는 연결 지점입니다. 링크는 전용 하드웨어 인터페이스(예: 비동기식 인터페이스) 또는 멀티채널 하드웨어 인터페이스(예: PRI 또는 BRI)의 채널일 수 있습니다.

• MP - 멀티링크 PPP 프로토콜(RFC 1717 참조)

• 멀티섀시 MP - MP + SGBP + L2F + Vtemplate.

• PPP—포인트-투-포인트 프로토콜(RFC 1331 참조)

• Rotary Group(로터리 그룹) - 전화를 걸거나 받기 위해 할당된 물리적 인터페이스의 그룹입니다. 이 그룹은 임의의 링크를 사용하여 전화를 걸거나 받을 수 있는 풀 역할을 합니다.

• SGBP - 스택 그룹 입찰 프로토콜.

• Stack Group(스택 그룹) - 그룹으로 작동하고 다른 시스템의 링크가 포함된 MP 번들을 지원하도록 구성된 둘 이상의 시스템 모음입니다.

• VPDN - 가상 사설 전화 접속 네트워크 ISP(Internet Service Provider)에서 Cisco 홈 게이트웨이로 PPP 링크 전달.

• Vtemplate - 가상 템플릿 인터페이스입니다.

참고: 이 문서에서 참조하는 RFC에 대한 자세한 내용은 Cisco IOS Release 11.3-No. 523, 제품 게시판에서 지원되는 RFC 및 기타 Stds를 참조하십시오. RFC 및 표준 문서 가져오기 또는 InterNIC 에 직접 연결하는 RFC 인덱스

표기 규칙

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

문제 정의

MP는 여러 링크가 형성하는 논리적 파이프(번들) 간에 패킷을 분할하고 재결합할 수 있는 기능을 통해 필요에 따라 추가 대역폭을 제공합니다.

이는 느린 WAN 링크 전반의 전송 레이턴시를 줄이고, 최대 수신 유닛을 늘릴 수 있는 방법도 제공합니다.

송신단에서 MP는 단일 패킷을 여러 패킷으로 단편화하여 여러 PPP 링크를 통해 전송하도록 지원합니다. 수신단에서 MP는 여러 PPP 링크에서 다시 원래 패킷으로 패킷을 재결합합니다.

Cisco는 자동 종단 시스템에 대한 MP를 지원합니다. 즉, 동일한 클라이언트의 여러 MP 링크가 액세스 서버에서 종료될 수 있습니다. 그러나 예를 들어 ISP는 여러 액세스 서버에서 단일 회전 번호를 여러 PRI에 편리하게 할당하고 서버 구조를 비즈니스 요구에 맞게 확장 가능하고 유연하게 만드는 것을 선호합니다.

Cisco IOS® Software Release 11.2에서는 Cisco가 이러한 기능을 제공하므로 동일한 클라이언트의 여러 MP 링크가 서로 다른 액세스 서버에서 종료될 수 있습니다. 동일한 번들의 개별 MP 링크가 실제로 서로 다른 액세스 서버에서 종료될 수 있지만, MP 클라이언트에 관한 한 단일 액세스 서버에서 종료되는 것과 유사합니다.

이러한 목표를 달성하기 위해 MP는 멀티섀시 MP를 사용합니다.

기능 개요

그림 1은 단일 Cisco 액세스 서버에서 MP를 사용하여 이 기능을 지원하는 방법을 보여줍니다.

그림 1 - 단일 Cisco 액세스 서버의 MP

그림 1은 MP 멤버 인터페이스가 번들 인터페이스에 연결되는 방법을 보여줍니다. 멀티섀시 MP가 활성화되지 않은 독립형 시스템에서는 멤버 인터페이스가 항상 물리적 인터페이스입니다.

스태킹된 환경을 지원하려면 MP 외에도 다음 세 가지 하위 구성 요소가 추가로 필요합니다.

• SGBP

• Vtemplate

• L2F

이 문서의 다음 섹션에서는 이러한 구성 요소에 대해 자세히 설명합니다.

SGBP

다중 액세스 서버 환경에서 네트워크 관리자는 스택 그룹에 속할 액세스 서버 그룹을 지정할 수 있습니다.

스택 그룹이 시스템 A와 시스템 B로 구성되어 있다고 가정합니다. userx라는 원격 MP 클라이언트는 시스템 A에서 첫 번째 MP 링크가 종료됩니다(systema). 번들 userx는 시스템에서 구성됩니다. 이제 userx의 다음 MP 링크가 시스템 B(시스템)에서 종료됩니다. SGBP는 시스템에서 userx가 상주하는 번들을 찾습니다. 이때 또 다른 구성 요소인 L2F는 두 번째 MP 링크를 시스템에서 시스템으로 투영합니다. 그런 다음 예상 MP 링크가 시스템에서 번들에 조인합니다.

따라서 SGBP는 정의된 스택 그룹 내에서 스택 멤버의 번들 위치를 찾습니다. SGBP는 또한 번들 생성을 위해 지정된 스택 멤버에 대해 중재합니다. 이 예에서 시스템에서 첫 번째 MP 링크가 수신되면 시스템 및 시스템(및 스택 그룹의 다른 모든 멤버)이 실제로 번들 생성을 위해 입찰합니다. SGBP에서 번들 생성을 위해 지정하므로 시스템의 입찰이 더 높습니다(첫 번째 링크를 수락했기 때문).

SGBP 입찰 프로세스에 대한 이 설명은 다소 단순합니다. 실제로 스택 멤버에서 SGBP 입찰은 지역, 사용자 구성 가능한 가중치 메트릭, CPU 유형, MP 번들 수 등의 함수입니다. 이 입찰 프로세스에서는 액세스 인터페이스가 없는 시스템이라도 지정된 시스템에서 번들을 생성할 수 있습니다. 예를 들어, 스택 환경은 10개의 액세스 서버 시스템과 2개의 4500(스택 멤버 12개로 구성된 스택 그룹)으로 구성될 수 있습니다.

참고: 두 4500과 같이 입찰이 동일할 경우 SGBP는 무작위로 입찰의 낙찰자를 지정합니다. 4500이 항상 다른 스택 멤버보다 우수하도록 구성할 수 있습니다. 따라서 4500s는 MP 패킷 프래그멘터 및 리어셈블러에 특화된 오프로드 멀티섀시 MP 서버가 됩니다. 이는 액세스 서버에 비해 CPU 전력이 더 높은 데 적합한 작업입니다.

간단히 말해, SGBP는 멀티섀시 MP의 위치 및 중재 메커니즘입니다.

가상 액세스 인터페이스

가상 액세스 인터페이스는 번들 인터페이스(그림 1 및 그림 2 참조)와 예상 PPP 링크(그림 2 참조)의 역할을 모두 합니다. 이러한 인터페이스는 동적으로 생성되며 온디맨드 방식으로 시스템에 반환됩니다.

가상 템플릿 인터페이스는 가상 액세스 인터페이스가 복제된 구성 정보의 저장소 역할을 합니다. 다이얼러 인터페이스 컨피그레이션은 컨피그레이션 정보의 또 다른 소스로 사용됩니다. 가상 액세스 인터페이스를 복제할 구성 소스를 선택하는 방법은 MMP(Multichassis Multilink PPP)(2부)에서 명확해집니다.

L2F

L2F는 지정된 최종 시스템에 대한 실제 PPP 링크 투영을 제공합니다.

L2F는 원격 클라이언트가 식별되는 인증 단계까지 표준 PPP 작업을 수행합니다. 인증 단계는 로컬로 완료되지 않습니다. SGBP에서 대상 스택 구성원과 함께 제공되는 L2F는 대상 스택 구성원에 대한 PPP 링크를 예상합니다. 여기서 인증 단계가 재개되고 예상 PPP 링크에서 완료됩니다. 최종 인증 성공 또는 실패는 대상 스택 멤버에서 수행됩니다.

수신 통화를 수락한 원래 물리적 인터페이스는 L2F 전달된다고 합니다. L2F가 동적으로 생성하는 해당 인터페이스(PPP 인증 성공 시)는 예상 가상 액세스 인터페이스입니다.

참고: 투영된 가상 액세스 인터페이스도 가상 템플릿 인터페이스(정의된 경우)에서 복제됩니다.

그림 2에서는 systema, systemb 및 systemc로 구성된 스택 그룹 stackq에 대해 설명합니다.

그림 2 - 클라이언트가 스택에 호출

1. 클라이언트 사용자 X 통화 시스템의 첫 번째 링크가 통화를 수신합니다. SGBP는 스택 그룹 멤버 중 존재하는 userx에 의한 번들을 찾으려고 시도합니다. 없는 경우 PPP에서 MP가 협상되므로 시스템에 번들 인터페이스가 생성됩니다.

2. 시스템이 userx로부터 두 번째 통화를 수신합니다. SGBP를 통해 번들이 상주하는 시스템이 무엇인지 확인할 수 있습니다. L2F는 시스템에서 시스템으로 링크를 전달합니다. 시스템에 예상 PPP 링크가 생성됩니다. 그런 다음 예상 링크가 번들 인터페이스에 조인됩니다.

3. 시스템이 userx로부터 세 번째 통화를 수신합니다. 다시 SGBP는 시스템이 번들이 있는 위치를 찾습니다. L2F는 시스템에서 시스템으로 링크를 전달하는 데 사용됩니다. 시스템에 예상 PPP 링크가 생성됩니다. 그런 다음 예상 링크가 번들 인터페이스에 조인됩니다.

참고: 번들 인터페이스는 시스템의 번들을 나타냅니다. 모든 고유한 발신자에 대해 동일한 발신자의 MP 멤버 인터페이스는 하나의 번들 인터페이스로 종료되거나 그로부터 시작됩니다.

최종 사용자 인터페이스

Vtemplate 사용자 인터페이스는 여기에서 명목상 지정됩니다. 자세한 내용은 가상 템플릿 기능 사양을 참조하십시오.

SGBP

1. sgbp 그룹 <이름>

   이 전역 명령은 스택 그룹을 정의하고, 그룹에 이름을 할당하며, 시스템을 해당 스택 그룹의 멤버로 만듭니다.

   참고: 스택 그룹은 전체적으로 하나만 정의할 수 있습니다.

   stackq라는 스택 그룹을 정의합니다.

   systema(config)#sgbp group stackq
   

   참고: 이제 PPP CHAP 챌린지 또는 시스템의 PPP PAP 요청에 stackq라는 이름이 사용됩니다. 액세스 서버에서 스택 그룹 이름을 정의할 때, 이 이름은 일반적으로 동일한 시스템에 대해 정의된 호스트 이름을 대체합니다.

2. sgbp 멤버 <peer-name> <peer-IP-address>

   이 전역 명령은 스택 그룹의 피어를 지정합니다. 이 명령에서 <peer-name>은 호스트 이름이고 <peer-IP-address>는 원격 스택 멤버의 IP 주소입니다. 따라서 자신을 제외한 스택의 모든 스택 그룹 멤버에 대한 항목을 정의해야 합니다. dns(Domain Name Server)는 피어 이름을 확인할 수 있습니다. DNS가 있는 경우 IP 주소를 입력할 필요가 없습니다.

   systema(config)#sgbp member systemb 1.1.1.2
   	
      systema(config)#sgbp member systemc 1.1.1.3 

3. sgbp seed-bid {기본값 | 오프로드 | 정방향 전용 | <0-9999>}

   스택 멤버가 번들에 대해 입찰하는 구성 가능한 중량입니다.

   모든 스택 멤버에 기본 매개변수가 정의된 경우 사용자 userx에 대한 첫 번째 호출을 받은 스택 멤버는 항상 bid를 획득하고 마스터 번들 인터페이스를 호스팅합니다. 동일한 사용자에서 다른 스택 멤버 프로젝트로 이 스택 멤버로 이어지는 모든 후속 호출입니다. sgbp seed-bid를 정의하지 않으면 기본값이 사용됩니다.

   오프로드가 정의된 경우, CPU 전력에서 번들 로드를 뺀 값으로 사전 조정된 플랫폼당 bid를 전송합니다.

   < 0-9999>가 구성된 경우 전송된 bid는 사용자가 구성한 값에서 번들 로드를 뺀 값입니다.

   번들 로드는 스택 멤버의 활성 번들 수로 정의됩니다.

   1. 여러 PRI에서 로터리 그룹의 통화를 받기 위해 스태킹된 등가 스택 멤버가 있는 경우 모든 스택 멤버에서 sgbp seed-bid default 명령을 실행합니다. 동일한 스택 멤버의 예는 4개의 AS5200으로 구성된 스택 그룹입니다. 사용자 userx에 대한 첫 번째 호출을 받은 스택 멤버는 항상 bid를 획득하고 마스터 번들 인터페이스를 호스팅합니다. 다른 스택 멤버에 대한 동일한 사용자에 대한 모든 후속 호출은 이 스택 멤버에 대해 프로젝트됩니다. 여러 통화가 여러 스택 멤버를 통해 동시에 들어오는 경우 SGBP 연결 해제 메커니즘이 연결을 끊습니다.

   2. 다른 스택 멤버에 비해 스택 멤버로 사용 가능한 고전력 CPU가 있는 경우 나머지 스택 멤버에 비해 상대적으로 높은 전력을 활용하고자 할 수 있습니다(예: 다른 유사한 스택 멤버에 비해 스택 멤버로 사용 가능한 고전력 CPU 하나 이상). 예를 들어, 4500 1개 및 AS5200 4개). sgbp seed-bid offload 명령을 사용하여 지정된 고전력 스택 멤버를 오프로드 서버로 설정할 수 있습니다. 이 경우 오프로드 서버는 마스터 번들을 호스팅합니다. 다른 스택 멤버의 모든 호출은 이 스택 멤버에 투영됩니다. 실제로 하나 이상의 오프로드 서버를 정의할 수 있습니다. 플랫폼이 동일하면(동일) 입찰가는 동일합니다. SGBP 타이 브레이킹 메커니즘은 타이를 해제하고 플랫폼 중 하나를 우승자로 지정합니다.

      참고: 서로 다른 두 플랫폼을 오프로드 서버로 지정하는 경우 CPU 전력이 더 높은 플랫폼이 입찰에서 이깁니다.

   3. 여러 플랫폼을 정렬했거나 정확히 동일한 플랫폼을 사용하고 하나 이상의 플랫폼을 오프로드 서버로 지정하려는 경우 sgbp seed-bid 9999 명령을 사용하여 bid 값을 나머지보다 상당히 높게 수동으로 설정할 수 있습니다. 예를 들어, 4700(가장 높은 시드 입찰가로 지정됨) 1개, 4000 2개, 7000 1개가 있습니다. 특정 플랫폼과 관련된 초기 입찰 값을 확인하려면 show sgbp를 사용합니다.

   4. 프런트엔드 스택 멤버가 하나 이상의 오프로드 서버로 항상 오프로드되는 멀티섀시 환경에서는 멀티링크 번들이 로컬로 형성되는 경우와 같이 프런트엔드 스택 멤버가 실제로 오프로드할 수 없는 경우가 있습니다. 예를 들어, 모든 오프로드 서버가 다운된 경우 이러한 상황이 발생할 수 있습니다. 네트워크 관리자가 수신 전화를 끊도록 선호하는 경우 sgbp seed-bid forward-only 명령을 실행합니다.

4. sgbp ppp-forward

   sgbp ppp-forward를 정의하면 PPP 및 MP 통화 모두 SGBP 입찰의 승자에게 예측됩니다. 기본적으로 MP 통화만 착신 전환됩니다.

5. sgbp 표시

   이 명령은 스택 그룹 멤버의 상태를 표시합니다. 상태는 ACTIVE, CONNECTING, WAITINFO 또는 IDLE일 수 있습니다. 각 스택 그룹 멤버의 ACTIVE가 최상의 상태입니다. CONNECTING 및 WAITINFO는 전환 상태이므로 ACTIVE로 전환할 때만 상태를 확인해야 합니다. IDLE(유휴)은 스택 그룹 시스템이 원격 스택 멤버 systemd를 감지할 수 없음을 나타냅니다. 예를 들어 유지 관리를 위해 systemd를 종료한 경우에는 걱정할 필요가 없습니다. 그렇지 않으면 이 스택 멤버와 시스템 간의 라우팅 문제 또는 기타 문제를 살펴봅니다.

   systema#show sgbp
     Group Name: stack Ref: 0xC38A529
     Seed bid: default, 50, default seed bid setting
   	
        Member Name: systemb State: ACTIVE  Id: 1
        Ref: 0xC14256F
        Address: 1.1.1.2 
   	
        Member Name: systemc State: ACTIVE  Id: 2
        Ref: 0xA24256D
        Address: 1.1.1.3 Tcb: 0x60B34439
   	
        Member Name: systemd State: IDLE Id: 3
        Ref: 0x0
        Address: 1.1.1.4 
   	

6. sgbp 쿼리 표시

   현재 시드 bid 값을 표시합니다.

   systema# show sgbp queries
     Seed bid: default, 50
   	
     systema# debug sgbp queries
     %SGBPQ-7-MQ:    Bundle: userX  State: Query_to_peers   OurBid: 050
     %SGBPQ-7-PB:    1.1.1.2 		State: Open_to_peer  Bid: 000  Retry: 0
     %SGBPQ-7-PB:    1.1.1.3		 State: Open_to_peer  Bid: 000  Retry: 0
     %SGBPQ-7-PB:    1.1.1.4		 State: Open_to_peer  Bid: 000  Retry: 0
     %SGBPQ-7-MQ:    Bundle: userX  State: Query_to_peers   OurBid: 050
     %SGBPQ-7-PB:    1.1.1.2		State: Rcvd     Bid: 000  Retry: 0
     %SGBPQ-7-PB:    1.1.1.3		State: Rcvd     Bid: 000  Retry: 0
     %SGBPQ-7-PB:    1.1.1.4		State: Rcvd     Bid: 000  Retry: 0
     %SGBPQ-7-DONE: Query #9 for bundle userX, count 1, master is local
   

mp

1. multilink 가상 템플릿 <1-9>

   MP 번들 인터페이스가 인터페이스 매개변수를 복제하는 데 사용되는 가상 템플릿 번호입니다. 다음은 MP가 가상 템플릿과 연결되는 방법의 예입니다. 가상 템플릿 인터페이스도 정의해야 합니다.

   systema(config)#multilink virtual-template 1
     systema(config)#int virtual-template 1
     systema(config-i)#ip unnum e0
     systema(config-i)#encap ppp
     systema(config-i)#ppp multilink
     systema(config-i)#ppp authen chap
   

2. show ppp multilink

   이 명령은 MP 번들에 대한 번들 정보를 표시합니다.

   systema#show ppp multilink
     Bundle userx 2 members, Master link is Virtual-Access4
     0 lost fragments, 0 reordered, 0 unassigned, 100/255 load
     0 discarded,  0 lost received, sequence 40/66 rcvd/sent
     members 2
       Serial0:4  
       systemb:Virtual-Access6    (1.1.1.2)
   

   이 예에서는 스택 그룹 stackq의 스택 그룹 멤버 시스템에서 해당 번들 userx의 번들 인터페이스가 Virtual-Access4로 설정되어 있음을 보여 줍니다. 두 멤버 인터페이스가 이 번들 인터페이스에 조인됩니다. 첫 번째는 로컬 PRI 채널이고 두 번째는 스택 그룹 멤버 시스템의 예상 인터페이스입니다.

예

다음 예를 보려면 MMP(Multichassis Multilink PPP)(2부)를 참조하십시오.

• 다이얼러가 포함된 스택에서의 AS5200

• 오프로드 서버 사용

• 물리적 인터페이스가 있는 오프로드 서버

• 비동기, 직렬 및 기타 비 다이얼러 인터페이스

• 멀티섀시에서 전화 걸기

• 멀티섀시 다이얼링

다음 섹션도 참조하십시오.

• 구성 및 제한 사항

• 문제 해결

관련 정보

• 다이얼 및 액세스 기술 지원 페이지
• 기술 지원 및 문서 − Cisco Systems