Подводные камни Inter-AS Option C на JunOS

в 4:00, , рубрики: juniper option C, Сетевые технологии
image alt

Данная статья написана так сказать по заявкам слушателей нашей радиостанции. При настройке 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.

Давайте воспроизведем проблему в эмуляторе и докопаемся да ее сути. Возьмем такую сетку:

Подводные камни Inter-AS Option C на JunOS - 2

Метки, полученные по eBGP-LU из соседней автономной системы внутри нашей локалной автономки будем распространять с помощью iBGP-LU (как я написал ранее можно использовать и редистрибуцию, но этот подход мне не нравится, к тому же имеет свой подводный камень, о котором я напишу далее):

Подводные камни Inter-AS Option C на JunOS - 3

Конфигурация стыков одинакова, и для 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. Суть всего описанного выше показана на рисунке ниже:

Подводные камни Inter-AS Option C на JunOS - 4

Но почему же тогда пинг до удаленной PE проходит? Все просто — когда PE маршрутизатор отправляет icmp запрос, он не навешиваем vpnv4 метку — пакет идет со стеком из двух меток (ну либо одной, если вы используете редистрибуцию). Трафик все так же приходит на ASBR удаленной автономной системы (в нашем случае на TULA-ASBR1), с него, как мы уже выяснили, снимается метка и уже голый ip трафик идет через P маршрутизатор, который находится в одном IGP домене с хостом назначения и знает маршрут до него (хотя TULA-P1 и не знает обратного маршрута, но это не мешает ему форвардить трафик). То есть это работает вот так:

Подводные камни Inter-AS Option C на JunOS - 5

Путей решения данной проблемы несколько. Начем с опций трафик-инжиниринга протокола 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:

Подводные камни Inter-AS Option C на JunOS - 6

то вам надо будет сделать 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

Источник

Поделиться

* - обязательные к заполнению поля