NSG - Примеры конфигурации: Маршрутизация в корпоративной сети
Оборудование для сетей передачи данных
+7 (495) 727-1959

Маршрутизация в корпоративной сети
на основе подключений LTE и туннелей GRE

Имеется удалённая площадка с доступом по двум каналам LTE. Требуется обеспечить устойчивую связь с головным офисом по сети VPN сотовых операторов (одного или разных). Используется устройство NSG–1700 с двумя опциями LTE и SIM-карты со статическими приватными адресами. Для маршрутизации пакетов через нужный канал (приоритетный из двух, или единственный действующий в данный момент) в локальную сеть на площадке используется OSPF. Однако через сеть оператора OSPF не проходит, поэтому через каждый сотовый канал стоится туннель GRE к центральному шлюзу и уже поверх него работает OSPF и передаётся полезный трафик.

Маршрутизация в корпоративной сети

Настройка локальной сети и сотовых портов:

port 
: eth0 
: : ifAddress 
: : : prefix = "192.168.1.1/24"
: eth1 
: : ifAddress 
: : : prefix = "123.145.0.65/29"
: m1 
: : type = "lte"
: : ifAddress 
: : : dhcp-options 
: : : : default-gw-table = 1
: : provider 
: : : main 
: : : : APN = "my.poopy.apn"
: m2 
: : type = "lte"
: : ifAddress 
: : : dhcp-options 
: : : : default-gw-table = 2
: : provider 
: : : main 
: : : : attempts = 0
: : : aux 
: : : : APN = "my.other.apn"
: : : : attempts = 1

Порты LTE работают в режиме эмуляции Ethernet-подобных интерфейсов и получают настройки от сотовых операторов по DHCP. Важно: маршрут по умолчанию, полученный по DHCP, записывается не в основную таблицу маршрутизации, а в отдельные таблицы 1 и 2, соответственно. Эти маршруты нужны только для маршрутизации пакетов GRE на центральный шлюз. Полезный трафик будет маршрутизироваться в тот или другой туннель позже — при помощи OSPF.

Посмотреть маршруты, назначенные операторами, можно при помощи команд show в следующих узлах:

ip
: route-tables 
: : 1 
: : : name = "m1-default-route"
: : 2 
: : : name = "m2-default-route"

Сами эти узлы созданы исключительно для просмотра и имена таблицам назначены для удобства. На работу устройства их наличие не влияет.

Трафик на шлюз маршрутизируется при помощи следующих правил:

ip
: rule 
: : 1 
: : : to = "123.145.0.129/32"
: : : table = 1
: : 2 
: : : to = "123.145.0.128/32"
: : : table = 2
: : 3 
: : : to = "123.145.0.129/32"
: : : type = "prohibit"
: : 4 
: : : to = "123.145.0.128/32"
: : : type = "prohibit"

Если сотовый интерфейс в нерабочем состоянии, то соответствующая таблица будет пустая и пакет не может быть маршрутизирован нужным образом. В этом случае он уничтожается, чтобы не ушёл по умолчанию внутрь другого, работающего, туннеля.

Туннели GRE:

tunnel 
: gre 
: : gre1 
: : : ifAddress 
: : : : prefix = "172.16.250.62/30"
: : : destination = "123.145.0.129"
: : : device = "m1"
: : gre2 
: : : ifAddress 
: : : : prefix = "172.16.250.58/30"
: : : destination = "123.145.0.128"
: : : device = "m2"

Параметр device не обязательный, нужные интерфейсы и адреса источника определяются автоматически по таблицам маршрутизации. Но он привязывает состояние туннеля к состоянию сотового интерфейса. В результате при потере сотового соединения туннель немедленно падает и перестроение маршрутов происходит быстрее.

Собственно динамическая маршрутизация. Протокол OSPF обеспечивает обмен маршрутами между таблицей master и соседними узлами, а фиктивный протокол kernel — обмен между таблицей master и основной маршрутной таблицей ядра, по которой непосредственно производится маршрутизация пакетов. Из двух сотовых соединений (и туннелей) предпочтительным считается первое, поэтому для него выставлена меньшая метрика.

ip 
: dynamic-routing 
: : enable = true
: : kernel 
: : : 1 
: : : : export = "all"
: : ospf 
: : : 1 
: : : : area 
: : : : : 0.0.0.42 
: : : : : : interface 
: : : : : : : "\"eth1\"" 
: : : : : : : : stub = "on"
: : : : : : : "\"gre1\"" 
: : : : : : : : cost = 100
: : : : : : : "\"gre2\"" 
: : : : : : : : cost = 200
: : : : : : networks 
: : : : : : : 123.145.0.64/29 
: : : : : : : 172.16.250.56/30 
: : : : : : : 172.16.250.60/30 
: : : : : : stub = "on"
: : router-id = "172.23.250.58"

В заключение, сервисы netping контролируют доступность шлюза по одному и по другому сотовым каналам. Если канал "завис", т.е. номинально существует, но данные по нему не проходят (это часто случается и ещё долго будет случаться в сотовых сетях), то они рестартуют порт. Скрипт рестарта исполняется в контекcте bash, поэтому сначала запускается оболочка nsgsh, а внутри неё исполняются команды дерева NSG.

services 
: netping 
: : check-m1 
: : : adm-state = "up"
: : : destination = "123.145.0.129"
: : : failure-script = "nsgsh -qr .port.m1.restart=nil"
: : check-m2 
: : : adm-state = "up"
: : : destination = "123.145.0.128"
: : : failure-script = "nsgsh -qr .port.m2.restart=nil"

Дополнительные замечания:

Как можно видеть, конфигурация содержит минимальное число параметров, уникальных для клиента. Это адреса сетей /30 в туннелях, адрес в локальной сети за клиентским маршрутизатором и (не обязательный в явном виде) Router ID. Таким образом, она хорошо подходит для массовых инсталляций. Дополнительно уменьшить число уникальных параметров можно при помощи ненумерованных интерфейсов в туннелях.