- 홈
- /
- 문서
로컬 게이트웨이 (LGW) 는 Cisco Webex Calling 고객에게 온프레미스 PSTN 액세스를 제공하는 독점 솔루션이에요.이 문서는 활성 통화의 상태 저장 페일오버를 보장하기 위해 활성 또는 대기 CUBE와 함께 CUBE 고가용성을 사용하여 로컬 게이트웨이를 구성하는 방법을 안내해요.
펀더멘털은
전제조건
Cisco Unified Border Element(CUBE) 고가용성 (HA) 을 로컬 게이트웨이로 배포하기 전에 다음 개념을 깊이 이해해야 해요. Webex Calling
-
스테이트풀 콜 보존을 위한 CUBE Enterprise를 통한 레이어 2 박스 리던던시
이 문서에 제공된 구성 지침은 기존 음성 구성이 없는 전용 로컬 게이트웨이 플랫폼을 가정해요. 기존 CUBE Enterprise 배포를 로컬 게이트웨이 기능도 활용하도록 수정하려는 경우Cisco Webex Calling, 기존 통화 흐름과 기능이 중단되지 않도록 적용된 구성에 세심한 주의를 기울이고 CUBE HA 설계 요구 사항을 준수하는지 확인하세요.
하드웨어 및 소프트웨어 구성 요소
큐브 HA를 로컬 게이트웨이로 사용하려면 IOS-XE 버전 17.9.1 이상이 필요하고 큐브 HA와 LGW 기능이 모두 지원되는 플랫폼이 필요해요.
이 기사의 show 명령과 로그는 VCube (CSR 8000v) 에 구현된 Cisco IOS -XE 17.9.1의 최소 소프트웨어 릴리스를 기반으로 해요.
참조 자료
다음은 다양한 플랫폼에 대한 자세한 CUBE HA 구성 가이드예요.
-
시스코 프리퍼드 아키텍처용 Cisco Webex Calling — https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Webex Calling솔루션 개요
Cisco Webex Calling온 프레미스 PBX 전화 서비스에 대한 멀티 테넌트 클라우드 기반 대안을 고객에게 여러 PSTN 옵션과 함께 제공하는 협업 제품이에요.
로컬 게이트웨이 배포 (아래 참조) 가 이 기사의 초점이에요. 로컬 게이트웨이 (프레미스 기반 PSTN) 트렁크 인을 Webex Calling 통해 고객 소유 PSTN 서비스에 연결할 수 있어요. 또한 다음과 같은 온프레미스 IP PBX 배포에 대한 연결성을 제공해요. Cisco Unified CM 클라우드와의 모든 통신은 SIP의 경우 TLS 전송, 미디어의 경우 SRTP를 사용하여 보호돼요.
아래 그림은 기존 IP PBX가 없는 Webex Calling 배포를 보여 주며 단일 또는 다중 사이트 배포에 적용할 수 있어요. 이 기사에 설명된 구성은 이 배포를 기반으로 해요.
레이어 2 박스 투 박스 리던던시
CUBE HA 레이어 2 박스 투 박스 리던던시는 리던던시 그룹 (RG) 인프라 프로토콜을 사용하여 액티브/스탠바이 라우터 쌍을 구성해요. 이 쌍은 각각의 인터페이스에서 동일한 가상 IP 주소 (VIP) 를 공유하고 상태 메시지를 계속 교환해요. 한 쌍의 라우터에서 CUBE 세션 정보가 체크포인팅되어 활성 라우터가 서비스가 중단되면 대기 라우터가 모든 CUBE 통화 처리 책임을 즉시 넘겨받아 시그널링과 미디어를 상태 저장 보존해요.
체크 포인팅은 미디어 패킷과 연결된 통화로 제한돼요. 전송 중인 전화는 체크포인트가 아니에요 (예: 시도 중이거나 벨이 걸려오는 상태).
이 기사에서 CUBE HA는 상태 저장 통화 보존을 위해 CUBE 고가용성 (HA) 레이어 2 박스 투 박스 (B2B) 이중화를 언급할 거예요.
IOS-XE 17.9.1부터 CUBE HA를 Cisco Webex Calling 트렁크 배포를 위한 로컬 게이트웨이 (프레미스 기반 PSTN) 로 배포할 수 있어요. 이 기사에서는 설계 고려 사항 및 구성에 대해 설명합니다. 그림은 전형적인 CUBE HA 설정을 Cisco Webex Calling 트렁크 배포용 로컬 게이트웨이로 보여 줘요.
리던던시 그룹 인프라 컴포넌트
리던던시 그룹 (RG) 인프라 구성 요소는 두 CUBE 간의 박스 투 박스 통신 인프라 지원을 제공하고 안정적인 최종 리던던시 상태를 협상해요. 이 구성 요소는 또한 다음을 제공해요.
-
제어 인터페이스를 통해 두 CUBE 간에 keepalive 메시지와 hello 메시지를 교환하여 각 라우터의 최종 중복 상태를 협상하는 HSRP와 비슷한 프로토콜이에요. 위 그림의 기가비트 이더넷3예요.
-
액티브 라우터에서 스탠바이 라우터로 (데이터 인터페이스를 통해) 각 통화의 신호 및 미디어 상태를 체크포인팅하는 전송 메커니즘—위 그림의 기가비트 이더넷3예요.
-
트래픽 인터페이스용 가상 IP (VIP) 인터페이스 구성 및 관리 (동일한 RG 그룹을 사용하여 여러 트래픽 인터페이스를 구성할 수 있음) — 기가비트 이더넷 1과 2는 트래픽 인터페이스로 간주돼요.
이 RG 구성 요소는 음성 B2B HA를 지원하도록 특별히 구성해야 해요.
시그널링과 미디어 모두를 위한 가상 IP (VIP) 주소 관리
B2B HA는 이중화를 위해 VIP를 사용해요. CUBE HA 쌍의 두 CUBE에 있는 VIP와 관련 물리적 인터페이스는 동일한 LAN 서브넷에 있어야 해요. 음성 B2B HA 지원에는 VIP 구성과 VIP 인터페이스를 특정 음성 애플리케이션 (SIP) 에 바인딩하는 것이 필수예요. Webex Calling액세스 SBCUnified CM, 서비스 제공자 또는 프록시와 같은 외부 장치는 CUBE HA 라우터를 통과하는 통화의 대상 IP 주소로 VIP를 사용해요. 따라서 Webex Calling 관점에서 보면 CUBE HA 쌍이 단일 로컬 게이트웨이 역할을 해요.
설정된 통화의 통화 시그널링 및 RTP 세션 정보가 액티브 라우터에서 대기 라우터로 체크포인팅돼요. 액티브 라우터가 다운되면 스탠바이 라우터가 이어받아 이전에 첫 번째 라우터에서 라우팅한 RTP 스트림을 계속 전달해요.
페일오버 시 일시적 상태인 통화는 전환 후 보존되지 않아요. 예를 들어, 아직 완전히 설정되지 않았거나 전송 또는 보류 기능으로 수정 중인 통화예요. 전환 후 설정된 통화 연결이 끊길 수 있어요.
CUBE HA를 상태 저장 통화 페일오버를 위한 로컬 게이트웨이로 사용하려면 다음과 같은 요구 사항이 있어요.
-
큐브 HA는 TDM이나 아날로그 인터페이스를 같은 위치에 둘 수 없어요
-
Gig1과 Gig2는 트래픽 (SIP/RTP) 인터페이스라고 하고 Gig3은 리던던시 그룹 (RG) 제어/데이터 인터페이스예요
-
동일한 레이어 2 도메인에 CUBE HA 쌍을 2개 이상 배치할 수 없어요. 하나는 그룹 ID가 1이고 다른 하나는 그룹 ID 2예요. 동일한 그룹 ID로 2개의 HA 쌍을 구성하는 경우, RG 제어/데이터 인터페이스가 다른 레이어 2 도메인 (VLAN, 별도의 스위치) 에 속해야 해요.
-
포트 채널은 RG 제어/데이터 및 트래픽 인터페이스 모두에서 지원돼요.
-
모든 시그널링/미디어는 가상 IP 주소에서 송수신돼요
-
CUBE-HA 관계에서 플랫폼이 다시 로드될 때마다 항상 스탠바이 모드로 부팅돼요
-
모든 인터페이스 (Gig1, Gig2, Gig3) 의 하위 주소는 같은 플랫폼에 있어야 해요
-
리던던시 인터페이스 식별자, rii는 동일한 레이어 2에 있는 쌍/인터페이스 조합에 고유해야 해요
-
물리적 구성을 포함하여 두 CUBE의 구성이 동일해야 하고 같은 유형의 플랫폼과 IOS-XE 버전에서 실행되어야 해요.
-
루프백 인터페이스는 항상 가동되기 때문에 바인드로 사용할 수 없어요.
-
다중 트래픽 (SIP/RTP) 인터페이스 (Gig1, Gig2) 를 사용하려면 인터페이스 추적을 구성해야 해요
-
RG-컨트롤/데이터 링크 (Gig3) 의 크로스오버 케이블 연결로는 CUBE-HA가 지원되지 않아요.
-
CUBE HA가 작동하려면 두 플랫폼이 동일해야 하고 마찬가지로 모든 인터페이스에서 물리적 스위치를 통해 연결되어야 해요. CUBE-1 및 CUBE-2 GE0/0/0은 같은 스위치에서 종료해야 하고 그런 식이에요.
-
CUBE에서 직접 WAN을 종료하거나 양쪽의 데이터 HA를 종료할 수 없어요.
-
액티브/스탠바이 모두 같은 데이터 센터에 있어야 해요
-
이중화를 위해 별도의 L3 인터페이스 (RG 제어/데이터, Gig3) 를 사용해야 해요. 즉 트래픽에 사용되는 인터페이스는 HA 킵얼라이브 및 체크포인팅에 사용할 수 없어요.
-
페일오버 시, 이전에 활성화된 CUBE가 신호 처리와 미디어를 보존하면서 설계상 재로드를 거치게 돼요
두 CUBE 모두에 이중화를 구성하세요
가상 IP를 불러오는 데 HA 쌍으로 사용되도록 양쪽 CUBE에 레이어 2 박스 간 이중화를 구성해야 해요.
| 1 |
글로벌 수준에서 인터페이스 추적을 구성하여 인터페이스 상태를 추적하세요.
Track CLI는 RG에서 음성 트래픽 인터페이스 상태를 추적하는 데 사용돼서 트래픽 인터페이스가 다운된 후에도 활성 경로가 제 역할을 하게 돼요. | ||
| 2 |
애플리케이션 이중화 하위 모드에서 VoIP HA와 함께 사용할 RG를 구성하세요.
다음은 이 구성에 사용된 필드에 대한 설명이에요.
| ||
| 3 |
CUBE 애플리케이션에 박스 투 박스 리던던시를 활성화하세요. RG를 아래
redundancy-group 1 —이 명령을 추가하고 제거하려면 업데이트된 구성을 적용하려면 다시 로드해야 해요. 모든 구성이 적용된 후에 플랫폼을 다시 로드할 거예요. | ||
| 4 |
아래 그림과 같이 Gig1과 Gig2 인터페이스를 각각의 가상 IP로 구성하고 리던던시 인터페이스 식별자 (rii) 를 적용하세요.
다음은 이 구성에 사용된 필드에 대한 설명이에요.
| ||
| 5 |
첫 번째 CUBE의 구성을 저장하고 다시 로드하세요. 마지막으로 다시 로드하는 플랫폼은 항상 대기 모드예요.
VCUBE-1 완전히 부팅한 후에 VCUBE-2 구성을 저장하고 다시 로드하세요.
| ||
| 6 |
박스-투-박스 구성이 예상대로 작동하는지 확인하세요. 관련 출력은 굵게 표시돼요. VCUBE-2 마지막으로 다시 로드했고 설계 고려 사항에 따라 마지막으로 다시 로드할 플랫폼은 항상 대기중이에요.
다음으로, 두 HA CUBE 모두에서 로컬 게이트웨이 구성 (등록 기반 또는 인증서 기반) 을 진행하세요. 에 대해 Cisco IOSXE에서 로컬 게이트웨이 구성을 참조하세요 Webex Calling. |