MPLS и VPLS с лабораторией по организации трафика Настройка лабораторной работы по MPLS и VPLS с организацией трафика.

Пожалуйста, прочитай пост Улдиса в этой теме – там видно, в чем разница. Вся разработка ведется в пакетах mpls-test и routing-test, и чтобы их использовать, нужно установить оба.

Здесь описана простая настройка и команды, необходимые для конфигурации маршрутизаторов: http://wiki.mikrotik.com/wiki/MPLS_TE_Tunnels Да, вы правы, TE тоннели независимы от VPLS. Как и распределение меток на основе LDP, TE тоннели просто устанавливают коммутируемые каналы (label switched path). LDP устанавливает LSP для каждого маршрута в сети, а TE тоннели устанавливают LSP по мере необходимости (при конфигурировании). Установленные LSP затем можно использовать для пересылки данных, один из потенциальных “пользователей” — VPLS. Если вам нужна дополнительная помощь в настройке TE тоннелей, пожалуйста, опишите планируемую вами схему.

Тебе стоит учитывать, что TE-туннели сами по себе не ограничивают/не управляют трафиком. "Пропускная способность", которую указывают для TE-туннеля, больше похожа на административное значение, она влияет на то, можно ли зарезервировать пропускную способность на каком-то маршрутизаторе или нет. Если у какого-то TE-туннеля зарезервирована пропускная способность 10 Мбит/с, маршрутизаторы по пути не будут ограничивать пропускную способность для конкретного потока до 10 Мбит/с. Если тебе действительно нужно жёстко ограничить объём данных, передаваемых по TE-туннелю, нужно убедиться, что больше указанного лимита данных не входит в TE-туннель (это можно сделать с помощью очередей на маршрутизаторе TE ingress). Если в твоей конфигурации трафик обоих клиентов перенаправляется по TE-туннелям (через основной магистральный канал), каждый из которых имеет пропускную способность 10 Мбит/с, то при обрыве основного магистрального канала только один туннель будет перенаправлен по резервному (потому что первый туннель «зарезервирует» 10 Мбит/с, и больше "пропускной способности" для второго туннеля не останется). Ещё один момент: RouterOS пока не реализует MPLS local protection (быструю переадресацию) – перенаправление трафика на резервный канал произойдёт только после изменения состояния IGP и пересмотра туннелей.

Быстрая переадресация (помни, что RouterOS пока что не поддерживает это) должна перенаправлять трафик по резервному туннелю за миллисекунды, а не за секунды или минуты. Также учти, что быстрая переадресация не восстанавливает существующие туннели – тебе нужно настроить резервные туннели вокруг «уязвимых» каналов или узлов в пути туннеля, и при отказе канала/узла трафик будет перенаправляться по обходному пути (фактически основной туннель также будет поддерживаться по этой резервной связи, чтобы он не вытек). Время сходимости TE-туннелей к новой топологии зависит от типа отказа. Например, если маршрутизатор обнаружил отключение кабеля (предположительно твой тест-кейс), RSVP/IGP могут среагировать немедленно – в этом случае туннель будет восстановлен за несколько секунд. Если обнаружение отказа произойдет на основе протокольного таймаута (например, OSPF или RSVP), это займет больше времени. В чем именно проблема с медленной резервной связи? Чтобы контролировать, как пропускная способность распределяется между потоками трафика при передаче по более медленной резервной связи, ты можешь отмечать пакеты в зависимости от того, от какого клиента они пришли, и настроить очередь на резервном интерфейсе (используя подходящие значения limit-at и max-limit). Я не вижу, как VPLS mesh здесь подходит. Что касается установки TE-туннелей – тебе просто нужно убедиться, что у обоих есть шанс быть установленными по резервной связи (настроенная пропускная способность). TE-туннели однонаправленные как при установке, так и при передаче данных. Сбивающий с толку тезис должен означать, что тебе не нужно иметь туннель в обратном направлении, чтобы первый туннель работал и передавал данные. Конечно, тебе следует настроить туннель в обратном направлении, если ты хочешь, чтобы данные передавались в обоих направлениях по TE-туннелям, но это не является требованием для двунаправленной связи – например, данные могут быть отправлены в обратном направлении по LSP, установленному LDP.

У меня есть вопросы по примерам в Wiki по настройке MPLS, они больше касаются OSPF, но возникают из примеров MPLS: - IP-адреса, используемые в качестве loopback-адресов, являются публичными адресами, 9.0.0.0/8 принадлежит IBM, не должны ли они быть в частном диапазоне, например, 10.0.0.0/8, 172.16.0.0/16 или 192.168.0.0/24? Я понимаю, что это примеры, но разве они не должны быть корректными? Настраивая тестовую лабораторию в соответствии с примерами из Wiki, я вижу некоторые маршруты в OSPF-таблицах с Area как "unknown", особенно loopback-адреса. Это нормально или адресные диапазоны должны иметь определения Area? Кажется, что все работает нормально, просто выглядит странно! С уважением, Chris Macneill

Возможно, просто необходимо уточнить, что адреса loopback 9.x.x.x следует менять на что-то более осмысленное в частном адресном пространстве при переходе с тестовой среды в продуктивную. Кто-нибудь где-нибудь обязательно оставит эти адреса 9.x.x.x и со временем может столкнуться с какими-то странными проблемами с маршрутизацией! Я понимаю, что те, кто работает с MPLS, как правило, достаточно продвинутые и сами это разберутся, но ведь найдется хотя бы один, кто не разберется! Я приложил JPEG экрана маршрутизации OSPF для одного из моих узлов. Проблема видна только в Winbox, возможно, это просто ошибка там с пакетом routing-test, я использую v3.14. В CLI-версии данных вообще нет информации об Area. Я настроил записи Area для сети 9.0.0.0/8 и 192.168.3.0/24, но они все равно отображаются как "неизвестные" даже после перезагрузки. Узел 1 подключен через другой RB532 к корпоративной локальной сети (192.168.3.0/24) через 192.168.155.0/24. Также 192.168.55.0/24 есть на “gateway” RB532 как локальная тестовая сеть. Сети, которые соединяют мои три тестовых узла, это 192.168.12.0/24, 192.168.23.0/24 и 192.168.13.0/24. Я использую NAT на “gateway” узле, чтобы я отображался как один адрес 192.16.3.0/24 для корпоративной сети, остальное маршрутизируется. С уважением, Chris Macneill

gustkiller, раз TE тоннели – это интерфейсы, ты можешь перенаправлять трафик через них, используя маршрутизацию (или политическую маршрутизацию). Для этого тебе придется добавить IP-адрес в начало тоннеля (просто чтобы его можно было использовать для IP-маршрутизации), а затем использовать настройку “gateway=”.