_{Original file}

NETSHe Lab

Оглавление

Система NETSHe поддерживает различные средства маршрутизации от статических маршрутов до динамических протоколов маршрутизации. Так же в NETSHe можно организовать гибкую маршрутизацию, с несколькими альтернативными маршрутами или маршрутизацию от источника (source routing). Подробно рассматриваются только случаи, перечисленные в оглавлении.

Все настройки так или иначе связанные с маршрутизацией собраны в одном пункте меню WebUI «Маршрутизация». Так же в меню «Диагностика» в данном контексте может быть полезен пункт: «Диагностика →Маршруты», где показано текущее состояние главной таблицы маршрутизации.

Система NETSHe допускает указание различных статических маршрутов, для этого нужно воспользоваться пунктом «Маршрутизация →Статические маршруты». Список маршрутов выглядит так:

Для ввода статического маршрута следует указать:

1. - тип протокола (IPv4 или IPv6),
2. - адрес и маску сети,
3. - метрику маршрута,
4. - интерфейс (обязательно) и (или) шлюз (указание шлюза не обязательно для интерфейсов без ARP/NBD), через который должны идти пакеты,
5. понятное описание маршрута.

Следует помнить, что для применения новых маршрутов следует перезагрузить устройство.

Система имеет предустановленный либо устанавливаемый BGP-маршрутизатор и средства управления им, которые находятся в «Маршрутизация →Маршрутизация BGP».

Для работы BGP маршрутизатора явно должны быть указаны номер своей автономной системы (1), адреса соседей (как минимум один) (3), для соседей-маршрутизаторов, не являющихся прямо присоединенным к нашему, требуется явно указать, что маршрутизатор находится за несколькими (eBGP multihop).

BGP маршрутизатор позволяет анонсировать через BGP как не присоединенные или агрегированные сети (2), так и локальные маршруты, полученные с помощью других протоколов маршрутизации и сетевых сервисов (5).

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

BGP маршрутизатор способен анонсировать для соседа маршрут по умолчанию.

Система NETSHe имеет предустановленный либо устанавливаемый RIP-маршрутизатор, настройки которого можно найти в «Маршрутизация →Маршрутизация RIP».

RIP является дистанционно-векторным, автоматическим протоколом маршрутизации, где роль дистанции выполняет метрика (hop) со значениями от 1 до 15.

Анонс сетей и установление соседства осуществляются через явно указанные интерфейсы (2), либо с использованием multicast пакетов, либо с использованием unicast UDP через интерфейсы точка-точка, в последнем случае требуется в явном виде указать соседей (5).

Как и в других реализациях RIP, в NETSHe можно задать сети, на которых он работает (1). При этом иерархия классов сетей будет соблюдаться, так что лучше сети подбирать максимально соответствующие классам сетей.

А вот довольно редкий у других производителей механизм фильтрации RIP в NETSHe представлен широко, можно выбирать интерфейсы (2), маршруты, полученные из других источников (6), а так же задавать параметры. Например, функция split horizon из стандарта RIP, которая позволяет не посылать обновления маршрутов тем интерфейсам, от которых они стали известны (4), в NETSHe настраивается отдельно для каждого интерфейса.

Поскольку протокол RIP автоматический, использующий multicast вещание, иногда в сетях с низкой пропускной способностью имеет смысл ограничить обмен маршрутной информацией только с непосредственными соседями (3).

В состав NETSHe был включен RIP NG маршрутизатор для сетей IPv6, найти его можно в соответствующем пункте меню «Маршрутизация →Маршрутизация RIP IPv6 (NG)»

RIP NG проще в настройке и использовании. Настройке подлежат список сетей (1) и интерфейсов (2), через которые будет работать маршрутизация.

Система NETSHe имеет предустановленный либо устанавливаемый OSPF-маршрутизатор и средства управления им, которые находятся в «Маршрутизация →Маршрутизация OSPF».

OSPF относится к протоколам динамической маршрутизации и построен на принципе отслеживания состояния каналов. Он имеет более быструю сходимость в сравнении с RIP.

OSPF является довольно сложным в настройке видом маршрутизации, поэтому следует помнить, что в веб-интерфейсе NETSHe реализованы только самые часто используемые опции. При необходимости использовать все возможности маршрутизатора, включите «Использовать настройки из командной строки» и сконфигурируйте маршрутизатор из командной строки, использую утилиту vtysh.

Для настроек из WebUI следует определить приоритет самого маршрутизатора NETSHe, задав ему идентификатор (1). Затем нужно определить области OSPF и сети (2), которые к этим областям относятся. Потом следует заняться отбором интерфейсов (4) и локальных маршрутов, которые будут задействованы в OSPF дереве. При этом у каждого интерфейса можно указать ряд параметров, по которым будет определяться приоритет его маршрутов (5). Указанная тут стоимость будет добавлена к стоимостям всех маршрутов, проходящих через этот интерфейс.

Напомним, что OSPF работает через соседство, устанавливаемое посредством multicast рассылок через широковещательные интерфейсы (не требуют явного указания соседей), либо через unicast UDP сообщения, требующие явного указания адреса соседа (3).

Дополнительно можно указать тип интерфейса (6) для лучшего установления соседства OSPF в случае объединения разнородных сетей, а так же задать соседей явно (3).

При использовании OSPF следует помнить, что такие маршруты будут иметь приоритет перед маршрутами иных типов динамической маршрутизации (RIP, BGP) и статическими маршрутами.

За более подробной информацией по настройке и использованию маршрутизации OSPF рекомендуем Вам обратиться к соответствующим руководствам.

Система NETSHe может распределять трафик по нескольким внешним WAN интерфейсам. На основе данного факта можно выделить три варианта применения Multipath маршрутизации:

1. резервирование подключений к провайдерам, при котором один канал выполняет функцию основного, а другой – функцию backup, при которой он становится рабочим только в отсутствие (падении) основного канала;
2. распределение трафика между подключениями на основе сетей, при этом трафик разных сервисов используют постоянно каждый свой канал;
3. автоматическая балансировка трафика между каналами, при этом трафик распределяется между каналами динамически и автоматически, исходя из заданных коэффициентов.

Несмотря на широкие возможности, надо отметить ряд требований и ограничений, накладываемых на случаи применения multipath:

1. все интерфейсы, участвующие в multipath маршрутизации, должны принадлежать зоне WAN;
2. необходимо использовать собственные настройки DNS; от настроек DNS, которые автоматически выдают провайдеры, необходимо отказаться;
3. рекомендуется задавать индивидуальные адреса для проверки состояния каждого интерфейса, участвующего в маршрутизации;
4. если применяется балансировка трафика, то обязательно должен быть включен межсетевой экран.

Преимущества использования:

1. в случае автоматической балансировки трафика TCP-сессии отслеживаются и все пакеты одной сессии отправляются через один интерфейс;
2. в случае отключения одного из WAN интерфейсов, трафик продолжает распределяться по оставшимся каналам;
3. в случае переключения каналов основной/резервный все маршруты своевременно обновляются (удаляются не актуальные, добавляются нужные), задержки при переключении прогнозируемы.

Настраивается данный функционал с помощью разных пунктов меню, среди которых главный «Маршрутизация → Multipath маршрутизация».

Поскольку разные случаи применения multipath предполагают довольно разнообразные настройки, разумно будет рассмотреть их подробно в отдельных разделах данного документа.

Рассмотрим случай, когда существует два подключения к 2-м провайдерам. Оба провайдера используют при подключении статическую маршрутизацию и выдают нам по подсети адресов. Это означает, что провайдеры не посылают Вашему оборудованию никакой информации о маршрутах, состоянии собственных каналов связи.

Требуется организовать переключение между провайдерами при возникновении проблем у текущего и возврат на основного провайдера по мере разрешения проблем. Переключение должно происходить автоматически.

Очень частой причиной отсутствия связи являются проблемы на магистральных линиях/оборудовании оператора и далее. Из этого следует, что Ethernet (или любой другой WAN) порт NETSHe будет в «поднятом» состоянии всегда, когда есть сигнал между Вашим портом и портом на оборудовании провайдера. Следовательно, корректно отследить проблемы со связью по состоянию WAN-порта не представляется возможным.

Для начала выберем критерий отсутствия проблем у провайдера. В качестве такого критерия в NETSHe используется доступность заданного для проверки соединения IP адреса, расположенного где-то на стороне основного провайдера. Доступность означает прохождение серии ICMP-пакетов (ping). Соединение с провайдером рассматривается как доступное, если последняя серия пакетов прошла успешно, и объявляется недоступным, если серия ping завершилась неудачно. Успешным завершением серии ping считается код завершения 0 команды ping –c5 CHECKING_IP_ADDRESS, а неуспешным – любой иной код завершения.

Вы можете заметить, что IP-адрес для проверки соединения к одному провайдеру может быть недоступен через сеть другого, или, иными словами, нужно обеспечить, чтобы серия ping для проверки доступности выполнялась исключительно через подключение конкретного провайдера. Так, мы должны в таблицу маршрутизации внести маршрут до тестируемого IP-адреса. Эти маршруты должны иметь минимальную маску (т.е. быть маршрутом только до конкретного хоста) и максимальный приоритет. Эти маршруты должны постоянно находиться в таблице маршрутизации и иметь приоритет выше текущего маршрута по умолчанию.

Проверка доступности каждого подключения к провайдеру автоматическая и происходит раз в 5 минут, что позволяет говорить о времени переключения на резервный канал в пределах 5 минут.

Прежде всего, нужно посмотреть настройки обоих WAN интерфейсов и отключить адреса DNS-серверов, присылаемые операторским DHCP сервером. Это вызвано тем, что операторские DNS серверы часто не принимают запросов от «не своих» IP адресов. В данном примере один из WAN IP определяется вручную, соответственно опция о DNS провайдера не доступна.

При этом у пути соединения с основным провайдером следует задать «Внешний адрес для проверки соединения», к которому надо прописать маршрут обязательно через данный WAN-интерфейс. На картинке выше видно, что адрес для проверки не располагается в непосредственной близости от устройства с NETSHe, более того, NETHSe непосредственно присоединяется к какой-то частной сети, в которой где-то имеется выход в Интернет. Тем не менее, этот канал выбран основным, т.к. резервное подключение, как будет видно позднее, осуществляется через сотовое соединение.

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

Механизм проверки соединения до провайдера реализуется скриптом failover.sh из расписания задач. Эта задача вносится в расписание автоматически, от Вас не требуется никаких действий для этого. Но проверить ее наличие все-таки нужно, т.к. расписание задач доступно для редактирования всем администраторам устройства.

Так же стоит проверить вхождение обоих WAN интерфейсов в зону WAN и наличие настроек разрешения имен DNS общих для всех подключений в Интернет.

При переключении соединения с провайдером из таблицы маршрутизации удаляются маршруты предыдущего соединения и устанавливаются новые маршруты (как минимум должен быть установлен маршрут по умолчанию).

Для настройки этого функционала необходимо проверить или настроить следующие параметры, которые подробно показаны в предыдущем примере:

1. убедиться, что оба WAN интерфейса принадлежат зоне WAN,
2. убедиться, что в расписании задач есть задача failover.sh,
3. проверить или настроить общие параметры DNS,
4. проверить и удалить статические маршруты через требуемые WAN интерфейсы,
5. убедиться, что включен межсетевой экран.

Межсетевой экран можно найти в меню «Сеть →Межсетевой экран» или найти соответствующее сообщение на главной странице WebUI.

Все остальные настройки выполняются в пункте «Маршрутизация → Multipath маршрутизация».

Во-первых, надо разрешить multipath маршрутизацию (1) и балансировку трафика (2), далее нужно задать IP-адреса вышестоящих маршрутизаторов (3) для каждого из участвующих в балансировке интерфейсов (4). Эти адреса будут использованы для построения исходящих маршрутов для маркированного трафика. Наконец, следует определить пропорцию, как будет делиться трафик по каналам (5). Значения 0/0 соответствуют симметричному 50%/50% распределению трафика по интерфейсам.

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

Данное руководство не описывает маршрутизацию на основе политик. В качестве критериев в политиках могут выступать не только адреса источника и назначения, а и номера портов, протоколов, флаги TCP. В общем случае специалисты техподдержки на сайте http://www.netshe-lab.ru помогут Вам реализовать сколь угодно детальную маршрутизацию под вашу конкретную задачу.