====== netshe_doc_chap6 ====== {{netshe_doc_chap6.odt|Original file}} ===== ===== {{глава_6_-_маршрутизация_Image_0.gif}}**NETSHe Lab** |**Универсальное программное обеспечение **\\ **NETSHe**** **\\ **для сетевых устройств.**\\ Часть 6. Маршрутизация.|| | NETSHe Lab длительное время занимается разработками программного обеспечения для сетевых устройств, провайдеров услуг и операторов связи. Среди программного обеспечения центральное место занимает операционная система NETSHe, которая может быть использована в широком спектре сетевых устройств и сервисов.|| |Версия 2\\ Апрель, 2020|\\ Станислав Корсаков, ООО «Нетше лаб»\\ (с) 2009-2020 Ярославль| Оглавление Система NETSHe поддерживает различные средства маршрутизации от статических маршрутов до динамических протоколов маршрутизации. Так же в NETSHe можно организовать гибкую маршрутизацию, с несколькими альтернативными маршрутами или маршрутизацию от источника (source routing). Подробно рассматриваются только случаи, перечисленные в оглавлении. Все настройки так или иначе связанные с маршрутизацией собраны в одном пункте меню WebUI «Маршрутизация». Так же в меню «Диагностика» в данном контексте может быть полезен пункт: «Диагностика ->Маршруты», где показано текущее состояние главной таблицы маршрутизации. ====== Статические маршруты ====== Система NETSHe допускает указание различных статических маршрутов, для этого нужно воспользоваться пунктом «Маршрутизация ->Статические маршруты». Список маршрутов выглядит так: {{глава_6_-_маршрутизация_Image_1.jpg}} Для ввода статического маршрута следует указать: - - тип протокола (IPv4 или IPv6), - - адрес и маску сети, - - метрику маршрута, - - интерфейс (обязательно) и (или) шлюз (указание шлюза не обязательно для интерфейсов без ARP/NBD), через который должны идти пакеты, - понятное описание маршрута. Следует помнить, что для применения новых маршрутов следует перезагрузить устройство. ====== Динамическая маршрутизация BGP ====== Система имеет предустановленный либо устанавливаемый BGP-маршрутизатор и средства управления им, которые находятся в «Маршрутизация ->Маршрутизация BGP». {{глава_6_-_маршрутизация_Image_2.jpg}} Для работы BGP маршрутизатора явно должны быть указаны номер своей автономной системы (**1**), адреса соседей (как минимум один) (**3**), для соседей-маршрутизаторов, не являющихся прямо присоединенным к нашему, требуется явно указать, что маршрутизатор находится за несколькими (eBGP multihop). BGP маршрутизатор позволяет анонсировать через BGP как не присоединенные или агрегированные сети (**2**), так и локальные маршруты, полученные с помощью других протоколов маршрутизации и сетевых сервисов (**5**). В случае анонса одинаковых маршрутов несколькими соседями, в таблицу маршрутизации попадет маршрут от соседа, имеющий минимальный вес. BGP маршрутизатор способен анонсировать для соседа маршрут по умолчанию. ====== Динамическая маршрутизация RIP ====== Система NETSHe имеет предустановленный либо устанавливаемый RIP-маршрутизатор, настройки которого можно найти в «Маршрутизация ->Маршрутизация RIP». {{глава_6_-_маршрутизация_Image_3.jpg}} 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)» {{глава_6_-_маршрутизация_Image_4.jpg}} RIP NG проще в настройке и использовании. Настройке подлежат список сетей (**1**) и интерфейсов (**2**), через которые будет работать маршрутизация. ====== Динамическая маршрутизация OSPF ====== Система NETSHe имеет предустановленный либо устанавливаемый OSPF-маршрутизатор и средства управления им, которые находятся в «Маршрутизация ->Маршрутизация OSPF». OSPF относится к протоколам динамической маршрутизации и построен на принципе отслеживания состояния каналов. Он имеет более быструю сходимость в сравнении с RIP. OSPF является довольно сложным в настройке видом маршрутизации, поэтому следует помнить, что в веб-интерфейсе NETSHe реализованы только самые часто используемые опции. При необходимости использовать все возможности маршрутизатора, включите «Использовать настройки из командной строки» и сконфигурируйте маршрутизатор из командной строки, использую утилиту **vtysh**. Для настроек из WebUI следует определить приоритет самого маршрутизатора NETSHe, задав ему идентификатор (**1**). Затем нужно определить области OSPF и сети (2), которые к этим областям относятся. Потом следует заняться отбором интерфейсов (**4**) и локальных маршрутов, которые будут задействованы в OSPF дереве. При этом у каждого интерфейса можно указать ряд параметров, по которым будет определяться приоритет его маршрутов (**5**). Указанная тут стоимость будет добавлена к стоимостям всех маршрутов, проходящих через этот интерфейс. {{глава_6_-_маршрутизация_Image_5.jpg}} Напомним, что OSPF работает через соседство, устанавливаемое посредством multicast рассылок через широковещательные интерфейсы (не требуют явного указания соседей), либо через unicast UDP сообщения, требующие явного указания адреса соседа (**3**). Дополнительно можно указать тип интерфейса (**6**) для лучшего установления соседства OSPF в случае объединения разнородных сетей, а так же задать соседей явно (**3**). При использовании OSPF следует помнить, что такие маршруты будут иметь приоритет перед маршрутами иных типов динамической маршрутизации (RIP, BGP) и статическими маршрутами. За более подробной информацией по настройке и использованию маршрутизации OSPF рекомендуем Вам обратиться к соответствующим руководствам. ====== Multipath-маршрутизация ====== Система NETSHe может распределять трафик по нескольким внешним WAN интерфейсам. На основе данного факта можно выделить три варианта применения Multipath маршрутизации: - резервирование подключений к провайдерам, при котором один канал выполняет функцию основного, а другой – функцию backup, при которой он становится рабочим только в отсутствие (падении) основного канала; - распределение трафика между подключениями на основе сетей, при этом трафик разных сервисов используют постоянно каждый свой канал; - автоматическая балансировка трафика между каналами, при этом трафик распределяется между каналами динамически и автоматически, исходя из заданных коэффициентов. Несмотря на широкие возможности, надо отметить ряд требований и ограничений, накладываемых на случаи применения multipath: - все интерфейсы, участвующие в multipath маршрутизации, должны принадлежать зоне WAN; - необходимо использовать собственные настройки DNS; от настроек DNS, которые автоматически выдают провайдеры, необходимо отказаться; - рекомендуется задавать индивидуальные адреса для проверки состояния каждого интерфейса, участвующего в маршрутизации; - если применяется балансировка трафика, то обязательно должен быть включен межсетевой экран. Преимущества использования: - в случае автоматической балансировки трафика TCP-сессии отслеживаются и все пакеты одной сессии отправляются через один интерфейс; - в случае отключения одного из WAN интерфейсов, трафик продолжает распределяться по оставшимся каналам; - в случае переключения каналов основной/резервный все маршруты своевременно обновляются (удаляются не актуальные, добавляются нужные), задержки при переключении прогнозируемы. Настраивается данный функционал с помощью разных пунктов меню, среди которых главный «Маршрутизация -> Multipath маршрутизация». {{глава_6_-_маршрутизация_Image_6.jpg}} Поскольку разные случаи применения 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 провайдера не доступна. {{глава_6_-_маршрутизация_Image_7.jpeg}} При этом у пути соединения с основным провайдером следует задать «Внешний адрес для проверки соединения», к которому надо прописать маршрут обязательно через данный WAN-интерфейс. На картинке выше видно, что адрес для проверки не располагается в непосредственной близости от устройства с NETSHe, более того, NETHSe непосредственно присоединяется к какой-то частной сети, в которой где-то имеется выход в Интернет. Тем не менее, этот канал выбран основным, т.к. резервное подключение, как будет видно позднее, осуществляется через сотовое соединение. {{глава_6_-_маршрутизация_Image_8.jpg}} {{глава_6_-_маршрутизация_Image_9.jpg}} У резервного соединения помимо опции «Не использовать серверы имен провайдера», выбираем опцию «Использовать интерфейс как резервный». А так же проверяем, что нет никаких статических маршрутов, привязанных к резервному интерфейсу. {{глава_6_-_маршрутизация_Image_10.jpeg}} Механизм проверки соединения до провайдера реализуется скриптом failover.sh из расписания задач. Эта задача вносится в расписание автоматически, от Вас не требуется никаких действий для этого. Но проверить ее наличие все-таки нужно, т.к. расписание задач доступно для редактирования всем администраторам устройства. {{глава_6_-_маршрутизация_Image_11.jpg}} Так же стоит проверить вхождение обоих WAN интерфейсов в зону WAN и наличие настроек разрешения имен DNS общих для всех подключений в Интернет. {{глава_6_-_маршрутизация_Image_12.jpg}} {{глава_6_-_маршрутизация_Image_13.jpeg}} При переключении соединения с провайдером из таблицы маршрутизации удаляются маршруты предыдущего соединения и устанавливаются новые маршруты (как минимум должен быть установлен маршрут по умолчанию). ===== Настройка балансировки исходящего трафика на примере двух провайдеров ===== Для настройки этого функционала необходимо проверить или настроить следующие параметры, которые подробно показаны в предыдущем примере: - убедиться, что оба WAN интерфейса принадлежат зоне WAN, - убедиться, что в расписании задач есть задача failover.sh, - проверить или настроить общие параметры DNS, - проверить и удалить статические маршруты через требуемые WAN интерфейсы, - убедиться, что включен межсетевой экран. Межсетевой экран можно найти в меню «Сеть ->Межсетевой экран» или найти соответствующее сообщение на главной странице WebUI. Все остальные настройки выполняются в пункте «Маршрутизация -> Multipath маршрутизация». {{глава_6_-_маршрутизация_Image_14.jpeg}} Во-первых, надо разрешить multipath маршрутизацию (**1**) и балансировку трафика (**2**), далее нужно задать IP-адреса вышестоящих маршрутизаторов (**3**) для каждого из участвующих в балансировке интерфейсов (**4**). Эти адреса будут использованы для построения исходящих маршрутов для маркированного трафика. Наконец, следует определить пропорцию, как будет делиться трафик по каналам (**5**). Значения 0/0 соответствуют симметричному 50%/50% распределению трафика по интерфейсам. Следует понимать, что при условии непрерывности TCP-сессий, невозможно обеспечить одномоментное и точное деление трафика. В процессе эксплуатации баланс будет стремиться к указанным значениям, но в краткой перспективе может, конечно, иметь большую погрешность. ====== Заключение ====== Данное руководство не описывает маршрутизацию на основе политик. В качестве критериев в политиках могут выступать не только адреса источника и назначения, а и номера портов, протоколов, флаги TCP. В общем случае специалисты техподдержки на сайте [[http://www.netshe-lab.ru|http://www.netshe-lab.ru]] помогут Вам реализовать сколь угодно детальную маршрутизацию под вашу конкретную задачу.