Match route instance джунипер что это

Обзор экземпляров маршрутизации

Вы можете создавать несколько экземпляров BGP, IS-IS, LDP, multicast Source Discovery Protocol (MSDP), OSPF версии 2 (обычно называют просто OSPF), OSPF версии 3 (OSPFv3), протокольной независимой многоадресной передачи (PIM), RIP, RIP следующего поколения (RIPng), а также статические маршруты, включая заявления на следующих уровнях иерархии:

[edit routing-instances routing-instance-name protocols]

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols]

В одном экземпляре маршрутизации можно настроить только один экземпляр каждого протокола.

Вы также можете создать несколько экземпляров маршрутизации для разделения таблиц маршрутизации, политик маршрутизации и интерфейсов для отдельных оптовых абонентов DHCP (розничных торговцев) на уровне 3 оптовой сети. Для получения информации о том, как настроить оптовые сетевые сервисы уровня 3, см. Библиотеку управления абонентами и сервисами на базе ОС Junos.

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

Каждый экземпляр маршрутизации имеет уникальное название и соответствующую таблицу IP-одноадресной передачи. Например, если настроить экземпляр маршрутизации с именем my-instance , соответствующая таблице IP-одноадресной передачи my-instance.inet.0 . Все маршруты для my-instance устанавливаются в my-instance.inet.0 .

Экземпляр маршрутизации master по умолчанию относится к главной inet.0 таблице маршрутизации. Главный экземпляр маршрутизации защищен и не может быть указан в качестве экземпляра маршрутизации.

Каждый экземпляр маршрутизации состоит из следующих наборов:

Интерфейсы, принадлежащие этим таблицам маршрутизации (необязательно в зависимости от типа экземпляра маршрутизации)

Операция фиксации ошибок при настройке одного и того же логического интерфейса как для каналов уровня 2, так и для ccc-подключения.

Конфигурации варианта маршрутизации

Можно настроить 13 типов экземпляров маршрутизации:

Ethernet VPN (EVPN) (только маршрутизаторы серии MX)— Используйте этот тип экземпляра маршрутизации для подключения группы разогнаенных объектов клиентов с помощью виртуального моста уровня 2.

Переадресация — используйте этот тип экземпляра маршрутизации для приложений переадресации на основе фильтров. В этом типе экземпляра нет единого отображения между интерфейсом и экземпляром маршрутизации. Все интерфейсы принадлежат к экземпляру inet.0 по умолчанию.

Многоадресная передача в Интернете по MPLS — используйте этот тип экземпляра маршрутизации для поддержки впуска туннелей поставщиков репликации для передачи данных многоадресной передачи IP между маршрутизаторами через облако MPLS с использованием MBGP или MVPN нового поколения.

Протокол VPN-подключение на уровне 2 (только маршрутизаторы серии MX) Используйте этот тип экземпляра маршрутизации для поддержки пакетов VLAN уровня 2 с отсутствием соответствующего . При использовании этого экземпляра маршрутизатор узнает как внешний тег, так и внутренний тег входящих пакетов, когда instance-role заявление определяется как access или только внешний тег VLAN, когда instance-role заявление определяется как nni .

Контроль уровня2 (только маршрутизаторы серии MX) Используйте тип экземпляра маршрутизации для RSTP или MSTP в граничных интерфейсах клиентов экземпляра маршрутизации VPLS. Этот тип экземпляра не может использоваться, если граничные интерфейсы клиента многоарокизированы с пограничными интерфейсами двух поставщиков. Если интерфейс граничного интерфейса клиента предназначен для двух граничных интерфейсов поставщика, используйте туннелирование BPDU по умолчанию.

VPN-подключение уровня 2 — используйте этот тип экземпляра маршрутизации для реализации виртуальной частной сети уровня 2 (VPN).

MAC-VRF (маршрутизаторы серии MX и vMX; коммутаторы QFX5100, QFX10002-60C, QFX5110, QFX5120, QFX5200, QFX10002, QFX10008 и QFX10016; Только коммутаторы серии EX9200) Используйте этот тип экземпляра маршрутизации для настройки нескольких экземпляров EVPN для клиентов, mac-vrf каждый из которых может поддерживать другой тип сервиса EVPN. Такая конфигурация приводит к тому, что таблицы виртуальной маршрутизации и пересылания (VRF) для конкретных клиентов с MAC-адресами на каждом устройстве Juniper Networks, которое служит виртуальным конечным устройством туннеля (VTEP) в сети EVPN-VXLAN. Этот тип экземпляра маршрутизации предназначен только для маршрутов одноадресной передачи EVPN.

MPLS- Используйте этот тип экземпляра маршрутизации для защиты от спуфинга меток или странствующей инъекции меток в пограничных маршрутизаторах автономной системы (ASBRs).

Непреднаказанное: используйте этот тип экземпляра маршрутизации при необходимости разделения информации о таблице маршрутизации. Соответствующей таблицы переадресации нет. Все маршруты устанавливаются в таблицу переадресации по умолчанию. Экземпляры IS-IS — это строго невзгодные типы экземпляров.

Виртуальный маршрутизатор — как и тип экземпляра маршрутизации и переадресации VPN, но используется для приложений, не связанных с VPN. Нет никакого виртуального импорта маршрутизации и переадресации (VRF), экспорта VRF, целевого показателя VRF или требований к разграничению маршрутов для этого типа.

Виртуальный коммутатор (только маршрутизаторы серии MX) Используйте тип экземпляра виртуального коммутатора для изоляции сегмента локальной сети с помощью экземпляра протокола STP и разделения пространства идентификатора VLAN. Для получения более подробной информации о настройке виртуального коммутатора см. библиотеку коммутации и преодоления на уровне ОС Junos для устройств маршрутизации на уровне 2.

VPLS— Используйте тип экземпляра маршрутизации виртуальной частной локальной сети (VPLS) для реализации локальной сети между набором объектов в VPN.

VRF — используйте тип экземпляра маршрутизации и переадресации VPN (VRF) для реализации VPN-подключения уровня 3. Этот тип экземпляра маршрутизации имеет таблицу маршрутизации VPN, а также соответствующую таблицу переадресации VPN. В этом типе экземпляра между интерфейсом и экземпляром маршрутизации имеется одно-одно картирование. Каждый экземпляр VRF соответствует таблице переадресации. Маршруты интерфейса переходят в соответствующую таблицу переадресации.

Настраивайте глобальные варианты маршрутизации и протоколы для основного экземпляра, включив в них заявления на [edit protocols] уровнях и [edit routing-options] уровнях иерархии. Маршруты устанавливаются в главный экземпляр inet.0 маршрутизации по умолчанию, если не указан экземпляр маршрутизации.

Для реализации VPN-подключения уровня 3 используется несколько экземпляров BGP, OSPF и RIP. Несколько экземпляров BGP, OSPF и RIP хранят информацию о маршрутизации для разных VPN-сетей отдельно. Экземпляр VRF рекламирует маршрутизатор от граничного маршрутизатора клиента до маршрутизатора границы поставщика услуг (PE) и рекламирует маршрутизаторы от маршрутизатора PE до маршрутизатора CE. Каждый VPN получает только информацию маршрутизации, принадлежащую этому VPN.

Экземпляры переадресации используются для реализации переадресации на основе фильтров для приложений на уровне общего доступа.

Экземпляры PIM используются для многоадресной передачи по VPN-приложениям.

Непреднамеренные экземпляры IS-IS и OSPF можно использовать для разделения очень большой сети на небольшие административные организации. Вместо настройки большого количества фильтров для фильтрации маршрутов могут использоваться непреднамеренные экземпляры, тем самым внедряя политики. Для сокращения объема информации о маршрутизации, рекламируемой во всех компонентах сети, могут использоваться непредназначенные экземпляры. Информация о маршрутизации, связанная с определенным экземпляром, может быть объявлена в случае необходимости вместо того, чтобы рекламироваться по всей сети.

Экземпляры VPN-на уровне 2 используются для реализации VPN-на уровне 2.

Экземпляры виртуальных маршрутизаторов аналогичны типу маршрутизации и переадресации VPN, но используются для приложений, не связанных с VPN. Нет никаких требований к импорту VRF, экспорту VRF, целевому показателю VRF или отличительным требованиям к маршрутизатору для этого типа.

Используйте тип маршрутизации VPLS для реализации локальной сети между набором объектов в VPN.

Чтобы настроить тип экземпляра маршрутизации, используйте instance-type заявление на уровне иерархии [ edit routing-instances routing-instance-name ].

Чтобы настроить экземпляр маршрутизации, укажите следующие параметры:

Название экземпляра маршрутизации. Каждый экземпляр маршрутизации имеет уникальное название и соответствующую таблицу IP-одноадресной передачи. Например, если настроить экземпляр маршрутизации с именем my-instance, соответствующая таблица IP-одноадресной передачи — это my-instance.inet.0. Все маршруты для моего экземпляра установлены в my-instance.inet.0 .

Невозможно указать название экземпляра маршрутизации по умолчанию или включить специальные символы в название экземпляра маршрутизации.

Тип экземпляра маршрутизации.

Интерфейсы, привязанные к экземпляру маршрутизации. Интерфейсы, не обязательные для типа экземпляра маршрутизации переадресации.

Чтобы настроить экземпляр маршрутизации, используйте routing-instances заявление на уровне иерархии [ edit ].

Вы можете создать экземпляр BGP, IS-IS, OSPF, OSPFv3, RIP или RIPng, включив конфигурирование на [edit routing-instances routing-instance-name protocols] уровне иерархии. Вы также можете настроить статические маршруты для экземпляра маршрутизации.

Juniper routing instances

Routing Instance – это совокупность таблиц маршрутизации, интерфейсов и параметров протоколов маршрутизации. Протоколы маршрутизации контролируют информацию в таблицах маршрутизации, причем в одной routing instance могут быть как IPv4, так и IPv6 маршруты одновременно, а так же несколько физических или логических интерфейсов. Один физический интерфейс, разбитый на несколько логических unit-ов (субинтерфейсов), может быть отнесен к разным routing instance (однако один и тот же unit (субинтерфейс) или, не разделенный на unit-ы, физический интерфейс, нельзя прикрепить к разным routing instance).

Routing instance — мощнейший инструмент операционной системы JunOS, позволяющий при совместном использовании c rib-groups, firewall filters и policy выполнить любую задачу. К сожалению, многие инженеры не знают о назначении большинства routing instances, кроме всем до боли знакомой VRF.

JunOS предоставляет нам большой выбор routing instance, доступных для конфигурирования:

На момент написания статьи доступны для конфигурирования следующие типы routing instance:
1. VRF,
2. Forwarding,
3. Virtual router,
4. Nonforwarding,
5. VPLS,
6. Layer 2 VPN,
7. Layer2-control (MX Series routers only),
8. Virtual switch (MX Series routers only),
9. Layer 2 Backhaul VPN (MX Series routers only) (о ней я постараюсь написать отдельный пост).

Если кто-то обнаружит какую то какие либо описки или неточности в статье (я тоже человек и могу ошибиться) или у кого-то будут дополнения, прошу писать личные сообщения с ссылками на необходимую информацию.

VRF (Virtual routing and forwarding).

Этот тип routing instance знают почти все. По своему функционалу он подобен аналогичному из мира Cisco и используется для реализации сервисов на базе MPLS (например для L3VPN, 6VPE).

VRF не является каким то отдельным маршрутизатором внутри основного маршрутизатора (или коммутатора). VRF изолирует таблицу маршрутизации и интерфейсы клиента от основной таблицы маршрутизации и интерфейсов маршрутизатора, а так же от таблиц маршрутизации и интерфейсов других клиентов. Конфигурация VRF выглядит следующим образом:

Функционал данной routing-instance поддерживает все протоколы маршрутизации, статические маршруты, протокол распределения меток ldp (но rsvp — не поддерживается), а так же экспорт и импорт маршрутов (из протоколов маршрутизации основной routing-instance и других VRF, сконфигрурированных на маршрутизаторе).

В конфигурации обязательно надо указать уникальное значение route-distinguisher, значения route-targets (import и export), а так же интерфейс (или интерфейсы) в сторону клиента, относящиеся к данной routing-instance. Использование RT и RD является одними из ключевых понятий в реализации l3vpn (соответственно и других технологий, использующих данную логику, например 6VPE) — именно эти два значения позволяют использовать пересекающуюся адресацию у клиентов (RD) и производить фильтрацию префиксов, получаемых от разных клиентов и последующей инсталяцией их в изолированные таблицы маршрутизации (RT). Данная routing-instance создает свою таблицу маршрутизации, которая имеет наименование instance_name.inet.0 или instance_name.inet6.0:

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

Помимо таблицы маршрутизации клиента, на маршрутизаторе будет создана еще одна таблица маршрутизации bgp.l3vpn.0, в которую устанавливаются все маршруты, полученные маршрутизатором по протоколу bgp (address family inet-vpn unicast), согласно сконфигурированным значениям RT import:

Примечание: в конфигурации есть команда vrf-table-label. По умолчанию JunOS использует per-next-hop label allocation для маршрутов клиентов. Указанная выше команда переводит режим распределения меток в per-vrf, то есть все маршруты данной vrf будут иметь одну и ту же метку. (Если кому то будет интересно, напишу статью об этом.)

Переходим к следующему типу routing instance — Forwarding.

Как известно, JunOS отпугивает многих новичков длинными и на первый взгляд не понятными конфигурациями, особенно если этот новичок пришел из мира Cisco. К примеру, если в Cisco вам надо сделать policy based routing (PBR), то вы пишите access-list и простенький route-map. В JunOS все сложнее, но поняв подход Juniper, вы поймете на сколько он элегантнее цисковского. Зачем я это пишу? Дело в том, что routing instance Forwarding задумывалась именно для целей PBR (в мире Juniper этот вид маршрутизации носит имя filter based routing). Ниже предствлена конфигурация данной routing instance:

Все просто — ни каких RT, RD. Эта routing instance не поддерживает указание интерфейса и конфигурирование протокола маршрутизации*. Дело в том, что для работы FBR этого и не надо. Мы делаем статический маршрут с нужным нам next-hop, а на интерфейс, с которого пакеты будут прилетать на маршрутизатор, мы вешаем filter, который в случае совпадения, к примеру, исходящего адреса, будет отправлять трафик через сконфигурированную routing instance по статическому маршруту, в противном случае пакет «полетит» согласно основной таблицы маршрутизации.

Есть одно но, что бы routing instance могла отправить пакет на нужный next-hop, нам надо что бы у нее был маршрут к этому next-hop. Для этого нам надо перенести маршруты из таблицы маршрутизации inet.0 в таблицу маршрутизации сконфигурированной routing instance (которая будет иметь название instance_name.inet.0), причем не все маршруты а только необходимые (не забываем и про directly connected). Делается это с помощью rib groups, описание можно почитать тут тут.

Данная routing instance создает свою таблицу маршрутизации, манипулируя содержанием которой, мы можем направить трафик по маршруту, отличному от основного.

* JunOS позволит вам сконфигурировать например ospf или isis в данном типе routing instance (BGP — не поддерживается), но так как у вас нет интерфейсов, закрепленных за routing instance, использование протокола маршрутизации будет бессмысленно, а добавить маршруты из основной таблицы можно через rib-groups без использования отдельного протокола маршрутизации.

Virtual router.

Функционал routing instance virtual router сходен с vrf-lite из мира Cisco. Данная routing instance позволяет запускать любые протоколы маршрутизации от rip до bgp, создавать GRE и ipsec тоннели, реализовывать функционал nat и dhcp, а так же поддерживает протокол LDP (однако RSVP не поддерживается). Основной задачей данной routing instance является изоляция интерфейса (интерфейсов) клиента и его таблицы маршрутизации. Ближайшим родственником virtual-router можно назвать routing instance no-forwarding (будет описан ниже), их функционал несколько схож. Но, рассматриваемый нами тип routing instance устанавливает маршруты в отдельную таблицу маршрутизации, которая имеет наименование instance_name.inet.0 (instance_name.inet6.0):

Клиенту отдаются только маршруты, которые есть в данной routing-instance. С помощью rib groups можно произвести перераспределение маршрутов из основной таблицы маршрутизации в таблицу маршрутизации клиента или перераспределить маршруты между virtual routers, которые «живут» на маршрутизаторе.

Данный тип routing instance используется довольно таки часто. Если его сравнивать с VRF, то данная routing instance избавлена от необходимости конфигурирования RT и RD. Пример конфигурации данной routing-instance представлен ниже:

Следующий тип routing instance – No-forwarding.

Данный тип routing instance, в отличии от трех предыдущих, хоть и создает свою таблицу маршрутизации, но все маршруты инсталирует в основную default forwarding table.

Отличие fib от rib состоит в том, что в rib попадают все маршруты например протокола ospf (например к одному и тому же префиксу есть два маршрута — оба и будут отображены в rib), но только лучший из этих маршрутов попадет в fib и будет использоваться для передачи трафика (исключения, например ECMP). Так же rib предназначена для хранения и обмена маршрутной информацией между пирами в сети и для пересылки трафика она не удобна. Fib же как раз и предназначена для быстрого поиска необходимых для пересылки трафика данных и дает возможность реализовать аппаратную обработку трафика.

Данную routing instance применяют когда необходимо произвести сегментацию сети на третьем уровне (подобно VLAN). Конфигурация представлена ниже:

Примечание: auto-export обязательно должно быть сконфигурировано в основной routing instance и routing instance no-forwarding, иначе ожидаемого результата вы не получите.

Разберем как работает данная routing instance. Мы имеем несколько сконфигурированных routing instance:

Из вывода следует, что у нас три сконфигурированных и одна default routing instance ( private routing instance мы не рассматриваем):

1.virtual-router с типом virtual-router (соответствует таблица маршрутизации virtual-router.inet.0)
2.forward с типом forwarding (соответствует таблица маршрутизации forward.inet.0)
3.default (соответствует таблица маршрутизации inet.0)
4.no-frw с типом non-forwarding (соответствует таблица маршрутизации no-frw.inet.0)

Пока все как обычно — у каждой routing instance есть своя таблица маршрутизации.
Теперь посмотрим как обстоят дела с forwarding-table на маршрутизаторе:

Созданы только forwarding-table для:
1.virtual-router.inet.0
2.forward.inet.0
3.default.inet.0

forwarding-table для no-frw.inet.0 не существует, потому то routing instance no-forwarding инсталирует свои маршруты в forwarding-table default (точнее сказать, помимо своей таблицы маршрутизации, routing instance no-forwarding экспортирует свои маршруты в defaul inet.0, откуда они и попадают в defaul fib).

Тогда возникает вопрос – а зачем нам эта routing instance? В отличии от Cisco, на оборудовании Juniper нельзя запустить две копии одного и того же протокола маршрутизации в одной и той же instance. То есть, если в Cisco мы можем запустить процесс ospf 1 и процесс ospf 2 одновременно, то в JunOS на уровне иерархии [edit protocols], нет возможности запустить две копии одного и того же процесса, например OSPF (не путайте с area, их как раз таки может быть несколько). Данная routing instance предназначена как раз для запуска нескольких копий одного протокола маршрутизации.

Функционал данной routing instance поддерживает все протоколы маршрутизации, за исключение BGP. Не поддерживаются и протоколы распределения меток ldp или rsvp.

Для полноты картины рассмотрим такую схему (взял с сайта Juniper):

Итак, предположим, что мы хотим, что бы CE2 мог общаться только с CE3, и, соответственно, CE1 мог общаться только с CE4. Тут то мы и воспользуемся routing instance no-forwarding.
Мы создаем на PE0 и PE2 две routing instance (1 и 2) с типом no-forwarding, указываем в них необходимый интерфейс и запускаем ospf.

Создаем политики, согласно которых, процесс ospf routing instance 1, получая маршруты от CE1, добавляет к этим маршрутам тег 100 и экспортирует в default rib inet.0, а процесс ospf routing instance 2 добавляет к полученным от CE2 маршрутам тег 200 и экспортирует в default rib inet.0.

То есть мы получили в inet.0 все маршруты от CE1 и CE2, причем мы четко можем разделить, какие маршруты пришли от CE1, а какие от CE2.

Далее, эти маршруты передаются на PE2 вместе с тегами. С помощью политики, на PE2 в routing instance 1 мы указываем, что надо экспортировать на CE3 только маршруты с тегом 200, и, соответственно, на CE4 только маршруты с тегом 100. В итоге мы получили практически VLAN на третьем уровне.

Как мы и хотели, обмен трафиком возможен между CE1 и CE4, и соответственно между CE2 и CE3; Почему между CE1 и CE3 обмен трафиком невозможен? По простой причине – у CE1 нет маршрута до CE2 или CE3. Аналогичная картина будет и на остальных маршрутизаторах данной топологии.

На первый взгляд рассмотренная routing instance очень похожа на virtual-router. Но надеюсь что теперь вы понимаете, что она предназначена для иных целей и имеет меньший функционал.

Принцип работы технологии VPLS не входит в текст данной статьи, но будет частично затронут в ходе пояснений (иначе ничего не объяснить).

Нам нужно реализовать Virtual Private LAN Service, мы создаем данную routing instance. По сути повторяет функционально VRF (особенно при использовании BGP сигнализации), но предназначена для реализации L2 сервисов. Данный тип routing instance позволяет автоматически создавать полносвязную топологию из виртуальных l2 соединений между сайтам клиента. Эта routing instance, в связи с отсутствием необходимости запуска протоколов маршрутизации и распределения меток, их конфигурирование не поддерживает. Так как данная routing instance работает с l2 а не IP адресами, то forwarding table хранит mac адреса:

Ниже представлена таблица маршрутизации одного из клиентов (BGP signaling):

10.0.1.1:100:1:1/96 — этот префикс обозначает сайт клиента и состоит из:
1. 10.0.1.1:100 — RD
2. 1 — site-id
3. 1 — label block offcet (сдвиг блока меток, если кому интересно, могу написать отдельную статью об операциях с метками при организации VPLS)

Помимо представленной выше таблицы маршрутизации, в JunOS будет еще одна таблица маршрутизации bgp.l2vpn.0, в которой будут отображены все l2vpn маршруты данного PE маршрутизатора (при использовании bgp как сигнализацию):

Конфигурация данной routing instance зависит от того, какая сигнализация используется для организации VPLS – BGP (драфт Компелла) или LDP (Мартини). В зависимости от вашего выбора конфигурация будет меняться.

Если мы реализуем VPLS согласно драфту Компелла (BGP signaling), то конфигурация будет выглядеть вот так:

Так как драфт Компелла включает autodiscovery PE маршрутизаторов, то в конфигурации необходимо помимо интерфейса, указать RT и RD. Как я показал раннее, RD используется для поиска и идентификации PE маршрутизаторов, к которым подключены сайты клиента. На уровне иерархии [edit routing-instance protocols vpls] необходимо указать название сайта, его site-identifier (это JunOS может задавать автоматически, если это указать в конфигурации) и максимальное количество сайтов (site-range) клиента, причем site-identifier должен быть меньше, чем site-range.

Если мы используем LDP-сигнализацию (Мартини), то конфигурация будет немного проще:

Данная технология VPLS не поддерживает autodiscovery без дополнительного «костыля»*, поэтому в базовой конфигурации указывается только интерфейс, к которому подключен клиент, нет ни RT, ни RD. На уровне иерархии [edit routing-instance protocols vpls] необходимо указать лупбеки всех PE маршрутизаторов, к которым подключены сайты клиента, а так же VPLS-ID, который должен совпадать для все VPLS routing instance данного клиента.

* для использования autodiscovery в данном случае необходимо использовать BGP, используя address family bgp l2vpn auto-discovery-only. При этом явно указывать соседей на PE маршрутизаторах не надо, но тогда необходимо сконфигурировать RT, RD а так же l2vpn-id:

Проверить состояние соединений, которые данная routing instance установила можно командой show vpls connections:

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

Layer 2 VPN

В Junos есть (во всяком случае я знаю) три способа создать l2vpn (в отличии от VPLS, l2vpn имеет топологию p2p). Данная routing-instance близка по конфигурации и сигнализации к VPLS BGP signaling. Конфигурация предусматривает указание rd и rt для поиска PE-маршрутизаторов и последующего установления p2p соединения:

Как и ее старший брат routing-instance vpls, данная routing-instance, в силу своего назначения, не подразумевает настройки протоколов маршрутизации.

Плюсом данной routing-instance является простота настройки и, в отличии от других типов l2vpn, обладает лучшей масштабируемостью (при необходимости легко добавляются другие сайты). В отличии от VPLS, routing-instance l2vpn не поддерживает кроссплатформенное взаимодействие (например между Juniper и Cisco).

Данная routing-instance не дает возможности создать VPLS, хотя дает возможность сконфигурировать более одного виртуального L2 соединения (но это не будет полноценным VPLS).

Таблица маршрутизации выглядит практически так же как и VPLS:

Проверить состояния соединений можно с помощью команды show l2vpn connections, причем вывод будет подобен выводу show vpls connections (routing-instance VPLS).

Layer2-control

Данная routing-instance предназначена для запуска протокола семейства STP при использовании VPLS Multihoming. Ее применение очень хорошо описано в этой статье, поэтому не буду повторяться.

Virtual switch

Помимо маршрутизации, маршрутизаторы серии MX могут выполнять и функции, присущие исключительно коммутатору. Изначально, при конфигурировании VLAN и trunk портов на маршрутизаторе MX-серии, все VLAN и trunk интерфейсы попадают в одни bridge domian, который называется default-switch routing-instance. Маршрутизаторы MX серии предоставляют возможность сконфигурировать пользовательские routing-instance virtual-switch:

Данная routing-instance позволяет реализовать на маршрутизаторе функционал коммутатора и производит изолирование интерфейсов и одного или более VLAN. То есть virtual switch позволяет производить сегментацию сетей на втором уровне, не прибегая к сегментированию сети на третьем уровне (что сохранит нам IP адреса). Для каждого сегмента можно запустить свой протокол из семейства STP. Маршрутизаторы серии MX поддерживают протоколы: STP, RSTP, MSTP, VSTP.

Парсер Хабра

JunOS предоставляет нам большой выбор routing instance, доступных для конфигурирования:

VRF (Virtual routing and forwarding).

Примечание: в случае, когда необходимо запустить в данном VRF протокол ISIS, то нужно сконфигурировать дополнительный unit логического интерфейса Lo с указанием NET адреса, а так же прикрепить данный логический интерфейс к VRF:
Примечание: в конфигурации есть команда vrf-table-label. По умолчанию JunOS использует per-next-hop label allocation для маршрутов клиентов. Указанная выше команда переводит режим распределения меток в per-vrf, то есть все маршруты данной vrf будут иметь одну и ту же метку. (Если кому то будет интересно, напишу статью об этом.)

Переходим к следующему типу routing instance — Forwarding.

Virtual router.

Функционал routing instance virtual router сходен с vrf-lite из мира Cisco. Данная routing instance позволяет запускать любые протоколы маршрутизации от rip до bgp, а так же LDP (однако RSVP не поддерживается). Основной задачей данной routing instance является изоляция интерфейса (интерфейсов) клиента и его таблицы маршрутизации. Ближайшим родственником virtual-router можно назвать routing instance no-forwarding (будет описан ниже), их функционал несколько схож. Но, рассматриваемый нами тип routing instance устанавливает маршруты в отдельную таблицу маршрутизации, которая имеет наименование instance_name.inet.0 (instance_name.inet6.0):

Следующий тип routing instance – No-forwarding.

Разберем как работает данная routing instance. Мы имеем несколько сконфигурированных routing instance:

Из вывода следует, что у нас три сконфигурированных и одна default routing instance ( private routing instance мы не рассматриваем):

Созданы только forwarding-table для:
1.virtual-router.inet.0
2.forward.inet.0
3.default.inet.0

Для полноты картины рассмотрим такую схему (взял с сайта Juniper):

Самым известным представителем данной routing-instance является isis routing-instance. Все маршруты протокол isis инсталирует в inet.0, а не в iso.0.

VPLS.

Ниже представлена таблица маршрутизации одного из клиентов (BGP signaling):
10.0.1.1:100:1:1/96 — этот префикс обозначает сайт клиента и состоит из:
1. 10.0.1.1:100 — RD
2. 1 — site-id
3. 1 — label block offcet (сдвиг блока меток, если кому интересно, могу написать отдельную статью об операциях с метками при организации VPLS)

Если мы реализуем VPLS согласно драфту Компелла (BGP signaling), то конфигурация будет выглядеть вот так:

Если мы используем LDP-сигнализацию (Мартини), то конфигурация будет немного проще:

Проверить состояние соединений, которые данная routing instance установила можно командой show vpls connections:
С точки зрения клиента данная технология будет иметь вид коммутатора, к которому подключены сайты клиента.

Layer 2 VPN

Таблица маршрутизации выглядит практически так же как и VPLS:

Layer2-control

Virtual switch

Subnets.ru blog

Juniper и несколько routing-instances или как создать вторую роутинг таблицу для BGP (VRF)

Задача

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

Иными словами нужно что бы эти три пира «жили» в своей таблице маршрутизации и не имели отношения к основной таблице маршрутизации.
Каждая таблица будет «жить» по своим законам и трафик будет ходить по своим маршрутам.

Имеем

Juniper M10i
JUNOS 10.1R1.8

Решение

Решить эту задачу нам поможет routing-instances.

Благодаря им мы можем создать несколько таблиц маршрутизации и явным образом указать для каких интерфейсов роутера её использовать.

Первый возникающий вопрос это какого типа routing-instances нам нужен ? Смотрим описание:

forwarding

To configure a routing instance type, include the instance-type statement:

Если вы общались с железом от Cisco, то первое что вам бросится в глаза, так это знакомое слово VRF (либо вы уже слышали/настраивали VRF-lite).

В моем случае мне походит тип virtual-router, т.к. VPN`а у меня нет, а все что мне нужно это создать вторую, отдельную от основной, таблицу маршрутизации, которая будет действовать только в пределах данного роутера.

Приступим

Исходные данные для нашего VRF:
VRF апстрим #1:

подключен к физическому интерфейсу: ge-0/0/1.0
ASN: 100
IP-адрес: 1.1.1.1/30

подключен к физическому интерфейсу: ge-0/0/2.0
ASN: 200
IP-адрес: 2.2.2.1/30

подключен к физическому интерфейсу: ge-0/1/0.0
ASN: 300
IP-адрес: 3.3.3.2/30

Назовем наш VRF именем test, а наш номер AS будет 400.

Обращаю ваше внимание так это на то, что конфигурацию протокола BGP у основного роутера мы не трогаем, т.е. никаких изменений туда вносить не надо.
Подмечу, что конфигурацию самих физических интерфейсов и policy-statement (роут мапов) для пиров в нашем VRF нужно производить в режиме конфигурирования основного роутера, а не в routing-instances test.

Заходим в режим конфигурирования:

Затем перейдем в уровень routing-instances:

root@juniper# edit routing-instances

После чего нам нужно задать имя нашего routing-instance (допустим test) и задать в нем остальные настройки, в том числе настройки протокола BGP.

[edit routing-instances]
root@juniper# set test description «test routing table»

Зададим тип routing-instance:

[edit routing-instances]
root@juniper# set test instance-type virtual-router

Затем укажем какие интерфейсы роутера помещать в данный instance (в моем случае это будет три интерфейса, т.к. три пира и каждый в своем интерфейсе, это могут быть как целиком физические интерфейсы, так и вланы):

[edit routing-instances]
root@juniper# set test interface ge-0/0/1.0
root@juniper# set test interface ge-0/0/2.0
root@juniper# set test interface ge-0/1/0.0

Дальнейшая настройка routing-instance ничем не отличается от настройки основного роутера. Те же секции, те же команды. Не буду далее описывать каждую команду и покажу что мы должны получить на выходе по нашему routing-instance test:
[edit]
root@juniper# show routing-instances test

Собственно на этом конфигурация VRF и закончена. Как видно из конфига мы настроили BGP протокол внутри VRF`а где апстримов поместили в группу upstreams, а нашего клиента в группу customers.

Теперь остается настроить сами физические интерфейсы и создать полиси-мапы (vrf-upstream-1-in, vrf-customer, vrf-upstream-2-in, vrf-customer, vrf-client-in, vrf-client-out).

Напоминаю, что это делается в режиме «глобального» конфигурирования роутера, а не в routing-instance test.

Что мы должны увидеть после коммита данного конфига ?

[edit]
root@juniper# run show bgp summary

мы увидим что появилась ещё одна роутинг таблица, в которой перечислены наши VRF пиры.

Так же можно посмотреть что там с маршрутами в нашей routing-instance test:

[edit]
root@juniper# run show route table test.inet.0

Несколько заметок, например запустив пинг до нашего VRF клиента командой:

[edit]
root@juniper# run ping 3.3.3.2

не удивляйтесь что пинга нет, даже при наличии линка на физическом интерфейсе и не торопитесь с выводами, что физика не работает или с той стороны не настроен IP-адрес, просто вы забыли о том, что вы выполняете эту команду из основного роутера, а ведь физический интерфейс в сторону VRF-клиента принадлежит routing-instance test и основной роутер действительно не знает маршрут в эту подсеть.

Меняем команду на:

[edit]
root@juniper# run ping 3.3.3.2 routing-instance test
и вот он наш пинг:

т.е. мы явно сказали роутеру какой instance использовать для отправки пакетов до хоста 3.3.3.2.

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Пожалуйста, уважайте чужой труд.