목차

소개

TITAN 기본 사항

TITAN은 어떻게 작동합니까?

고정 인프라

설정

테스트 시나리오

메시 엔드 장애 조치

차량 라디오에서 장애 조치 테스트

문제 해결 TITAN

소개

이 문서에서는 CURWB 구축에서 TITAN의 사용, 구성 및 문제 해결에 대해 설명합니다.

TITAN 기본 사항

TITAN은 CURWB 구축에서 하드웨어 이중화를 통해 고가용성을 제공하는 중요한 기능입니다. 그것은 유동성 네트워크의 고정된 부분의 다양한 특징들에 걸쳐 구성될 수 있다. 가장 일반적인 애플리케이션은 코어 네트워크 글로벌 게이트웨이, 로컬 메시 엔드 게이트웨이 및 온보드 차량 무선 장치에서 TITAN을 활성화하는 것입니다. 레이어 2 및 레이어 3 네트워크에서 모두 작동합니다.

TITAN을 활성화하면 500밀리초 미만의 빠른 장애 조치를 기본 디바이스에서 보조 디바이스로 제공합니다. 보조 디바이스는 CURWB MPLS 통신을 즉시 재개합니다.

여기 보이는 예에서는 세 가지 조건 모두에서 TITAN 장애 조치를 보여줍니다.

- 코어 네트워크 글로벌 게이트웨이,

- 로컬 메시 엔드 게이트웨이,

- 온보드 차량 라디오

TITAN은 어떻게 작동합니까?

타이탄의 개념을 완전히 이해하기 위해서는 오토탭과 친해지는 것이 필수적이다. CUWRB 장치가 연결을 탐지하고 메시 엔드 또는 네트워크 코어와의 전용 인그레스/이그레스 경로만 허용하는 네트워크 루프 방지 메커니즘입니다.

동일한 패스프레이즈가 있는 무선 장치가 동일한 브로드캐스트 도메인의 동일한 네트워크 스위치에 연결되어 여러 안테나가 있는 단일 장치로 작동합니다.

CURWB Mesh Protocol은 무선 장치 간의 유선 연결을 탐지하며 경로는 자동으로 구축됩니다. 그 결과 여러 무선 인터페이스가 있는 단일 AP가 있는 것과 같습니다.

AutoTap 기능은 이러한 컨피그레이션에서 네트워크 루프를 방지합니다. 물리적으로 연결된 그룹에서 기본(최하위 숫자 메시 ID)으로 선택된 무선만 MAC 주소 정보를 게시합니다. 연결된 그룹의 기본 라디오로 선택된 라디오에서만 트래픽이 오는 것으로 보입니다.

고정 인프라

사용자는 동일한 구성으로 2개의 메시 엔드부를 설정하고 동일한 스위치에 연결합니다. 이러한 디바이스는 정보를 공유하여 기본 유닛을 선택하고 다른 유닛은 대기 상태가 됩니다. 장애가 발생하면 스탠바이 유닛이 500ms에 업무를 인계받아 모든 메시 포인트를 시스템에 다시 연결합니다. 고정 네트워크의 경우 TITAN은 메시 엔드 유닛에서만 활성화할 수 있으며, 포인트가 인수한 엔드와의 연결을 자동으로 설정합니다.

모빌리티 차량

프로세스는 고정 네트워크에서와 동일하며, 유닛은 동일한 구성의 동일한 스위치에 있어야 합니다. 알고리즘은 하나를 기본 유닛으로 설정하고 다른 하나를 보조 유닛으로 설정합니다. 기본 유닛에 장애가 발생할 경우 보조 유닛이 500ms에 이를 인계받아 닫힌 트랙사이드 유닛에 연결됩니다. 이동성과 유일한 차이점은 TITAN을 메시 포인트 유닛에서 활성화할 수 있다는 것입니다. 이 경우, Fluidity(유동성) 기능이 라디오의 동작 모드를 대체합니다.

트랙사이드 라디오

라디오가 백본 네트워크와 통신할 수 없는 경우, 시스템은 장애에 대한 즉각적인 응답으로 차량을 가장 가까운 트랙측에 강제로 연결합니다. 고정 네트워크에서와 동일한 프로세스이지만 둘 이상의 활성 대기 트랙사이드 가능성이 있습니다. 트랙사이드 시스템에서 백업은 대기 모드의 무선이 아니라 완전 작동 및 능동적 백업으로 오류를 해결할 수 있습니다.

기업 네트워크에 연결된 게이트웨이

Mesh가 고정 네트워크에서 종료되는 것처럼 게이트웨이(FM1000 및 FM10000)가 함께 작동하여 Primary를 선택하고 백업이 장애 발생 시 인계됩니다.

예비선거

동일한 유선 방송 도메인에 연결되고 동일한 패스프레이즈로 구성된 모든 CURWB 유닛들은 몇 초마다 분산 프라이머리 선출 과정을 수행한다. Primary 유닛은 CURWB MPLS 네트워크의 엣지 포인트, 즉 사용자 트래픽이 메쉬로 들어오거나 나갈 수 있는 디바이스를 구성합니다. 보조 유닛은 MPLS 릴레이 포인트 역할을 합니다. 각 네이버에 대해 알고리즘은 유닛의 역할(메시-엔드 또는 메시-포인트)과 해당 메시-ID를 기반으로 우선순위 값을 계산합니다. 메시-엔드는 메시-포인트들보다 높은 우선순위를 할당받고, 동일한 우선순위 중에서, 가장 낮은 메시-ID를 갖는 유닛이 선호된다. 선택 메커니즘은 네트워크에서 지속적으로 실행되는 전용 신호 처리 프로토콜에 의존하며, 모든 유닛에서 동일한 기본 를 선택하도록 보장합니다.

메시 엔드 장애 조치

정상 작동 중에는 기본 및 보조 메시가 계속 종료되어 상태에 대해 서로 통신하고 네트워크 연결 정보를 교환합니다. 특히 Primary 는 내부 포워딩 테이블 및 멀티캐스트 경로와 관련된 업데이트를 주기적으로 Secondary에 전송합니다.

설정

기본 TITAN 컨피그레이션 설정에서는 구축에 기본 게이트웨이 하나와 보조 게이트웨이 두 개(메시 엔드)가 필요합니다.

기본 및 보조 하드웨어 모두 이러한 TITAN 컨피그레이션을 가져야 합니다.

mpls fastfail status enabled(mpls fail 상태 활성화) 구성

mpls fastfail timeout 구성 150

config mpls unicast-flood 활성화됨

config mpls arp-unicast disabled

config spanning-tree link-guard 40

config arp gratuitous enabled

arp 무상 지연 구성 150

레이어 3 컨피그레이션에서는 각 메시 끝에 HA가 필요한 경우 이전의 TITAN 컨피그레이션을 실행해야 하는 메시 끝을 2개 확보해야 합니다.

차량 라디오에 TITAN을 구성하는 동안, 먼저 차량에는 2개의 라디오가 있어야 합니다. 기본 서버에 장애가 발생할 경우 보조 서버가 통신을 인계받습니다. 이 시나리오에서, 차량 라디오들 및 유동성 네트워크의 메시 단부는 TITAN 구성을 가질 필요가 있다.

테스트 시나리오

현재 네트워크 토폴로지에는 7개의 무선이 포함되어 있습니다. 이 설정 내에서 메시 엔드 무선 인터페이스는 비활성화됩니다. 이러한 기능은 Trackside 무선 시스템의 일부로서가 아니라 게이트웨이로 기능하도록 제한되어 있습니다. 기본 메시 엔드 유닛에는 IP 주소 10.122.136.50이 할당되고 보조 유닛에는 IP 주소 10.122.136.47이 할당됩니다.

3개의 트랙사이드 무선 장치(10.122.136.9, 10.122.136.16 및 10.122.136.15)가 있습니다. IP 주소가 10.122.136.9인 트랙사이드 무선 장치는 코어 네트워크 인프라에 고정 연결됩니다. 이 중추적 무선 장치는 또한 IP 10.122.136.15 및 10.122.136.16을 사용하는 트레일러 무선 장치로 백홀 링크를 확장합니다. 이러한 고정 인프라 백홀 링크는 5240MHz 주파수 대역에서 작동하고 있습니다. 종합적으로, 세 개의 무선 장치는 IP 주소 10.122.136.13)를 사용하여 5180MHz 주파수로 작동하는 모바일 장치에 무선 커버리지를 제공합니다.

모바일 차량에는 IP 주소 10.122.136.13을 기본으로 하고 10.122.136.14를 보조로 하는 2개의 라디오가 장착되어 있습니다. 두 무선 장치 모두 단일 스위치를 통해 상호 연결됩니다. 보조 라디오는 여기에 표시되지 않습니다.

메시 엔드 장애 조치

1단계: 기본 및 보조 메시 끝이 모두 네트워크에 연결되고 활성 상태입니다. 우리는 낮은 메시 ID의 라디오가 메시 엔드로 작용하는 것을 볼 수 있다.

2단계: 기본이 정상적으로 작동하면 보조 메시 엔드가 전체 네트워크의 메시 엔드의 역할을 담당합니다. 실패한 기본 메시 끝이 인프라 무선 목록에 없습니다.

3단계: 장애가 발생한 기본 라디오가 다시 시작되어 작동합니다. 그러나 네트워크 토폴로지를 학습하기 위해 선점 지연을 기다립니다

4단계: 선점 타이머에 도달하면 메시 ID 5.246.226.200이 기본 ID의 역할을 인계받고 메시 ID 5.246.227.8의 무선 장치가 다시 보조 ID가 됩니다.

차량 라디오에서 장애 조치 테스트

이 실험실 네트워크에서는 한 대의 차량이 선로 변에 연결되어 있는 유동적인 네트워크를 가지고 있다. 이 차량에는 IP 10.122.136.13 - 메시 ID 5.66.194.36 (P) 및 10.122.136.14 - 메시 ID 5.246.2.120 (S)의 라디오 2개가 있습니다.

1단계: 기본 및 보조 차량 무선 장치가 모두 온라인 상태입니다. 낮은 메시 ID의 라디오가 기본 라디오로 작동하고 다른 ID가 보조 라디오로 작동하는 것을 볼 수 있습니다. 무선 품질에 따라 기본 및 보조 무선 모두 트랙측 무선 장치와 통신할 수 있습니다. 그러나 온보드 네트워크에 대한 모든 다운스트림 통신은 항상 기본 라디오를 통과합니다. TITAN 보조 차량 무선 장치는 500ms 내에 고장 시 Primary가 됩니다.

이 스크린샷에서는 메시 엔드에서 차량 무선까지 MPLS 터널을 볼 수 있습니다.

2단계: 기본 라디오 10.122.136.13을 종료하면 보조 라디오로 장애 조치되고 이제 10.122.136.14가 기본 라디오가 됩니다.

3단계: 차량의 고장 난 기본 온보드 라디오의 전원이 다시 들어오고 작동합니다. 그러나 이 라디오는 네트워크에 연결되지만 선점 지연을 기다리며 유동성 네트워크에 적극적으로 참여하지 않습니다.

이 스크린샷에서 볼 수 있듯이 5.66.194.36이 온라인 상태로 돌아왔지만 선점 지연 기간 중에는 보조 상태로 작동하고 있으며 5.246.2.120은 여전히 통신을 관리하고 있습니다. 또한 MPLS 터널에는 5.246.2.120이 트랙사이드 라디오와 통신 중임을 보여 줍니다.

문제 해결 TITAN

- TITAN 컨피그레이션 중에 모든 컨피그레이션은 모든 필수 무선 장치에서 동일해야 합니다.

- 구축 크기에 따라 선점 지연을 늘려야 할 수 있습니다. 이는 실패한 유닛이 작동할 때 토폴로지를 학습하기 전에 너무 일찍 역할을 인계받지 않도록 하기 위한 것입니다.

- 빠른 실패 시간 제한을 너무 작게 구성하면 네트워크가 불안정해질 수 있습니다. 대부분의 구축에서 150ms 값을 사용할 수 있습니다.