Acano 및 Cisco Meeting Server(CMS)의 IP 라우팅 규칙

소개

이 문서에서는 Acano 또는 Cisco Meeting Server(CMS) 서버의 IP 라우팅 규칙에 대해 설명합니다. Acano 또는 CMS 서버는 각각 고유한 기본 게이트웨이가 있는 여러 인터페이스를 구성할 수 있습니다.

사전 요구 사항

요구 사항

다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

• CMS 구성 요소: 
  • 웹 브리지(WB)
  • NAT(TURN) 서버 주변의 릴레이를 사용한 이동
  • 콜브리지(CB)
• 기본 IP 라우팅

사용되는 구성 요소

이 문서의 정보는 버전 2.3.x의 Cisco Meeting Server를 기반으로 합니다.

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

배경 정보

여기서 유일한 제한은 4포트 스위치의 서로 다른 인터페이스가 서로 다른 서브넷에 있어야 한다는 것입니다. 그렇지 않으면 설정에 라우팅 문제가 발생할 수 있습니다. 그에 대한 예외로, ADMIN 인터페이스가 있는 하드웨어 X 서버는 CMS 설치 설명서에 설명되고 이 메모에 표시된 대로 다른 인터페이스(A/B/C/D) 중 하나와 동일한 서브넷에서 이 ADMIN 인터페이스를 가질 수 있습니다.

참고: Cisco Meeting Server의 두 인터페이스는 동일한 서브넷에 둘 수 없습니다. 유일한 예외는 물리적 Acano X-Series 서버의 ADMIN 인터페이스가 다른 인터페이스(A~D) 중 하나와 동일한 서브넷에 있을 수 있으며, 이는 아마도 일반적인 구축일 것입니다.

TURN 서버 구성 요소에서 Binding Requests(바인딩 요청)를 받을 때 라우팅 로직을 알아야 하는 상황이 발생할 수 있습니다. 예를 들어 어떤 인터페이스에서 응답이 전송되는지 확인할 수 있습니다.

Acano/CMS 서버에는 어떤 IP 라우팅 규칙이 적용됩니까?

IP 라우팅 로직은 연결이 UDP(User Datagram Protocol)인지 TCP(Transmission Control Protocol)인지에 따라 달라집니다.
TCP의 경우, 새로운 연결이든 인바운드 연결에 대한 응답이든 이미지의 순서도를 사용하여 어떤 IP 라우팅 논리를 케이스에 적용할 수 있는지 확인할 수 있습니다.

인바운드 TCP 연결 응답

Acano/CMS 서버는 요청이 수신된 인터페이스 자체에서 인바운드 TCP 연결에 대해 응답합니다(이미 TCP 연결이 있으므로).

아웃바운드 TCP 연결 또는 모든 아웃바운드 UDP 패킷

두 시나리오 모두 이 순서도에 따라 이러한 IP 라우팅 규칙이 적용됩니다(또한 인바운드 TCP 연결 회신에 대한 첫 번째 단계).

참고: 이 논리는 새 아웃바운드 UDP 패킷 생성 또는 수신된 패킷에 대한 응답으로 전송되는 패킷에 적용됩니다.

모든 IP 라우팅 테이블을 표시하는 방법(인터페이스당)

MMP(Mainboard Management Processor)에서 ipv4 <interface> 명령을 사용합니다.

이를 통해 구성된 IP 주소 및 접두사 길이와 이 이미지에 표시된 대로 이 인터페이스에 대해 설정된 모든 고정 경로를 확인할 수 있습니다.

예를 들어, 8.8.8.8/32 및 8.8.4.4/32에 대한 경로는 이 특정 인터페이스에서 명시적으로 나가도록 설정됩니다(a).

eth4에 매핑되는 해당 인터페이스(A)에 대해 live.json 파일에 추가된 경로도 볼 수 있습니다.

    "ipv4": {
        "module": {
            "interfaces": {
                "eth4": {
                    "dhcp": "false",
                    "enabled": "true",
                    "default": "true",
                    "macaddress": "00:50:56:99:5A:5B",
                    "address": "10.48.54.160",
                    "prefixlen": "24",
                    "gateway": "10.48.54.200",
                    "routes": {
                        "8=8=8=8-32": {
                            "address": "8.8.8.8",
                            "prefixlen": "32"
                        },
                        "8=8=4=4-32": {
                            "address": "8.8.4.4",
                            "prefixlen": "32"
                        }
                    }

참고: live.json 파일에서 인터페이스 A-D(MMP)는 eth4-eth1에 매핑되므로 인터페이스 A는 eth4에 매핑되고 인터페이스 D는 eth1에 매핑됩니다. 다른 스니펫은 X-Series 서버의 스니펫으로, ADMIN 인터페이스가 다른 인터페이스에 표시된 모듈 대신 ipv4 아래 mmp의 섹션에 있는 것을 볼 수 있습니다.

    "ipv4": {
        "mmp": {
            "interfaces": {
                "eth0": {
                    "macaddress": "44:4A:65:00:13:00",
                    "dhcp": "false",
                    "enabled": "true",
                    "default": "true",
                    "address": "10.48.79.72",
                    "prefixlen": "24",
                    "gateway": "10.48.79.200"
                }

특정 인터페이스에 고정 경로를 추가하거나 삭제하려면 ipv4 <interface> route 명령을 사용할 수 있습니다(add | del) <address>/<prefix length>.

기본 인터페이스를 확인하고 변경하는 방법?

빈 컨피그레이션으로 시작할 경우 기본적으로 인터페이스 A가 기본 인터페이스입니다.

이 이미지에 강조 표시된 기본 매개변수로 인터페이스에서 이를 확인할 수 있습니다.

MMP에 대한 ipv4 <interface> 명령의 출력입니다.

참고: 이 값이 true로 설정된 경우 이 인터페이스는 이미지에서와 같은 기본 인터페이스입니다.

live.json에서 인터페이스 A(eth4에 매핑)가 기본 인터페이스로 설정되었는지 확인할 수도 있습니다.

    "ipv4": {
        "module": {
            "interfaces": {
                "eth4": {
                    "dhcp": "false",
                    "enabled": "true",
                    "default": "true",
                    "macaddress": "00:50:56:99:5A:5B",
                    "address": "10.48.54.160",
                    "prefixlen": "24",
                    "gateway": "10.48.54.200",
                    "routes": {
                        "8=8=8=8-32": {
                            "address": "8.8.8.8",
                            "prefixlen": "32"
                        },
                        "8=8=4=4-32": {
                            "address": "8.8.4.4",
                            "prefixlen": "32"

기본 인터페이스를 변경하려면 ipv4 <interface> default 명령을 사용할 수 있지만, 이 변경을 수용할 수 있는 올바른 고정 경로가 있는지 확인하십시오. 그렇지 않으면 라우팅이 영향을 받습니다.

예:

Image(이미지)는 다음과 같은 요구 사항이 있는 Core 서버와 Edge 서버가 하나씩 있는 단일 분할 서버 설정의 예를 나타냅니다.

• 코어 서버는 DMZ 인터페이스(A)에만 연결할 수 있고 공용 인터페이스(C & D)에는 연결할 수 없습니다.
• TURN 서버 구성 요소는 WebBridge와 마찬가지로 443에서 수신해야 합니다(따라서 포트 충돌을 피하기 위해 서로 다른 인터페이스가 필요함).

이 예에서는 특별한 라우팅이 설정되지 않았고 다른 기본 인터페이스가 지정되지 않았으므로 Edge 서버의 인터페이스 A가 기본값으로 설정됩니다.

상황:

• WebRTC 클라이언트가 로그인할 수 있지만 통화가 실패합니다.
• CB에서 TURN 서버로 요청을 바인딩하고 할당하면 성공 응답이 생성됩니다
• 외부 WebRTC 클라이언트의 요청을 TURN 서버에 바인딩 및 할당하지만 성공 응답 수신 못함

설명:

• WB 및 LB(Loadbalancer)는 인바운드 TCP 연결에만 응답하고 아웃바운드 연결을 자체적으로 시작하지 않으므로 이 라우팅에 문제가 발생하지 않습니다.

참고: 두 서비스가 동일한 서버에 있으므로 WB가 LB에 아웃바운드 연결을 설정할 수 있지만 이는 내부적으로 발생합니다.

• 또한 CB에서 TURN 서버 DMZ IP로의 Binding and Allocate Requests는 동일한 서브넷(에지 인터페이스 A와 코어 인터페이스 A)에 있거나 고정 경로가 설정되어 있지 않고 기본 인터페이스(이 경우 인터페이스 A)에서 보내기만 하므로 응답되지 않습니다.
• 외부 바인딩 및 할당 요청의 경우 고정 경로가 없으므로 기본 인터페이스 A를 사용하여 트래픽을 라우팅합니다(외부 클라이언트에 도달하지 않음).

해결책:

• 에지 서버에 인터페이스 B를 추가하고 내부 WB 연결(뿐만 아니라 LB)에 인터페이스 A를 사용하고 내부 TURN 서버 연결에 인터페이스 B를 사용합니다(443 상의 포트 충돌이 TURN 및 WB 모두에 사용되는 것을 방지하기 위해). MMP의 다음 명령으로 이를 구성하고, callbridges의 TURN 컨피그레이션을 인터페이스 B의 새 serverAddress에 맞게 수정합니다.

ipv4 b add <IP-address>/<prefix length> <default-gateway>
ipv4 b 활성화

사용 안 함
턴 리스너 d b
턴 활성화

• 다음 명령을 사용하여 에지 서버에서 내부 코어 서버로 트래픽을 라우팅하는 고정 경로를 추가합니다.
    
    ipv4 b 경로 추가 <주소>/<접두사 길이>

참고: LB 및 WB는 인바운드 TCP 연결에서만 반응하므로 TURN에 대한 UDP 패킷의 라우팅만 설정하면 되므로 인터페이스 B에서 이를 수행합니다. 또한 인터페이스 B의 게이트웨이가 CB로 라우팅할 수 있는지 확인합니다.

예를 들어 코어 서버에 IP 주소 192.168.0.100/24이 있는 경우 이 명령은 ipv4 b route add 192.168.0.100/24 또는 ipv4 b route add 192.168.0.100/32이어야 합니다.

• 외부 TURN 서버 인터페이스(D)를 트래픽의 기본 인터페이스로 만듭니다.

ipv4 d 기본값

다음을 확인합니다. 

현재 이 설정에 사용 가능한 확인 절차는 없습니다.

문제 해결 

현재 이 구성에 사용할 수 있는 특정 문제 해결 정보가 없습니다.

관련 정보 

• 기술 지원 및 문서 − Cisco Systems
• 협업 솔루션 분석기 툴 
• CMS 문서