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-instances {
routing-instance-name {
interface interface-name;
instance-type (forwarding | l2vpn | layer2-control | no-forwarding | virtual-router | virtual-switch | vpls | vrf);
}
}
На момент написания статьи доступны для конфигурирования следующие типы 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 выглядит следующим образом:
root@PE2# show routing-instances
6pe-2 {
instance-type vrf;
interface ge-0/0/3.101;
route-distinguisher 2001:31133;
vrf-target target:200:31133;
vrf-table-label;
routing-options {
router-id 101.101.101.101;
}
protocols {
ospf3 {
export isis-ce2-export;
area 0.0.0.0 {
interface ge-0/0/3.101;
}
}
}
}Функционал данной 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:
vrf1.inet.0: 12 destinations, 22 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/30 *[OSPF/10] 01:59:31, metric 2
> to 10.0.1.1 via ge-0/0/0.0
10.1.1.1/32 *[OSPF/10] 01:59:31, metric 2
> to 10.0.1.1 via ge-0/0/0.0
10.2.2.2/32 *[OSPF/10] 01:59:31, metric 2
> to 10.0.1.1 via ge-0/0/0.0
В таблице маршрутизации клиента есть только маршруты к другим сайтам данного клиента и его внутренние маршруты. То есть для клиента сеть провайдера прозрачна и имеет вид маршрутизатора, к которому подключены все его сайты.
Помимо таблицы маршрутизации клиента, на маршрутизаторе будет создана еще одна таблица маршрутизации bgp.l3vpn.0, в которую устанавливаются все маршруты, полученные маршрутизатором по протоколу bgp (address family inet-vpn unicast), согласно сконфигурированным значениям RT import:
bgp.l3vpn.0: 12 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
100:100:10.0.0.0/16
* 10.2.2.2 0 100 ?
100:100:10.0.1.1/32
* 10.2.2.2 0 100 ?
200:100:10.0.0.0/16
* 10.3.3.3 0 100 ?
Примечание: в случае, когда необходимо запустить в данном VRF протокол ISIS, то нужно сконфигурировать дополнительный unit логического интерфейса Lo с указанием NET адреса, а так же прикрепить данный логический интерфейс к VRF:
ce2-l3vpn {
instance-type vrf;
interface ge-0/0/2.0;
interface lo0.1; #в VRF добавлен unit 1 интерфейса Lo0
route-distinguisher 10.0.1.0:31133;
vrf-target target:10:31133;
protocols {
isis {
export isis-ce2-export;
interface ge-0/0/2.0;
interface lo0.1;
}
}
}
Примечание: в конфигурации есть команда 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:
[edit routing-instances]
root# show
forward {
instance-type forwarding;
routing-options {
static {
route 10.0.0.0/24 next-hop 10.0.1.1;
}
}
}
Все просто — ни каких 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, а так же LDP (однако RSVP не поддерживается). Основной задачей данной routing instance является изоляция интерфейса (интерфейсов) клиента и его таблицы маршрутизации. Ближайшим родственником virtual-router можно назвать routing instance no-forwarding (будет описан ниже), их функционал несколько схож. Но, рассматриваемый нами тип routing instance устанавливает маршруты в отдельную таблицу маршрутизации, которая имеет наименование instance_name.inet.0 (instance_name.inet6.0):
r6.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
60.0.0.0/30 *[Direct/0] 00:11:18
> via ge-0/0/2.0
60.0.0.1/32 *[Local/0] 00:11:18
Local via ge-0/0/2.0
60.1.1.1/32 *[OSPF/10] 00:11:04, metric 2
> to 60.0.0.2 via ge-0/0/2.0
224.0.0.5/32 *[OSPF/10] 00:11:19, metric 1
MultiRecvКлиенту отдаются только маршруты, которые есть в данной routing-instance. С помощью rib groups можно произвести перераспределение маршрутов из основной таблицы маршрутизации в таблицу маршрутизации клиента или перераспределить маршруты между virtual routers, которые «живут» на маршрутизаторе.
Данный тип routing instance используется довольно таки часто. Если его сравнивать с VRF, то данная routing instance избавлена от необходимости конфигурирования RT и RD. Пример конфигурации данной routing-instance представлен ниже:
r6 {
instance-type virtual-router;
interface ge-0/0/2.0;
}
protocols {
ospf {
export export-200;
area 0.0.0.0 {
interface all;
}
}
}
Следующий тип routing instance – No-forwarding.
Данный тип routing instance, в отличии от трех предыдущих, хоть и создает свою таблицу маршрутизации, но все маршруты инсталирует в основную default forwarding table.
Отличие fib от rib состоит в том, что в rib попадают все маршруты например протокола ospf (например к одному и тому же префиксу есть два маршрута — оба и будут отображены в rib), но только лучший из этих маршрутов попадет в fib и будет использоваться для передачи трафика (исключения, например ECMP). Так же rib предназначена для хранения и обмена маршрутной информацией между пирами в сети и для пересылки трафика она не удобна. Fib же как раз и предназначена для быстрого поиска необходимых для пересылки трафика данных и дает возможность реализовать аппаратную обработку трафика.
Данную routing instance применяют когда необходимо произвести сегментацию сети на третьем уровне (подобно VLAN). Конфигурация представлена ниже:
[edit routing-instances]
root# show
noforward {
instance-type no-forwarding;
interface ge-0/0/3.0;
routing-options {
auto-export;
}
protocols {
ospf {
export export-100;
area 0.0.0.0 {
interface ge-0/0/3.0;
}
}
}
}
Примечание: auto-export обязательно должно быть сконфигурировано в основной routing instance и routing instance no-forwarding, иначе ожидаемого результата вы не получите.
Разберем как работает данная routing instance. Мы имеем несколько сконфигурированных routing instance:
root> show route instance summary
Instance Type
Primary RIB Active/holddown/hidden
master forwarding
inet.0 19/0/0
__juniper_private1__ forwarding
__juniper_private1__.inet.0 7/0/0
__juniper_private2__ forwarding
__juniper_private2__.inet.0 0/0/1
__master.anon__ forwarding
forward forwarding
forward.inet.0 7/0/0
no-frw non-forwarding
no-frw.inet.0 16/0/0
virtual-router virtual-router
virtual-router.inet.0 14/0/0
Из вывода следует, что у нас три сконфигурированных и одна 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 на маршрутизаторе:
root> show route forwarding-table | match table
Routing table: default.inet
Routing table: __master.anon__.inet
Routing table: forward.inet
Routing table: virtual-router.inet
Routing table: default.iso
Routing table: __master.anon__.iso
Routing table: forward.iso
Routing table: virtual-router.iso
Routing table: default.inet6
Routing table: __master.anon__.inet6
Routing table: forward.inet6
Routing table: virtual-router.inet6
Routing table: default.mpls
Routing table: :mpls-oam.mpls
Routing table: default.ethernet-switching
Routing table: default.vmembers
Routing table: default.device-route
Routing table: default.MSTI
Routing table: default.dhcp-snooping
Созданы только 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.
Принцип работы технологии VPLS не входит в текст данной статьи, но будет частично затронут в ходе пояснений (иначе ничего не объяснить).
Нам нужно реализовать Virtual Private LAN Service, мы создаем данную routing instance. По сути повторяет функционально VRF (особенно при использовании BGP сигнализации), но предназначена для реализации L2 сервисов. Данный тип routing instance позволяет автоматически создавать полносвязную топологию из виртуальных l2 соединений между сайтам клиента. Эта routing instance, в связи с отсутствием необходимости запуска протоколов маршрутизации и распределения меток, их конфигурирование не поддерживает. Так как данная routing instance работает с l2 а не IP адресами, то forwarding table хранит mac адреса:
Routing table: vpls_bgp_signalig.vpls
VPLS:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 587 1
ge-0/0/3.0 user 0 comp 580 2
lsi.1048577 user 0 comp 581 2
ca:04:76:68:00:1c/48 dynm 0 ucst 577 3 ge-0/0/3.0
ca:05:79:f4:00:1c/48 dynm 0 indr 262142 5
10.0.0.2 Push 262146, Push 17(top) 572 2 ge-0/0/0.0
ca:08:5f:e4:00:1c/48 dynm 0 indr 262142 5
10.0.0.2 Push 262146, Push 17(top) 572 2 ge-0/0/0.0
Ниже представлена таблица маршрутизации одного из клиентов (BGP signaling):
customer1.site1.l2vpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.1.1:100:1:1/96
*[L2VPN/170/-101] 04:00:26, metric2 1
Indirect
10.0.1.2:100:2:1/96
*[BGP/170] 00:04:23, localpref 100, from 1.1.1.254
AS path: I
> to 20.0.0.2 via ge-0/0/1.0
10.0.1.3:100:3:1/96
*[BGP/170] 00:04:54, localpref 100, from 1.1.1.254
AS path: I
> to 20.0.2.2 via ge-0/0/0.0, Push 299808
to 20.0.1.2 via ge-0/0/2.0, Push 299808
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 как сигнализацию):
bgp.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
30.0.1.1:100:102:97/96
*[BGP/170] 00:04:55, localpref 100, from 1.1.1.254
AS path: I
> to 20.0.2.2 via ge-0/0/0.0, Push 299808
to 20.0.1.2 via ge-0/0/2.0, Push 299808
10.0.1.2:100:2:1/96
*[BGP/170] 00:04:23, localpref 100, from 1.1.1.254
AS path: I
> to 20.0.0.2 via ge-0/0/1.0
Конфигурация данной routing instance зависит от того, какая сигнализация используется для организации VPLS – BGP (драфт Компелла) или LDP (Мартини). В зависимости от вашего выбора конфигурация будет меняться.
Если мы реализуем VPLS согласно драфту Компелла (BGP signaling), то конфигурация будет выглядеть вот так:
routing-instances {
customer1.site1 {
instance-type vpls;
interface ge-0/0/3.0;
route-distinguisher 10.0.1.1:100;
vrf-target target:10.0.1.0:100;
protocols {
vpls {
no-tunnel-services;
site site1 {
site-range 10;
site-identifier 1;
interface ge-0/0/3.0;
}
}
}
} Так как драфт Компелла включает autodiscovery PE маршрутизаторов, то в конфигурации необходимо помимо интерфейса, указать RT и RD. Как я показал раннее, RD используется для поиска и идентификации PE маршрутизаторов, к которым подключены сайты клиента. На уровне иерархии [edit routing-instance protocols vpls] необходимо указать название сайта, его site-identifier (это JunOS может задавать автоматически, если это указать в конфигурации) и максимальное количество сайтов (site-range) клиента, причем site-identifier должен быть меньше, чем site-range.
Если мы используем LDP-сигнализацию (Мартини), то конфигурация будет немного проще:
ce3-vpls-ldp {
instance-type vpls;
interface ge-0/0/3.0;
protocols {
vpls {
no-tunnel-services;
vpls-id 101;
neighbor 1.1.1.1;
neighbor 2.2.2.2;
}
}
}Данная технология 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:
vpls100 {
instance-type vpls;
interface ge-1/1/0.100;
l2vpn-id l2vpn-id:100:200;
vrf-target target:100:208;
protocols {
vpls {
no-tunnel-services;
}
}
}
Проверить состояние соединений, которые данная routing instance установила можно командой show vpls connections:
[edit]
root# run show vpls connections
Layer-2 VPN connections:
Legend for connection status (St)
EI -- encapsulation invalid NC -- interface encapsulation not CCC/TCC/VPLS
EM -- encapsulation mismatch WE -- interface and instance encaps not same
VC-Dn -- Virtual circuit down NP -- interface hardware not present
CM -- control-word mismatch -> -- only outbound connection is up
CN -- circuit not provisioned <- -- only inbound connection is up
OR -- out of range Up -- operational
OL -- no outgoing label Dn -- down
LD -- local site signaled down CF -- call admission control failure
RD -- remote site signaled down SC -- local and remote site ID collision
LN -- local site not designated LM -- local site ID not minimum designated
RN -- remote site not designated RM -- remote site ID not minimum designated
XX -- unknown connection status IL -- no incoming label
MM -- MTU mismatch MI -- Mesh-Group ID not available
BK -- Backup connection ST -- Standby connection
PF -- Profile parse failure PB -- Profile busy
RS -- remote site standby SN -- Static Neighbor
VM -- VLAN ID mismatch
Legend for interface status
Up -- operational
Dn -- down
Instance: customer1.site1
Local site: site1 (1)
connection-site Type St Time last up # Up trans
2 rmt Up Nov 2 00:25:33 2015 1
Remote PE: 1.1.1.2, Negotiated control-word: No
Incoming label: 262154, Outgoing label: 262153
Local interface: lsi.1049099, Status: Up, Encapsulation: VPLS
Description: Intf - vpls customer1.site1 local site 1 remote site 2
3 rmt Up Nov 2 00:25:01 2015 1
Remote PE: 1.1.1.3, Negotiated control-word: No
Incoming label: 262155, Outgoing label: 262153
Local interface: lsi.1049098, Status: Up, Encapsulation: VPLS
Description: Intf - vpls customer1.site1 local site 1 remote site 3
С точки зрения клиента данная технология будет иметь вид коммутатора, к которому подключены сайты клиента.
Layer 2 VPN
В Junos есть (во всяком случае я знаю) три способа создать l2vpn (в отличии от VPLS, l2vpn имеет топологию p2p). Данная routing-instance близка по конфигурации и сигнализации к VPLS BGP signaling. Конфигурация предусматривает указание rd и rt для поиска PE-маршрутизаторов и последующего установления p2p соединения:
root# show
instance-type l2vpn;
interface ge-0/0/3.0;
route-distinguisher 100:100;
vrf-target target:1:1;
protocols {
l2vpn {
encapsulation-type ethernet-vlan;
no-control-word;
site site2 {
site-identifier 2;
interface ge-0/0/3.0 {
remote-site-id 1;
}
}
}
}
Как и ее старший брат routing-instance vpls, данная routing-instance, в силу своего назначения, не подразумевает настройки протоколов маршрутизации.
Плюсом данной routing-instance является простота настройки и, в отличии от других типов l2vpn, обладает лучшей масштабируемостью (при необходимости легко добавляются другие сайты). В отличии от VPLS, routing-instance l2vpn не поддерживает кроссплатформенное взаимодействие (например между Juniper и Cisco).
Данная routing-instance не дает возможности создать VPLS, хотя дает возможность сконфигурировать более одного виртуального L2 соединения (но это не будет полноценным VPLS).
Таблица маршрутизации выглядит практически так же как и VPLS:
root@PE1> show route table vpn.l2vpn.0
vpn1.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
100:100:1:1/96
*[BGP/170] 00:14:00, localpref 100, from 10.1.1.1
AS path: I
> to 10.0.0.2 via ge-0/0/3.0, label-switched-path pe1_to_pe2
200:200:1:2/96
*[L2VPN/170/-101] 00:17:35, metric2 1
IndirectПроверить состояния соединений можно с помощью команды 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:
[edit]
routing-instances {
routing-instance-name (
instance-type virtual-switch;
bridge-domains {
bridge-domain-name {
domain-type bridge;
interface interface-name;
vlan-id (all | none | number);
vlan-id-list [ vlan-id-numbers ];
vlan-tags outer number inner number;
}
}
protocols {
mstp {
...mstp-configuration ...
}
}
}
}Данная routing-instance позволяет реализовать на маршрутизаторе функционал коммутатора и производит изолирование интерфейсов и одного или более VLAN. То есть virtual switch позволяет производить сегментацию сетей на втором уровне, не прибегая к сегментированию сети на третьем уровне (что сохранит нам IP адреса). Для каждого сегмента можно запустить свой протокол из семейства STP. Маршрутизаторы серии MX поддерживают протоколы: STP, RSTP, MSTP, VSTP.
Спасибо за внимание!
Автор: Bormoglotx
