Данная статья написана так сказать по заявкам слушателей нашей радиостанции. При настройке Option C на JunOS у многих возникает один и тот же вопрос: почему ничего не работает хотя все вроде бы правильно? На JunOS все не так тривиально, как на Cisco и проблем может быть несколько. Перейдем непосредственно к сути: симптомы такие — вы настроили на ASBR BGP-LU сессию для организации Opt.C стыка на оборудовании Juniper (и естественно VPNv4 сессию между рефлекторами, но она тут не причем), но пинги между лупбеками PE маршрутизаторов различных автономных систем есть, а вот L3VPN не работает. Давайте разбираться, почему это происходит и как с этим бороться.
Opt.C в отличии от opt.B или opt.A это не только сессия между ASBR разных автономных систем, а комплексное решение, в которое входит BGP-LU сессия между ASBR, предназначенная для передачи маршрутов с метками до лупбеков между автономными системами, а так же VPNv4 сессия, как правило, между рефлекторами разных автономных систем, предназначенная для передачи VPNv4 префиксов. Внутри вашей автономной системы метод распределения маршрутов с метками до удаленных лупбеков выбираете вы сами — это может быть BGP-LU сессия на прямую с ASBR или через RR, либо редистрибуция BGP-LU маршрутов в IGP на ASBR. Каждый подход имеет свои плюсы и минусы, почитать об этом можете в моей предыдущей статье, описывающей принцип работы opt.C. Выбор варианта только за вами, но лично мне нравится когда все работает исключительно через BGP, однако я эксплуатирую сеть в которой есть как сегменты где происходит редистрибуция, так и сегменты, где используется исключительно BGP.
Давайте воспроизведем проблему в эмуляторе и докопаемся да ее сути. Возьмем такую сетку:
Метки, полученные по eBGP-LU из соседней автономной системы внутри нашей локалной автономки будем распространять с помощью iBGP-LU (как я написал ранее можно использовать и редистрибуцию, но этот подход мне не нравится, к тому же имеет свой подводный камень, о котором я напишу далее):
Конфигурация стыков одинакова, и для RZN-ASBR1 выглядит так:
bormoglotx@RZN-ASBR1# show protocols bgp
group PE {
type internal;
family inet {
labeled-unicast;
}
export NHS;
neighbor 62.0.0.1 {
local-address 62.0.0.3;
}
}
group ASBR {
type external;
family inet {
labeled-unicast;
}
export LO-export;
neighbor 30.0.0.1 {
local-address 30.0.0.0;
peer-as 71;
}
}
[edit]
bormoglotx@RZN-ASBR1# show policy-options policy-statement NHS
then {
next-hop self;
accept;
}
[edit]
bormoglotx@RZN-ASBR1# show policy-options policy-statement LO-export
term Lo {
from {
protocol ospf;
route-filter 62.0.0.0/24 prefix-length-range /32-/32;
}
then accept;
}
term Lo-local {
from {
protocol direct;
route-filter 62.0.0.0/24 prefix-length-range /32-/32;
}
then accept;
}
then reject;Для TULA-ASBR1 будет все тоже самое с поправкой на адресацию. Первая политика навешивается в сторону локальных PE маршрутизаторов и просто меняет next-hop на себя. Вторая политика навешивается в сторону удаленного ASBR и предназначена для экспорта только маршрутов до лупбеков в соседнюю автономную систему.
Примечание: в политике два терма — первый экспортирует лупбеки, которые имеются в igp, второй экспортирует собственный лупбек ASBR, так как он установлен в rib протоколом direct, а не igp. Это можно сделать и одним термом, но мне так удобнее.
Проверим состояние BGP-LU сессии между RZN-ASBR1 и TULA-ASBR1:
bormoglotx@RZN-ASBR1> show bgp neighbor 30.0.0.1
Peer: 30.0.0.1+179 AS 71 Local: 30.0.0.0+56580 AS 62
Type: External State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ LO-export ]
Options: <Preference LocalAddress AddressFamily PeerAS Refresh>
Address families configured: inet-labeled-unicast
Local Address: 30.0.0.0 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 71.0.0.3 Local ID: 62.0.0.3 Active Holdtime: 90
Keepalive Interval: 30 Group index: 1 Peer index: 0
BFD: disabled, down
Local Interface: ge-0/0/0.0
NLRI for restart configured on peer: inet-labeled-unicast
NLRI advertised by peer: inet-labeled-unicast
NLRI for this session: inet-labeled-unicast
Peer supports Refresh capability (2)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
NLRI that restart is negotiated for: inet-labeled-unicast
NLRI of received end-of-rib markers: inet-labeled-unicast
NLRI of all end-of-rib markers sent: inet-labeled-unicast
Peer supports 4 byte AS extension (peer-as 71)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 3
Received prefixes: 3
Accepted prefixes: 3
Suppressed due to damping: 0
Advertised prefixes: 3
Last traffic (seconds): Received 3 Sent 27 Checked 26
Input messages: Total 1731 Updates 7 Refreshes 0 Octets 33145
Output messages: Total 1728 Updates 3 Refreshes 0 Octets 33030
Output Queue[0]: 0
Все отлично, мы отдаем 3 маршрута и столько же и принимаем. В моем случае между ASBR и PE настроена прямая iBGP-LU сессия, в которой передаются лупбеки (схема маленькая и поэтому рефлектора нет).
Идем далее. Проверим, что именно анонсирует RZN-ASBR1 в соседнюю автономку:
bormoglotx@RZN-ASBR1> show route advertising-protocol bgp 30.0.0.1
inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 62.0.0.1/32 Self 2 I
* 62.0.0.2/32 Self 1 I
* 62.0.0.3/32 Self IНикаких сюрпризов — отдаем только лупбеки. Теперь между PE маршрутизаторами должна подняться vpnv4 сессия. Проверим:
bormoglotx@RZN-PE1> show bgp summary group eBGP-VPNV4
Groups: 2 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
10 3 0 0 0 0
bgp.l3vpn.0
1 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
71.0.0.1 71 6 6 0 0 1:02 Establ
bgp.l3vpn.0: 0/1/1/0
TEST1.inet.0: 0/1/1/0Отлично, сессия в апе и мы видим что получаем один маршрут. Но маршрута в таблице маршрутизации не будет, так как его next-hop в состоянии unusable:
bormoglotx@RZN-PE1> show route table bgp.l3vpn.0 hidden
bgp.l3vpn.0: 3 destinations, 3 routes (2 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
1:1:10.0.1.0/24
[BGP/170] 00:02:14, localpref 100, from 71.0.0.1
AS path: 71 I, validation-state: unverified
UnusableВ этом состоянии он потому, что маршрута до лупбека нет в таблице inet.3, в которой bgp резолвит next-hop. Для этого включим на bgp-lu сессии resolve-vpn, чтобы маршруты устанавливались и в inet.0 и в inet.3 (по умолчанию маршруты BGP-LU попадают в таблицу inet.0):
bormoglotx@RZN-PE1> show route table bgp.l3vpn.0 hidden
bgp.l3vpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
bormoglotx@RZN-PE1> show route table bgp.l3vpn.0 10.0.1.0/24
bgp.l3vpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1:1:10.0.1.0/24
*[BGP/170] 00:05:10, localpref 100, from 71.0.0.1
AS path: 71 I, validation-state: unverified
> to 10.0.0.1 via ge-0/0/0.0, Push 16, Push 299968, Push 299792(top)Как видите, маршрут сразу пропал из hidden и установился в таблицу маршрутизации.
По идее все настроено, маршруты есть — трафик должен ходить:
bormoglotx@RZN-PE1> show route table TEST1.inet.0 10.0.1.1
TEST1.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.1.0/24 *[BGP/170] 00:02:54, localpref 100, from 71.0.0.1
AS path: 71 I, validation-state: unverified
> to 10.0.0.1 via ge-0/0/0.0, Push 16, Push 299968, Push 299792(top)
bormoglotx@RZN-PE1> ping routing-instance TEST1 source 10.0.0.1 10.0.1.1 rapid
PING 10.0.1.1 (10.0.1.1): 56 data bytes
.....
--- 10.0.1.1 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet lossНо фактически получаем эпичный фейл — у нас ничего не заработало. Причем связность между лупбеками PE маршрутизаторов есть:
bormoglotx@RZN-PE1> ping source 62.0.0.1 71.0.0.1 rapid
PING 71.0.0.1 (71.0.0.1): 56 data bytes
!!!!!
--- 71.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 9.564/13.021/16.509/2.846 msДавайте разбираться в чем дело. Для этого придется проверить, что промежуточные маршрутизаторы делают с метками.
Итак, RZN-PE1 пушит три метки: Push 16, Push 299968, Push 299792(top). Метка 299792 нужна, чтобы добраться до RZN-ASBR1, метка 299968- это метка, которую RZN-ASBR1 сгенерировал для префикса 71.0.0.1 (TULA-PE1) ну и метка 16 — это vpnv4 метка.
Верхней меткой в стеке является метка 299792, и именно с ней работает маршрутизатор RZN-P1, получая транзитный mpls пакет — следующую метку в стеке он не смотрит. Мы же проверим, что RZN-P1 должен сделать, получив пакет с указанной выше меткой:
bormoglotx@RZN-P1> show route table mpls.0 label 299792
mpls.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
299792 *[LDP/9] 13:37:43, metric 1
> to 10.0.1.0 via ge-0/0/1.0, Pop
299792(S=0) *[LDP/9] 13:37:43, metric 1
> to 10.0.1.0 via ge-0/0/1.0, PopВсе логично, так как RZN-P1 является предпоследним маршрутизатором в LSP до RZN-ASBR1, то он снимает верхнюю метку (PHP) и далее отправляет в сторону ASBR пакет с уже двумя метками. То есть на RZN-ASBR1 прилетает пакет с верхней меткой в стеке 299968:
bormoglotx@RZN-ASBR1> show route table mpls.0 label 299968
mpls.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
299968 *[VPN/170] 00:39:11
> to 30.0.0.1 via ge-0/0/0.0, Swap 300000Тут тоже никакого криминала — как и положено происходит своп данной метки и передача в сторону TULA-ASBR1.
Теперь перемещаемся в соседнюю автономную систему и посмотрим, что будет делает с полученным пакетом TULA-ASB1:
bormoglotx@TULA-ASBR1> show route table mpls.0 label 300000
mpls.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
300000 *[VPN/170] 00:40:48
> to 20.0.1.1 via ge-0/0/1.0, Pop
300000(S=0) *[VPN/170] 00:40:48
> to 20.0.1.1 via ge-0/0/1.0, Pop TULA-ASBR1 снимает верхнюю метку и отправляет трафик в сторону TULA-P1 пакет всего с одной меткой — меткой 16, которая является vpnv4 меткой. Вот это и есть наша проблема — TULA-P1 не знает о такой метке и просто дропает пакет (а если и знает метку 16, то это будет метка какого то другого сервиса и трафик будет дропнут, только чуть позже):
bormoglotx@TULA-P1> show route table mpls.0 label 16
bormoglotx@TULA-P1>Почему это происходит? Дело в том, какой маршрут берется за основу при генерировании меток через BGP-LU сессию. По умолчанию для labeled-unicast сессии используется таблица inet.0 — в нее устанавливаются полученные маршруты и из нее же маршруты отдаются. При этоум за основу при генерирвании маршрутов до лупбеков берутся IGP маршруты (так как именно они являются лучшими в inet.0), в нашем случае это маршруты ospf. Как известно, IGP маршруты не имеют MPLS меток, поэтому при отдаче маршрута через BGP-LU сессию маршрутизатор TULA-ASBR1 записал в таблицу маршрутизации, что метку надо снять и отправить пакет через какой то определенный интерфейс (в нашем случае дальше будет передан пакет с одной меткой — маршрутизатор не знает, что под верхней меткой будет еще одна — он туда не лезет). То есть у нас просто не сшиваются два LSP. Суть всего описанного выше показана на рисунке ниже:
Но почему же тогда пинг до удаленной PE проходит? Все просто — когда PE маршрутизатор отправляет icmp запрос, он не навешиваем vpnv4 метку — пакет идет со стеком из двух меток (ну либо одной, если вы используете редистрибуцию). Трафик все так же приходит на ASBR удаленной автономной системы (в нашем случае на TULA-ASBR1), с него, как мы уже выяснили, снимается метка и уже голый ip трафик идет через P маршрутизатор, который находится в одном IGP домене с хостом назначения и знает маршрут до него (хотя TULA-P1 и не знает обратного маршрута, но это не мешает ему форвардить трафик). То есть это работает вот так:
Путей решения данной проблемы несколько. Начем с опций трафик-инжиниринга протокола mpls. Это не тот трафик инжиниринг о котором вы подумали (думаю вам на ум пришло слово RSVP). Существует 4-ре опции трафик инжиниринга:
bormoglotx@RZN-ASBR1# set protocols mpls traffic-engineering ?
Possible completions:
bgp BGP destinations only
bgp-igp BGP and IGP destinations
bgp-igp-both-ribs BGP and IGP destinations with routes in both routing tables
mpls-forwarding Use MPLS routes for forwarding, not routingОпция bgp — это опция по умолчанию, она заставляет маршрутизатор инсталировать маршруты ldp и rsvp в таблицу inet.3 и поэтому только bgp имеет доступ к этим маршрутам (резолв next-hop-ов для VPNv4L2-signalingEVPN маршрутов). Но обращаю ваше внимание на то, что BGP-LU маршруты будут попадать в inet.0, а не в inet.3.
Опция bgp-igp — эта опция заставляет маршрутизатор инсталлировать rsvp и ldp маршруты в таблицу inet.0, причем в этом случае inet.3 станет пустой. Если у вас ASBR используется и как PE-ка для терминации L3VPN, то вы должны осознавать, что они перестанут работать без костылей. Еще одно побочный эффект — «ломается» роутинг.
Опция bgp-igp-both-ribs — эта опция заставляет маршрутизатор инсталировать ldp и rsvp маршруты и в таблицу inet.0 и в таблицу inet.3. Побочный эффект как и у прошлой опции — «ломается» роутинг, а вот L3VPN работать будут.
Опция mpls-forwarding — эта опция заставляет маршрутизатора копировать маршруты из inet.3 в inet.0, но эти маршруты будут доступны только для форвардинга. В таблице inet.3 изменений не будет. Побочный эффект — трафик, который ранее ходил по ip (например bgp сессии до удаленных лупбеков) теперь будут ходить по mpls (хотя наверно это больше плюс, чем минус — смотря с какой стороны посмотреть).
Эти опции надо использовать с осторожностью, особенно вторую и третью. Обе эти опции ломают роутинг — так как ldp и rsvp маршруты появляются в таблице inet.0, в которой обычно главный протокол igp — isis или ospf. Но теперь маршруты igp станут менее приоритетными в силу их больших protocol preference в сравнении с протоколами распределения меток. Сломают роутинг, это значит, что есть если до включения опции вы видели маршрут до какого лупбека через ospf/isis как луший, то теперь его место займет маршруты ldp/rsvp. Если вы в какой то экспортной политике задали к примеру условие from ospf, то теперь это условие выполняться не будет со всеми вытекающими… Вторая опция, как я указал выше, еще и опасна тем, что таблица inet.3 становится пустой. Имейте это ввиду. А вот опция mpls-forwarding как раз то, что нам надо. При ее включении маршруты из inet.3 будут просто скопированы в inet.0 но только для форвардинга — то есть теперь трафик будет ходить не чистым ip, а через mpls.
Важно понимать, что ни одна из этих опций не генерирует новые LSP — просто существующие LSP копируются (или переносятся) в inet.0. Применяя эти опции (имеется ввиду 2-я, 3-я и 4-я опция в списке), вы позволяете маршрутизатору использовать имеющиеся у него LSP не только для форвардинга трафика L2/3VPN, а так же обычного трафика (если между точками, которые хотят обмениваться этим трафиком, есть LSP — ну к примеру эти точки — лупбеки маршрутизаторов), который обычно ходит чистым IP.
Включим эту опцию и проверим, что получится. Как вы помните, раннее TUAL-ASBR1 анонсировал метку 300000 и делал pop label вместо swap. После включения этой опции метки будут перегенерированы:
bormoglotx@RZN-ASBR1> show route receive-protocol bgp 30.0.0.1 71.0.0.1/32 detail
inet.0: 14 destinations, 16 routes (14 active, 0 holddown, 0 hidden)
* 71.0.0.1/32 (1 entry, 1 announced)
Accepted
Route Label: 300080
Nexthop: 30.0.0.1
MED: 2
AS path: 71 IТеперь TULA-ASBR1 анонсирует нам метку 300080. Посмотрим, что будет делать маршрутизатор с транзитным пакетом с этой меткой:
bormoglotx@TULA-ASBR1> show route table mpls.0 label 300080
mpls.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
300080 *[VPN/170] 00:04:07
> to 20.0.1.1 via ge-0/0/1.0, Swap 299776Вот теперь все так, как надо — происходит swap метки — наши LSP теперь сшиваются. А вот что происходит с таблицей маршрутизации inet.0:
bormoglotx@TULA-ASBR1> show route table inet.0 71.0.0.0/24
inet.0: 14 destinations, 16 routes (14 active, 0 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both
71.0.0.1/32 @[OSPF/10] 00:05:50, metric 2
> to 20.0.1.1 via ge-0/0/1.0
#[LDP/9] 00:05:50, metric 1
> to 20.0.1.1 via ge-0/0/1.0, Push 299776
71.0.0.2/32 @[OSPF/10] 00:05:50, metric 1
> to 20.0.1.1 via ge-0/0/1.0
#[LDP/9] 00:05:50, metric 1
> to 20.0.1.1 via ge-0/0/1.0
71.0.0.3/32 *[Direct/0] 14:16:29
> via lo0.0В таблице появились новые маршруты. Теперь для форвардинга у нас используется LSP(маршрут LDPRSVP, помеченные #), а для роутинга все те же IGP маршруты (которые теперь помечается @). Хотелось бы заметить, что сейчас маршруты в сторону соседнего ASBR как и ранее генерируются из маршрутов ospf, которые не имеют меток. Но так как у нас теперь для форвардинга используется маршрут LDP, то маршрутизатор будет делать не pop label а swap.
Ну и проверим, что L3VPN завелся:
bormoglotx@RZN-PE1> ping routing-instance TEST1 source 10.0.0.1 10.0.1.1 rapid
PING 10.0.1.1 (10.0.1.1): 56 data bytes
!!!!!
--- 10.0.1.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 6.861/16.084/47.210/15.596 msВ случае, если вы будете делать редистрибуцию в igp на ASBR:
то вам надо будет сделать egress-policy на протокол ldp, чтобы ASBR стал генерировать метки для полученных префиксов и распределять их внутри сети. По умолчанию JunOS генерирует метку только для своего лупбека, а так же до маршрутов с метками, полученными по ldp, в отличии от той же Cisco, поэтому на оборудовании Cisco такой проблемы нет (но и без этого там хватает своих проблем).
На RZN-ASBR-1 я сделал экспорт маршрутов, полученных по bgp в ospf (bgp LU между PE и ASBR теперь нет):
bormoglotx@RZN-ASBR1> show route receive-protocol bgp 30.0.0.1
inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 71.0.0.1/32 30.0.0.1 2 71 I
* 71.0.0.2/32 30.0.0.1 1 71 I
* 71.0.0.3/32 30.0.0.1 71 IСогласно политике експорта, данные маршрты уходят в ospf:
bormoglotx@RZN-ASBR1> show configuration protocols ospf
export OSPF-EXPORT;
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface ge-0/0/1.0 {
interface-type p2p;
}
interface ge-0/0/0.0 {
passive;
}
}
bormoglotx@RZN-ASBR1> show configuration policy-options policy-statement OSPF-EXPORT
term Remote-Lo {
from {
route-filter 71.0.0.0/24 prefix-length-range /32-/32;
}
then accept;
}
then reject;Полученные из соседней автономной системы маршруты попадают в ospf database как external и далее распределяются внутри igp домена:
bormoglotx@RZN-ASBR1> show ospf database
OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 62.0.0.1 62.0.0.1 0x80000016 2576 0x22 0xf0fb 60
Router 62.0.0.2 62.0.0.2 0x80000017 2575 0x22 0xf57b 84
Router *62.0.0.3 62.0.0.3 0x8000001a 80 0x22 0xd2dd 72
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern *71.0.0.1 62.0.0.3 0x80000001 80 0x22 0x2afc 36
Extern *71.0.0.2 62.0.0.3 0x80000001 80 0x22 0x1611 36
Extern *71.0.0.3 62.0.0.3 0x80000001 80 0x22 0x225 36Проверим на RZN-PE1 наличие маршрута:
bormoglotx@RZN-PE1> show route 71.0.0.1/32
inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
71.0.0.1/32 *[OSPF/150] 00:02:10, metric 2, tag 0
> to 10.0.0.1 via ge-0/0/0.0Маршрут есть только в таблице inet.0, но для того, чтобы bgp интсталировал маршрут в таблицу bgp.l3vpn.0, необходимо наличие lsp до protocol next-hop в таблице inet.3. Сейчас таблица inet.3 не имеет маршрута к префиксу 71.0.0.1/32. Маршрута нет, так как ldp не генерирует метки для данных префиксов.
bormoglotx@RZN-ASBR1> show ldp database
Input label database, 62.0.0.3:0--62.0.0.2:0
Label Prefix
299776 62.0.0.1/32
3 62.0.0.2/32
299792 62.0.0.3/32
Output label database, 62.0.0.3:0--62.0.0.2:0
Label Prefix
300640 62.0.0.1/32
300656 62.0.0.2/32
3 62.0.0.3/32Чтобы появились lsp, необходимо на RZN-ASBR1 сделать egress-policy для ldp, в которой указать, что для префиксов из диапазона 71.0.0.0/24 надо генерировать метки:
bormoglotx@RZN-ASBR1> show configuration protocols ldp
egress-policy LDP-EXPORT;
interface ge-0/0/1.0;
bormoglotx@RZN-ASBR1> show configuration policy-options policy-statement LDP-EXPORT
term Local-Lo {
from {
route-filter 62.0.0.3/32 exact;
}
then accept;
}
term Remote-Lo {
from {
route-filter 71.0.0.0/24 prefix-length-range /32-/32;
}
then accept;
}Будьте осторожны с egress-policy для LDP, так как чаще всего при его конфигурировании в первый раз инженер получает пустую inet.3. Те префиксы, которые вы укажите в политике будут анонсировать через LDP, но тогда маршрутизатор станет считать, что он является сорсом для всех этих FEC и просто не будет их инсталлировать в inet.3 (так как локальные FEC в inet.3 не устанавливаются — дефолтный локальный FEC на JunOS это его собственный лупбек и ldp не зачем строить lsp к самому себе). В указанной выше политике я в первом терме отдаю свой собственный лубпек, во втором терме лупбеки соседней автономки, полученные по bgp. Если вы хотите на ASBR инсталлировать маршруты из другой автономки в inet.3. то на сессию в сторону соседней автономной системы надо добавить опцию resolve-vpn:
bormoglotx@RZN-ASBR1> show configuration protocols bgp group ASBR
type external;
family inet {
labeled-unicast {
resolve-vpn;
}
}
export LO-export;
neighbor 30.0.0.1 {
local-address 30.0.0.0;
peer-as 71;
}Теперь метки будут генерироваться и для префиксов из диапазона 71.0.0.0/24:
bormoglotx@RZN-ASBR1> show ldp database
Input label database, 62.0.0.3:0--62.0.0.2:0
Label Prefix
299776 62.0.0.1/32
3 62.0.0.2/32
299792 62.0.0.3/32
299952 71.0.0.1/32
299968 71.0.0.2/32
299984 71.0.0.3/32
Output label database, 62.0.0.3:0--62.0.0.2:0
Label Prefix
3 62.0.0.1/32
3 62.0.0.2/32
3 62.0.0.3/32
300704 71.0.0.1/32
300720 71.0.0.2/32
300736 71.0.0.3/32После данных манипуляция на RZN-PE1 в inet.3 должны появился маршрут до лупебков соседней автономной системы и, как следствие должна появиться связность внутри L3VPN:
bormoglotx@RZN-PE1> show route 71.0.0.1/32
inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
71.0.0.1/32 *[OSPF/150] 00:09:17, metric 2, tag 0
> to 10.0.0.1 via ge-0/0/0.0
inet.3: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
71.0.0.1/32 *[LDP/9] 00:02:14, metric 1
> to 10.0.0.1 via ge-0/0/0.0, Push 299952
bormoglotx@RZN-PE1> ping routing-instance TEST1 source 10.0.0.1 10.0.1.1 rapid
PING 10.0.1.1 (10.0.1.1): 56 data bytes
!!!!!
--- 10.0.1.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 7.054/11.118/21.571/5.493 msЭто мы рассмотрели первый вариант решения проблемы. Теперь перейдем ко второму.
Как я ранее сказал, по умолчанию labeled-unicat маршруты инсталлируются и отдаются из таблицы inet.0, в которой, так же по умолчанию, нет маршрутов с метками. Мы можем заставить маршрутизатор отдавать и принимать маршруты из таблицы inet.3. Делается это так:
bormoglotx@RZN-ASBR1# show protocols bgp group ASBR
type external;
family inet {
labeled-unicast {
rib {
inet.3;
}
}
}
export LO-export;
neighbor 30.0.0.1 {
local-address 30.0.0.0;
peer-as 71;
}Примечание: на импорт в политике не должен быть указан протокол igp, так как ospf/isis маршрутов нет в таблице inet.3
Теперь посмотрим, что мы отдаем в соседнюю автономную систему:
bormoglotx@RZN-ASBR1> show route advertising-protocol bgp 30.0.0.1
inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 62.0.0.1/32 Self 1 I
* 62.0.0.2/32 Self 1 IТолько два маршрута, а раньше было три. Не отдается маршрут к самому себе (до лупбека RZN-ASBR1). Почему — легко понять, если поискать свой лубек в таблице inet.3:
bormoglotx@RZN-ASBR1> show route table inet.3 62.0.0.3/32
bormoglotx@RZN-ASBR1> Так как локальный FEC в inet.3 не устанавливается, то логично, что маршрута нет. Для того чтобы наш лупбек отдавался, нам необходимо скопировать его из таблицы inet.0 в таблицу inet.3. Для этого надо сделать rib-группу и навесить ее на interface-routes:
[edit]
bormoglotx@RZN-ASBR1# show | compare
[edit routing-options]
+ interface-routes {
+ rib-group inet inet.0>>>inet.3-Local-Lo;
+ }
bormoglotx@RZN-ASBR1> show configuration | compare rollback 4
[edit routing-options]
+ interface-routes {
+ rib-group inet inet.0>>>inet.3-Local-Lo;
+ }
+ rib-groups {
+ inet.0>>>inet.3-Local-Lo {
+ import-rib [ inet.0 inet.3 ];
+ import-policy Local-Lo;
+ }
+ }
[edit policy-options]
+ policy-statement Local-Lo {
+ term Lo {
+ from {
+ protocol direct;
+ route-filter 62.0.0.0/24 prefix-length-range /32-/32;
+ }
+ then accept;
+ }
+ then reject;
+ }Итак, эта строка:
import-rib [ inet.0 inet.3 ]говорит нам о том, что маршруты из таблицы inet.0 надо скопировать в таблицу inet.3. А вот эта строка
import-policy Local-Loприменяет к этому импорту политику, чтобы не копировать все маршруты. Ну и в конце концов эту rib-группу надо куда прикрутить. Так как мы копируем direct маршрут, то и прикручиваем к interface-routes.
После таких манипуляций маршрут до лупбека будет доступе в таблице inet.3 (но он будет как и в inet.0 установлен в таблицу не протоколом ldp/rsvp, а протоком direct):
[edit]
bormoglotx@RZN-ASBR1# run show route 62.0.0.3/32 table inet.3
inet.3: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
62.0.0.3/32 *[Direct/0] 00:00:07
> via lo0.0Можем проверить, отдаем ли мы теперь свой лупбек в соседнюю автономку:
bormoglotx@RZN-ASBR1> show route advertising-protocol bgp 30.0.0.1
inet.3: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 62.0.0.1/32 Self 1 I
* 62.0.0.2/32 Self 1 I
* 62.0.0.3/32 Self IОдну проблему решили. Но возникает вторая проблема:
bormoglotx@RZN-PE1> show route table TEST1.inet.0
TEST1.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 *[Direct/0] 01:38:46
> via ge-0/0/5.0
10.0.0.1/32 *[Local/0] 01:38:46
Local via ge-0/0/5.0Теперь маршрутов в L3VPN в соседнюю автономку нет, так как лежит bgp пиринг между PE маршрутизаторами:
bormoglotx@RZN-PE1> show bgp summary group eBGP-VPNV4
Groups: 2 Peers: 2 Down peers: 1
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
7 0 0 0 0 0
bgp.l3vpn.0
0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
71.0.0.1 71 179 183 0 1 18:34 ActiveДело в том, что маршруты на ASBR лежат в таблице inet.3, а label-unicast сессия с удаленными PE строится из inet.0, и естественно на PE-ки ничего не отдается. Для этого надо сделать еще одну rib-группу на ASBR и перенести маршруты из inet.3 в inet.0:
[edit]
bormoglotx@RZN-ASBR1# show routing-options rib-groups inet.3>>>inet.0-Remote-Lo
import-rib [ inet.3 inet.0 ];
import-policy Remote-Lo;
[edit]
bormoglotx@RZN-ASBR1# show policy-options policy-statement Remote-Lo
term Lo {
from {
route-filter 71.0.0.0/24 prefix-length-range /32-/32;
}
then accept;
}
then reject;И прикручиваем ее на нашу BGP сессию, в который мы получаем данные маршруты:
bormoglotx@RZN-ASBR1# show protocols bgp group ASBR
type external;
family inet {
labeled-unicast {
rib-group inet.3>>>inet.0-Remote-Lo;
rib {
inet.3;
}
}
}
export LO-export;
neighbor 30.0.0.1 {
local-address 30.0.0.0;
peer-as 71;
}Аналогичную конфигурацию надо сделать и на втором ASBR, если у вас и там редистрибуция в igp, после чего маршруты до удаленных лупбеков будут установлены в таблицу маршрутизации на PE-ках и eBGP vpnv4 сессия поднимутся (никто не запрещает в одной автономке делать редистрибуцию, а во второй использовать исключительно BGP — выбор только за администраторами сети):
bormoglotx@RZN-PE1> show bgp summary group eBGP-VPNV4
Groups: 2 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
10 3 0 0 0 0
bgp.l3vpn.0
1 1 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
71.0.0.1 71 184 189 0 1 1:11 Establ
bgp.l3vpn.0: 1/1/1/0
TEST1.inet.0: 1/1/1/0Теперь можно проверить связность внутри L3VPN:
bormoglotx@RZN-PE1> ping routing-instance TEST1 source 10.0.0.1 10.0.1.1 rapid
PING 10.0.1.1 (10.0.1.1): 56 data bytes
!!!!!
--- 10.0.1.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.332/37.029/83.503/29.868 msТеперь, думаю что вопросов с настройкой opt.C на JunOS станет меньше. Но если у кого то возникли вопросы — пишите в комментарии, ну или мне в телеграмм.
Спасибо за внимание.
Автор: Bormoglotx
