소개
이 문서에서는 Acano 또는 CMS(Cisco Meeting Server) 서버의 IP 라우팅 규칙에 대해 설명합니다.Acano 또는 CMS 서버는 여러 인터페이스를 구성할 수 있으며, 각 인터페이스는 고유한 기본 게이트웨이를 사용할 수 있습니다.
사전 요구 사항
요구 사항
다음 주제에 대한 지식을 보유하고 있으면 유용합니다.
- CMS 구성 요소:
- 웹 브리지(WB)
- NAT(TURN) 서버 주변 릴레이를 사용하는 접근
- CallBridge(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 패킷
두 시나리오 모두에서 이 흐름도(인바운드 TCP 연결 회신의 첫 번째 단계)에 따라 이러한 IP 라우팅 규칙이 적용됩니다.
참고:로직은 새 아웃바운드 UDP 패킷 생성 또는 수신된 패킷에 대한 응답으로 전송된 패킷에 적용됩니다.
모든 IP 라우팅 테이블(인터페이스당)을 표시하는 방법
MMP(Mainboard Management Processor)에서 ipv4 <interface> 명령을 사용합니다.
이를 통해 구성된 IP 주소 및 접두사 길이와 이 이미지에 표시된 대로 이 인터페이스에 대해 설정된 모든 고정 경로를 확인할 수 있습니다.
예를 들어, 8.8.8.8/32 및 8.8.4.4/32로의 경로는 이 특정 인터페이스(a)에서 명시적으로 내보내도록 설정됩니다.
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"
}
}
참고:live.json 파일에서 인터페이스 A-D(MMP의 인터페이스)는 eth4-eth1로 매핑되므로 인터페이스 A는 eth4에 매핑되고 인터페이스 D는 eth1에 매핑됩니다. 다른 코드 조각은 ADMIN 인터페이스가 다른 인터페이스에 표시된 모듈 대신 ipv4의 mmp 섹션에 있는 X-Series 서버의 조각입니다.
"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 명령을 사용할 수 있지만, 이 변경 사항을 수용할 올바른 고정 경로가 있는지 확인하십시오. 그렇지 않으면 라우팅이 영향을 받습니다.
예:
이 이미지는 다음과 같은 요구 사항이 있는 단일 코어 및 에지 서버를 사용하는 단일 분할 서버 설정의 예를 나타냅니다.
- 코어 서버는 DMZ 인터페이스(A)에만 연결할 수 있으며 공용 인터페이스(C & D)에는 연결할 수 없습니다.
- TURN 서버 구성 요소는 WebBridge와 마찬가지로 443에서 수신해야 합니다. 따라서 포트 충돌을 피하기 위해 서로 다른 인터페이스가 필요합니다.
이 예에서는 특별한 라우팅이 설정되지 않았으며 다른 기본 인터페이스가 지정되지 않았으므로 에지 서버의 인터페이스 A가 기본값으로 설정됩니다.
상황:
- WebRTC 클라이언트는 로그인할 수 있지만 호출이 실패했습니다.
- CB에서 TURN 서버에 대한 요청 바인딩 및 할당은 성공 응답을 가져옵니다.
- 외부 WebRTC 클라이언트에서 TURN 서버로 요청 바인딩 및 할당이 도착하지만 성공 응답을 가져오지 않습니다.
설명:
- WB 및 로드 밸런서(LB)는 인바운드 TCP 연결에만 응답하며 아웃바운드 연결을 직접 시작하지 않으므로 이 라우팅은 문제가 되지 않습니다.
참고:두 서비스가 모두 동일한 서버에 있으므로 WB는 여전히 LB에 아웃바운드 연결을 만들 수 있지만 내부적으로 발생합니다.
- 또한 CB에서 TURN 서버 DMZ IP로 바인딩 및 할당 요청은 동일한 서브넷(에지 인터페이스 A 및 코어 인터페이스 A)에 있거나 고정 경로가 설정되지 않고 기본 인터페이스(이 경우 인터페이스 A)에서 전송하기만 하면 응답됩니다.
- 외부 바인딩 및 할당 요청의 경우 정적 경로가 없으므로 기본 인터페이스 A를 사용하여 트래픽을 라우팅합니다(그러면 외부 클라이언트에 도달하지 않음).
해결책:
- 에지 서버에 인터페이스 B를 추가하고 내부 WB 연결에 인터페이스 A(LB 및 인터페이스 A)를 사용하고 내부 TURN 서버 연결에 인터페이스 B를 사용합니다(443의 포트 충돌을 방지하려면 TURN 및 WB 모두에 사용됩니다). MMP에서 다음 명령을 사용하여 이를 구성합니다. 또한 새 serverAddress(인터페이스 B의 주소)에 따라 통화 브리지의 TURN 컨피그레이션을 수정합니다.
ipv4 b <IP-address>/<prefix length> <default-gateway> 추가
ipv4 b 활성화
사용 안 함
수신 대기 d b
켜기
- 다음 명령을 사용하여 Edge 서버에서 내부 Core 서버로 트래픽을 라우팅하기 위한 고정 경로를 추가합니다.
ipv4 b 경로 추가 <주소>/<접두사 길이
참고:LB 및 WB는 인바운드 TCP 연결에만 반응하므로 TURN용 UDP 패킷에 대한 라우팅을 설정하기만 하면 됩니다. 따라서 인터페이스 B에서 이 작업을 수행할 수 있습니다. 또한 인터페이스 B의 게이트웨이가 이를 CB로 라우팅할 수 있는지 확인합니다.
예를 들어 코어 서버에 IP 주소가 192.168.0.100/24인 경우 명령은 ipv4 b 경로 추가 192.168.0.100/24 또는 ipv4 b 경로 추가 192.168.0.100/32여야 합니다.
- 외부 TURN 서버 인터페이스(D)를 트래픽의 기본 인터페이스로 만듭니다.
ipv4 d 기본
다음을 확인합니다.
현재 이 구성에 대해 사용 가능한 확인 절차가 없습니다.
문제 해결
현재 이 구성에 대해 사용 가능한 특정 문제 해결 정보가 없습니다.
관련 정보