Исходная конфигурация сети маршрутизаторов

В исходную конфигурацию сети учебной установки включено (см. приложение)

 

· Установленные имена и системные IP-адреса маршрутизаторов

· Сконфигурированные платы и порты, необходимые для выполнения работы. Идентификация порта в 7750SR имеет вид X/Y/Z, где X – номер позиции платы (IOM) в шасси, Y – номер дочерней платы (MDA) на плате IOM, Z – номер порта на MDA

· Сконфигурированные интерфейсы, необходимые для выполнения работы. В данном оборудовании интерфейсом называется логический объект, которому присваивается IP-адрес, и который может быть ассоциирован с портом (физическим объектом, входящим в состав плат). Особый статус имеет системный интерфейс, который связан не с портом, а с маршрутизатором, целиком.

· Сконфигурированный и настроенный протокол OSPF (динамической маршрутизации IP), служащий подложкой для протокола RSVP-TE, который в свою очередь обеспечивает построение туннелей IP/MPLS.

· Включенный протокол RSVP-TE на уровне маршрутизатора.

 

Используемые соглашения по названиям и IP-адресам

Схема присвоения IP-адресов отражена на рисунке (см. приложение).

Маршрутизаторы имеют названия вида PEx, где х = 1,2,3,4 и адреса системных интерфейсов вида х.х.х.х (например 2.2.2.2 и т.п.). Интерфейсы имеют названия вида To-PEx, где х – номер маршрутизатора, к которому ведет данный интерфейс (например, To-PE5 - интерфейс, ведущий к РЕ5).

 

Инструментальные средства проверки созданных конфигураций

SROS поддерживает ряд команд, обеспечивающих проверку работоспособности создаваемых объектов, включая стандартные средства IP ping, tracerout, а также другие, предназначенные для проверки объектов на уровне MPLS и сервисов. Эти средства сосредоточены в контексте ОАМ (oam lsp-ping, oam lsp-trace…).

Выполнение задания

Конфигурирование RSVP-TE с ограничениями по пропускной способности

1. Для обеспечения возможности построения MPLS-туннелей с учетом реальных пропускных способностей звеньев эзернет необходимо использование расширенной функциональности протокола динамической маршрутизации (OSPF), которая называется «traffic-engineering». Она предусматривает передачу в служебных сообщениях OSPF дополнительного блока информации, включающего сведения о пропускных способностях звеньев. Включите traffic-engineering протокола OSPF.

PEx# configure router ospf traffic-engineering ¿

1. Проверьте статус traffic-engineering протокола OSPF на вашем маршрутизаторе.

PEx# show router ospf status ¿

Для этого найдите в рапорте строку, описывающую статус traffic-engineering.

1. Включите MPLS на уровне системы и на уровне сетевых интерфейсов.

PEx# configure router mpls ¿

PEx>config>router>mpls# interface <topex> ¿

PEx>config>router>mpls>if# back ¿

Замечание: Повторите последние две команды для всех сетевых интерфейсов. Системный интерфейс конфигурируется по умолчанию.

1. Предыдущий шаг автоматически включает RSVP на интерфейсах. Убедитесь, что это так.

PEx# show router mpls interface ¿

1. Определите скорость порта, ведущего к вашему соседу по часовой стрелке. Какова рабочая скорость (operational speed)?

PEx# show port <X/X/X> ¿

Замечание: <X/X/X> = номер порта к вашему соседу по часовой стрелке.

1. Установите максимально резервируемую на интерфейсе пропускную способность для RSVP равной 100% от реальной пропускной способности интерфейса. Проверьте доступную пропускную способность.

PEx# configure router rsvp interface <topex> ¿

PEx>config>router>rsvp>if# subscription 100 ¿

Замечание: допускается резервирование пропускной способности интерфейса «с превышением» вплоть до 1000%.

PEx# show router rsvp interface <topex> detail ¿

1. Посмотрите базу данных Traffic Engineering и убедитесь, что по сети передается информация о пропускной способности звеньев эзернет.

PEx# show router ospf opaque-database detail ¿

1. Создание MPLS-пути. MPLS-путь состоит из последовательности участков (hop), каждый из которых представляет собой часть пути, соединяющую два маршрутизатора. Такой hop может быть типа «strict». В этом случае это элементарный участок, состоящий из звена непосредственно соединяющего два соседних маршрутизатора. Альтернативным вариантом будет hop типа «loose», представляющий из себя участок пути (не обязательно элементарный), соединяющий два маршрутизатора (не обязательно смежных) некоторым путем (возможно с транзитами), который автоматически выбирается системой.

Создайте пути к каждому из маршрутизаторов, используя участки типа «strict» по длинной внешней стороне кольца. Например, от PE1

· к PE4 через РЕ2 и РЕ3

· к РЕ3 через РЕ2

· к РЕ2 через РЕ4 и РЕ3.

PEx# configure router mpls ¿

PEx>config>router>mpls# path <p-topex> ¿

PEx>config>router>mpls>path# hop <Y> <X.X.X.X> strict ¿

PEx>config>router>mpls>path# no shutdown

Замечание: <Y> номер участка увеличивающийся на каждом шаге (например 10,20,30,… или 1,2,3,…).

Замечание: повторите последнюю команду для каждого участка создаваемого пути.

Замечание: повторите последние две команды для каждого из создаваемых путей к другим PE.

1. Создайте путь из одного участка типа «loose».

PEx>config>router>mpls# path <p-loose> ¿

PEx>config>router>mpls>path# no shutdown ¿

1. Проверьте конфигурацию ваших путей.

PEx# show router mpls path ¿

1. LSP (label switching path) - внутренне резервированная логическая структура, обеспечивающая симплексную передачу трафика между двумя точками MPLS-сети, состоящая из одного или нескольких путей (path), каждый из которых соединяет эти две точки, причем, один имеет статус первичного, а остальные – вторичных (резервных).

Создайте LSP ко всем PE сети, используя, ранее созданный «strict» путь в качестве первичного, а «loose» в качестве вторичного. Включите механизм выбора кратчайшего пути с учетом пропускной способности (Constrained Shortest Path First - CSPF) и установите пропускную способность для первичного пути, равной 10% от доступной пропускной способности (см. шаги 5-6).

PEx# configure router mpls ¿

PEx>config>router>mpls# lsp <l-topex> ¿

PEx>config>router>mpls>lsp# to <X.X.X.X> ¿

Замечание: <X.X.X.X> = IP-адрес системного интерфейса маршрутизатора в «хвосте» LSP (маршрутизатора, где оканчивается LSP).

PEx>config>router>mpls>lsp# cspf ¿

PEx>config>router>mpls>lsp# primary <p-topex> ¿

PEx>config>router>mpls>lsp>primary# bandwidth < 10%_от_общей_скорости > ¿

PEx>config>router>mpls>lsp>primary# exit ¿

PEx>config>router>mpls>lsp# secondary <p-loose> ¿

PEx>config>router>mpls>lsp>secondary# exit ¿

PEx>config>router>mpls>lsp# no shutdown ¿

1. Проверьте конфигурацию LSP. Какой объем пропускной способности зарезервирован за первичным? Какой объем пропускной способности зарезервирован за вторичным путем? Каково состояние вторичного пути?

PEx# show router mpls path lsp-binding ¿

PEx# show router mpls lsp detail ¿

PEx# show router mpls lsp path detail ¿

1. Выполните OAM LSP ping и trace на первичных и вторичных путях созданных LSP. Успешны ли пинги? Посмотрите, через какие узлы реально прошел первичный путь LSP? Соответствует ли он сконфигурированному «strict» пути? Успешны ли OAM LSP ping и trace successful вторичного пути LSP?

PEx# oam lsp-ping <l-topex> path <p-topex> ¿

PEx# oam lsp-ping <l-topex> path <p-loose> ¿

PEx# oam lsp-trace <l-topex> path <p-topex> ¿

PEx# oam lsp-trace <l-topex> path <p-loose> ¿

1. Измените статус вторичного пути на «standby» и повторите шаг 13. Что изменилось и почему?

PEx# configure router mpls lsp <l-topex> secondary <p-loose> standby ¿

1. Проверьте состояние MPLS и повторите шаг 7. Какова объявленная пропускная способность теперь?

PEx# show router mpls status ¿

 

Конфигурирование индивидуального быстрого перемаршрутирования (one-to-one Fast Reroute)

1. Помимо защиты с помощью вторичного пути, LSP может быть защищен от отказов на сети механизмом быстрого перемаршрутирования (Fast Reroute), позволяющего автоматически включать локальные обходы поврежденных участков. Fast Reroute бывает типа «one-to-one», когда для каждого поврежденного LSP создается свой индивидуальный обходной участок, или «one-to-many» («facility»), когда для всех поврежденный LSP используется один общий обходной участок.

Сконфигурируйте one-to-one Fast Reroute на LSP к противоположному маршрутизатору (на РЕ1 - l-tope3, на РЕ2 – l-tope4 и т.д.).

PEx# configure router mpls lsp <l-topex> fast-reroute one-to-one ¿

Замечание: к этому моменту первичный путь должен иметь резервирование пропускной способности 10% и вторичный путь должен быть в режиме standby.

PEx# show router mpls path lsp-binding ¿

1. Когда на всех узлах будет выполнен шаг 1, посмотрите сколько обходных LSP создано на вашем маршрутизаторе.

PEx# show router mpls status ¿

PEx# show router rsvp session (detail) ¿

1. Посмотрите LSPк противоположному от вас маршрутизатору. Какие типы обходов доступны? Активен ли обход?

PEx# show router mpls lsp <l-topex> path detail ¿

1. Какая MPLS-метка используется первичным путем на следующем участке? Какая метка будет использована для обхода, если первичный путь откажет?
2. Деактивируйте вторичный путь на LSP к противоположному маршрутизатору.

PEx# configure router mpls lsp <l-topex> secondary <p-loose> shutdown ¿

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

1. Выключите порт, используемый следующим участком LSP к противоположному маршрутизатору. Повторите шаг 3. Активен ли обход теперь?

 

Объявление клиента (Customer)

1. «Customer» понимается как оператор внешней сети, являющийся пользователем нашей сети и ее сервисов. Объявите двух клиентов (100 and 200). Снабдите клиентов данными: описанием, контактной информацией и номером контактного телефона.

Замечание: внутреннее соответствие данных связанных с customer автоматически контролируется на уровне маршрутизатора, однако крайне желательно обеспечивать их соответствие и в пределах всей сети. Это особенно критично, когда используется внешняя система управления сетевого уровня (5620SAM).

PEx# configure service customer 100 create ¿

Pex>config>service>cust# description <customer_name> ¿

Pex>config>service>cust# contact <customer_contact> ¿

Pex>config>service>cust# phone <customer_phone> ¿

Подготовка портов

Конфигурация сервисов, создаваемых провайдером, включает точки доступа к сервису SAP – логические объекты, базирующиеся на физических портах маршрутизаторов провайдера. Они используются в качестве места стыка сетей пользователя и провайдера сервиса. К SAP подключается сеть клиента.

1. Измените тип порта 1/1/8 на «access». В нашем случае выбор конкретного порта жестко определяется программно-аппаратными возможностями эмулятора.

PEx# configure port 1/1/8 ¿

Pex>port# shutdown ¿

Pex>port# ethernet mode access ¿

Pex>port# no shutdown ¿

1. Измените максимальную длину пакета (MTU) на всех сетевых («network») портах на 1600.

Замечание: Сетевые порты MPLS должны заведомо иметь MTU больше, чем стандартно по умолчанию (1540 байт). Это связано с тем, что в пакеты, передаваемые через эти порты, инкапсулируются пользовательские пакеты со стандартным значением MTU. Таким образом, длина пакета на сетевом порте должна быть больше стандартной, как минимум, на заголовок инкапсуляции

PEx# configure port <X/X/[1..4]> ethernet mtu 1600 ¿

PEx# show port <X/X> ¿

 

Конфигурирование полносвязной структуры (full mesh)SDPs

1. Для использования в составе сервисов применяются так называемые «сервисные туннели», которые объявляются на базе LSP.

Сконфигурируйте полносвязную структуру SDP на базе RSVP-TE, соединяющую ваш маршрутизатор с другими маршрутизаторами сети.

Замечание: Несколько сервисов могут использовать один SDP. Для различения пакетов, относящихся к разным сервисам в этих условиях, используются дополнительные (сервисные или VC) метки. За их присвоение и согласование отвечает специальный протокол TLDP ((targeted LDP).

PE# configure service sdp <2X> mpls create ¿

PE>config>service>sdp$ far-end <X.X.X.X> ¿

PE>config>service>sdp$ description <“SDP to PE X over RSVP-TE”> ¿

PE>config>service>sdp$ lsp <l-topex> ¿

PE>config>service>sdp$ signaling tldp ¿

PE>config>service>sdp$ no shutdown ¿

PE>config>service>sdp$ exit all ¿

Замечание: повторить процедуру для всех удаленных РЕ. Здесь Х – номер РЕ.

2. Проверьте созданные SDP.

PE# show service sdp (detail) ¿

Замечание: если SDPs остался в состоянии «operationally down», попробуйте найти причину, внимательно проверив содержимое рапорта команды show service sdp <sdp_id> detail..

Проверка инструментальными средствами OAM

Замечание: SDP Ping обеспечивает внутритуннельный одно- или двунаправленный тест целостности SDP (одного или пары). Пакеты SDP Ping OAM посылаются через тоннель, используя ту же инкапсуляцию, что и пакеты трафика. Таким образом, они передаются точно тем же путем, что и пакеты трафика внутри сервиса. Ответ SDP Ping может передаваться вне тоннеля (однонаправленное тестирование одного SDP) или внутри второго SDP (в случае двунаправленного теста).

1. Выполните однонаправленный SDP Ping. Какова величина «Path MTU»? Почему отсутствует Remote SDP-ID?

PEx# oam sdp-ping <XX> ¿

Замечание: Вы протестировали локальные SDP, но не выполнили двунаправленный тест.

<XX> локальный SDP.

1. Выполните двунаправленный SDP Ping Test. Каково значение Remote SDP-ID?

PEx# oam sdp-ping <XX> resp-sdp <YY> ¿

Замечание: Это двунаправленный тест в обоих направлениях для передачи пинга используются SDP.

<XX> локальный SDP и <YY> SDP с удаленной стороны.

1. Определите размер MTU поддержанный SDP.

Замечание: Важно понимать, что MTU, поддерживаемые SDP, должно обеспечивать в рамках сервиса передачу самых длинных пакетов заказчика.

PEx# oam sdp-mtu <XX> size-inc 1450 1500 step 10 ¿

Замечание: <XX> локальный SDP.

Конфигурирование сервиса ePipe

Сервис ePipe (также называемое Virtual Leased Line - VLL) обеспечивает соединение типа «точка-точка» между двумя узлами. С точки зрения клиента функционирует, как арендованная линия, соединяющая две точки его сети. Провайдер может ассоциировать с этим сервисом учет стоимости и контроль профиля трафика (shaping and policing) по входу и по выходу.

 

1. Создайте сервис ePipe 500 вашим PE и соседним PE. В учебной сети создаются два сервиса ePipe:

· между РЕ1 и PE2

· между РЕ3 и PE4

Объявите точку доступа к сервису (SAP), на ранее подготовленном порте 1/1/8

PEx# config service epipe 500 customer 100 create ¿

PEx>config>service>epipe$ sap <1/1/8>:0 create ¿

Замечание: «0» в конце идентификатора SAPозначает отсутствие инкапсуляции, что в свою очередь означает, что порт используется исключительно данным сервисом. Возможен случай, когда один физический порт используется несколькими сервисами. В этом случае используется инкапсуляция Dot1q или qinq

PEx>config>service>epipe>sap$ back ¿

PEx>config>service>epipe$ spoke-sdp <2X>:500 create ¿

Замечание: Используется SDP на основе RSVP-TE. В этом SDP в предыдущем упражнении был включен протокол TLDP. Запись «:500» привязывает SDPк сервису. В этот момент TLDP-метки связываю сервис с окончаниями туннеля ePipe.

“Spoke-sdp” означает, что в отличие от «mesh-sdp”? Этот sdp будет использоваться в режиме «точка-точка».

PEx>config>service>epipe>spoke-sdp$ back ¿

PEx>config>service>epipe$ no shutdown ¿

1. Проверьте созданный сервис ePipe. Какая метка используется для соединения с удаленным РЕ? Какая метка используется для сервиса ePipe на удаленном PE?

PEx# show service sap-using ¿

PEx# show service service-using ¿

PEx# show service id 500 all ¿

PEx# show service id 500 labels ¿

PEx# show router ldp bindings ¿

 

Проверка инструментальными средствами OAM

1. Проверьте работу вашего сервиса ePipe используя Service Ping.

Замечание: Service Ping обеспечивает проверку целостности отдельного сервиса из конца в конец. Service Ping работает на более высоком уровне, чем диагностика SDP. Он проверяет отдельный сервис, а не совокупность сервисов, использующих данный SDP. Проверяются следующие параметры из конца в конец:

Ø Целостность туннеля

Ø Присвоение VC-меток

Ø Существование сервиса

Ø Взаимное соответствие параметров сервиса

Ø Задержку распространения по шлейфу

Ø Динамическую конфигурацию сервиса

PEx# oam svc-ping <X.X.X.X> service 500 ¿

Замечание: в данном варианте service ping не используется реальный путь передачи пользовательских данных в сервисе. OAM сообщения передаются в рамках управляющего плана, а не плана данных. Для того чтобы посылать пакеты пинга по тому же пути, что и пользовательский трафик, необходимо использовать параметры local-sdp и remote-sdp.

PEx# oam svc-ping <X.X.X.X> service 500 local-sdp remote-sdp ¿

Замечание: <X.X.X.X> системный IP-адрес удаленного PE.

Замечание: svc-ping – полезное диагностическое средство для VLL, но оно требует, чтобы порт в сторону оборудования заказчика был в активном состоянии, т.е. чтобы к нему было подключено работающее оборудование. В момент, когда сервис только сконфигурирован это условие может не выполняться., поэтому в такой ситуации для проверки VLL удобнее использовать утилиту VCCV-Ping.

1. Проверьте работу вашего сервиса ePipe с помощью утилиты VCCV-ping.

Замечание: утилита VCCV Ping обеспечивает проверку целостности отдельного сервиса ePipe из конца в конец и использует для проверки целостности VLL метом «in-band», т.е. посылает сообщения VCCV Ping с той же инкапсуляцией и через тот же туннель, что и пакеты реального трафика VLL. VCCV Ping проверяет соответствие между планом данных и планом управления. Базируется на механизме LCP ping.

PEx# oam vccv-ping <2X>:500 reply-mode ip-routed ¿

Конфигурирование сервиса VPLS

1. Сервис VPLS (virtual private LAN service) представляет собой эмуляцию локальной сети для заказчика на базе MPLS-сети провайдера. Провайдер может ассоциировать с этим сервисом учет стоимости и контроль профиля трафика (shaping and policing) по входу и по выходу. Поскольку сеть провайдера в данном случае эмулирует работу коммутатора Ethernet, она должна обеспечивать процедуру заучивания МАС-адресов в пределах VPLS.

Сконфигурируйте сервис VPLS 600, включающий все четыре маршрутизатора.

Замечание: удалите SAP сервиса ePipe для того, чтобы использовать его в данном лабораторном упражнении (VPLS service).

PEx> config>service>epipe 500 ¿

PEx>config>service>epipe# shutdown ¿

PEx>config>service>epipe# sap <1/1/8>:0 ¿

PEx>config>service>epipe>sap$ shutdown ¿

PEx>config>service>epipe>sap$ back ¿

PEx>config>service>epipe# no sap <1/1/8>:0 ¿

Ctl+Z

PEx# configure service vpls 600 customer 100 create ¿

PEx>config>service>vpls# sap <X/X/X>:0 create ¿

PEx>config>service>vpls>sap$ back ¿

PEx>config>service>vpls# mesh-sdp <2X>:600 create ¿

PEx>config>service>vpls>mesh-sdp$ back ¿

Замечание: Повторите последние две команды для всех удаленных PE. Необходимо организовать полносвязную структуру SDP между всеми включенными в VPLS сервис РЕ. На SDP включен протокол TLDP обеспечивающий назначение сервисных меток. «:600» привязывает SDP к сервису. С этого момента протокол TLDP передает сервисную метку всем участникам VPLS.

PEx>config>service>vpls# no shutdown ¿

1. Проверьте VPLS. Какие метки используются для связи с другими PE? Какие метки используют удаленные PE для данного сервиса VPLS?

PEx# show service sap-using ¿

PEx# show service service-using ¿

PEx# show service id 600 all ¿

PEx# show service id 600 labels ¿

PEx# show router ldp bindings ¿

 

Варианты заданий

Каждая из четырех бригад работает на своем маршрутизаторе, выполняя задания строго по порядку. Для возможности проверки результатов важна синхронная работа бригад, в частности, при создании сервисов.

 

Содержание отчета

В индивидуальном отчёте должны быть приведены схемы созданных сервисов ePipe и VPLS с указанием использованных SAP, SDP, LDP, транспортных и сервисных меток.

 

Контрольные вопросы

1. Чем отличается обработка пакетов в маршрутизаторе IP/MPLS от обычной маршрутизации?

2. Чем отличаются порты SAP от портов SDP?

3. Объясните механизм организации туннеля 2-го уровня – LSP.

4. Поясните отличия в сервисах e-Pipe и VLL.

5. Дайте определение сервиса VPLS.

Литература

1. Деарт В.Ю. Мультисервисные сети связи. Транспортные сети и сети доступа. – М.: Инсвязьиздат, 2008, 166 с.