BGP Inter-AS

Сьогодні мова піде про міжоператорській взаємодії — BGP Inter-AS. У статті розглянемо наступні теми:
— BGP Inter-AS Option A
— BGP Inter-AS Option B
— BGP Inter-AS Option C
— Особливості налаштування даних опцій на JunOS
У даній статті буде багато висновків з CLI Cisco та Juniper. Якщо ви не знаєте основ mpls, різниці між bgp labeled-unicast і vpnv4 unicast, то читати дану статтю вам немає сенсу. Якщо ж ці поняття вам знайомі, то прошу прошу під кат.

Примітка: у наведених схемах ліва частина складається з маршрутизаторів під управління JunOS (крім CE), у правій частині Cisco IOS15.

Ну і почнемо з самого банального — Option A.
Сенс даної опції полягає в тому, що на ASBR-рах створюються VRF на кожен VPN і піднімаються окремі сабинтерфейсы з сусідньої AS. Таким чином ASBR-ри взаємодіють як CE-PE маршрутизатори, обмінюючись чистими IP маршрутами. В даній опції між ASBR-мі немає MPLS — тільки чистий IP трафік:

Розберемо детальніше як працює control plane:

1. PE1 генерує vpnv4 маршрут і віддає його за MP-BGP на роутрефлектор (RR1).

2. Роутрефлектор має vpnv4 сесію з ASBR1, в рамках якої віддає йому отриманий від PE1 vpnv4 маршрут.

3. Так як на ASBR1 теж створений VRF (в нашій топології на ASBR1 CE1 і CE3, а на ASBR2 — CE2 і CE4), то він приймає маршрут і инсталирует його в таблицю маршрутизації відповідної vrf.

4. ASBR1 передає на ASBR2 вже чистий IP марушрут (протокол маршрутизації може бути будь-яким, від RIP до BGP). Тут працює взаємодія по типу від CE до PE, де ASBR1 буде виконувати роль CE маршрутизатора, віддаючи IP префікс, а ASBR2 — PE маршрутизатора, отримуючи префікс і генеруючи vpnv4 префікс для своєї AS. (маршрути передаються з обох сторін, тому обидва ASBR виконують роль та CE і PE маршрутизатора).

5. ASBR2, отримавши IP префікс, генерує vpnv4 префікс і віддає його на свій роутрефлектор (RR2).

6. PE2 отримує від роутрефлектора за vpnv4 сесії даний префікс і инсталирует його в таблицю маршрутизації відповідного vrf, попередньо перевіривши досяжність next-hop і відповідність rt в маршруті сконфигурированному на маршрутизаторі vrf-import.

Тепер перейдемо до data plane:

1. PE1 отримує пакет від CE1, навішує на нього мітку (мітку vrf), отриману від ASBR1, транспортну мітку до ASBR1 (отриману за ldp) і надсилає у відповідний інтерфейс.

2. P1 отримавши пакет від PE1 зі стеком з 2-x міток виробляє зняття верхній транспортної мітки (php) і відправку пакета на ASBR1.

3. ASBR1 отримує пакет з однією міткою (міткою vrf), і діє як звичайний PE маршрутизатор, терминирующий клієнтський CE маршрутизатор — знімає позначку і відправляє пакет у відповідний інтерфейс, але так як роль CE маршрутизатора в даному сценарії виконує ASBR2, то чистий IP пакет відправляється в стик c ASBR2.

4. ASBR2 отримує даний пакет і працює як звичайний PE маршрутизатор – додає підпис vrf (отриману від PE2), транспортну мітку до PE2 (отриману за ldp) і надсилає у відповідний інтерфейс.

5. P2 виробляє зняття транспортної мітки (php).

6. PE2 отримує пакет з однією міткою (міткою vrf, яку сам і створив), знімає її, робить ip lookup і відправляє пакет згідно таблиці маршрутизації відповідного vrf.

Тепер подивимося на практиці які операції з мітками будуть проводитися.
Нижче представлені конфігурації BGP на ASBR-рах:
bormoglotx@ASBR1> show configuration routing-instances CE1
instance-type vrf;
interface ge-0/0/3.0;
route-distinguisher 1:2;
vrf-target {
import target:1:100;
export target:1:100;
}
vrf-table-label;
protocols {
bgp {
group AS64999 {
type external;
local address 10.2.0.1;
peer-as 64999;
local-as 65000;
neighbor 10.2.0.2;
}
}
}

ASBR2#sh configuration | b ip vrf
ip vrf CE2
rd 2:2
route-target export 2:100
route-target import 2:100

ASBR2#sh configuration | b address-family ipv4
address-family ipv4 vrf CE2
no synchronization
neighbor 10.2.0.1 remote-as 65000
neighbor 10.2.0.1 local-as 64999
neighbor 10.2.0.1 activate
exit-address-family

Все, як бачите, як у звичайного PE маршрутизатора, нічого кримінального.

Примітка: є кілька нюансів щодо протоколів маршрутизації. Якщо ви використовуєте BGP, то можливо вам доведеться скористатися командою loops 2, якщо ви будете пов'язувати два сайту клієнта з однаковими номерами автономних систем, а якщо у вас скрізь буде приміром OSPF, то не варто забувати про DN-біт. Кожен окремий випадок необхідно розглядати окремо.

Отже, ми створили vrf CE1 на PE1 і ASBR1, і vrf CE2 на PE2 і ASBR2, як показано на схемі. Експорт та імпорт vpnv4 маршрутів можливий тільки між даними vrf-ми всередині автономної системи. Між автономними системами маршрутами обмінюються тільки ASBR-ри (ipv4 unicast). Перевіримо зв'язність між клієнтськими маршрутизаторами CE1 і CE2:
R5#ping 10.0.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/70/84 ms

Все відмінно, зв'язність є. Тепер розглянемо, які будуть відбуватися операції з мітками по ходу просування пакету.
Отже, сморим маршрут на PE1:
bormoglotx@PE1> show route table CE1.inet.0 10.0.1.0/24

CE1.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.1.0/24 *[BGP/170] 00:03:29, localpref 100, from 10.0.10.10
AS path: 65000 64999 2 ?
> to 10.0.2.2 via ge-0/0/0.0, Push 16, Push 299824(top)

PE1 навішує дві мітки:

16 — мітка vrf, отриману через RR1 від ASBR1
299824 — транспортна позначка, отримана за протоколом ldp

і відправляє пакет інтерфейс ge-0/0/0.0 у бік P1.
P1 згідно таблиці mpls.0 (так як він транзитний маршрутизатор) виробляє зняття верхньої мітки (відпрацьовує механізм php) і надсилає цей пакет на ASBR1:
bormoglotx@P1> show route table mpls.0 label 299824

mpls.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

299824 *[LDP/9] 00:41:16, 1 metric
> to 10.0.3.1 via ge-0/0/1.0, Pop
299824(S=0) *[LDP/9] 00:41:16, 1 metric
> to 10.0.3.1 via ge-0/0/1.0, Pop

ASBR1 знімає позначку vrf і робить ip lookup в таблиці CE1.inet.0 (не забуваємо давати команду vrf-table-label на JunOS):
bormoglotx@ASBR1> show route table mpls.0 label 16

mpls.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

16 *[VPN/0] 00:35:23
to table CE1.inet.0, Pop

bormoglotx@ASBR1> show route table CE1.inet.0 10.0.1.0/24

CE1.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.1.0/24 *[BGP/170] 00:05:41, localpref 100
AS path: 64999 2 ?
> to 10.2.0.2 via ge-0/0/3.0

Пакет від ASBR1 передається через інтерфейс ge-0/0/3 на ASBR2 без mpls заголовка — тільки чистий ip трафік (зазвичай тегированный, в нашому випадку все одні vrf, тому я не став робити сабинтерфейсы, коли у вас буде кілька vrf, вам доведеться робити окремий сабинтерфейс на кожен vpn і вказувати його в налаштуваннях vrf).
ASBR2 отримавши IP пакет шукає маршрут в таблиці маршрутизації vrf CE2:
ASBR2#show ip route vrf CE2 10.0.1.0
Routing Table: CE2
Routing entry for 10.0.1.0/24
Known via "bgp 2", distance 200, 0 metric, type internal
Last update from 10.1.10.1 00:20:49 ago
Routing Descriptor Blocks:
* 10.1.10.1 (default), from 10.1.10.10, 00:20:49 ago
Route metric is 0, traffic share count is 1
AS Hops 0
MPLS label: 22
MPLS Flags: MPLS Required

ASBR2#sh mpls forwarding table 10.1.10.1
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
21 18 10.1.10.1/32 0 Gi1/0 10.1.0.2
17 10.1.10.1/32 0 Gi2/0 10.1.2.2

Відповідно до маршруту, ASBR2 навішує ярлик vrf (22), отриману за bgp vpnv4 від PE2 і відправляє в lsp на PE2 (10.1.10.1). Next-hop-му в маршруті вказаний P2 або RR2 (в нашому випадку рефлектор працює як P-маршрутизатор). Ми припустимо що трафік піде через P2 і будемо дивитися операції з мітками на ньому. P2 отримує пакет з двома мітками 22 і 17, дивиться в mpls forwarding table:
P1#sh mpls forwarding table labels 17
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
17 Pop Label 10.1.10.1/32 18542 Gi1/0 10.1.3.1

Згідно mpls forwarding table, P2 знімає верхню позначку (знову php) і надсилає пакет на PE2.

PE2 бачить, що ця мітка вказує на vrf CE2, виробляє ip lookup в таблиці vrf CE2 і відправляє чистий ip пакет клієнта:
PE2#sh mpls forwarding table labels 22
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
22 No Label 10.0.1.0/24[V] 14450 aggregate/CE2

PE2#sh ip rou vrf CE2 10.0.1.0

Routing Table: CE2
Routing entry for 10.0.1.0/24
Known via "connected", distance 0, 0 metric (connected, via interface)
Redistributing via bgp 2
Advertised by bgp 2
Routing Descriptor Blocks:
* directly connected, via GigabitEthernet3/0.10
Route metric is 0, traffic share count is 1

Зрозуміло, що дане рішення масштабується досить таки складно. Якщо ви підключаєте нового клієнта, то вам треба буде створити vrf не тільки на PE маршрутизаторі, на якому даний клієнт буде терминироваться, а ще й на ASBR (причому з відповідної сторони повинні будуть зробити те ж саме). Природно це рішення не задовольняє сьогоднішні запити операторів зв'язку, тому ми перейдемо до розгляду більш цікавих рішень — опції В і С.

Option B.

Між ASBR піднімається vpnv4 сесія, в рамках якої здійснюється обмін vpnv4 маршрутами (природно необхідно настроїти фільтрацію на ASBR передаються та отримуються префіксів, що б не віддати або не отримати щось зайве). Але ми знаємо, що маршрутизатор відкидає vpnv4 маршрути, якщо у нього немає VRF, якій (-их) ці маршрути призначені (якщо зазначеного в NLRI route-target немає ні в одному з vrf на import). Що б змінити це дефолтний поведінку на ASBR необхідно дозволити прийом всіх vpnv4 маршрутів ( keep all — Juniper, no bgp default route-target filter — IOS, retain route-target all — IOS XR, undo policy vpn-target — Huawei).

Отже, почнемо з control plane:

1. PE2 генерує vpnv4 маршрут і передає його на роутрефлектор RR2.

2. Роутрефлектор RR2 пересилає даний маршрут всім своїм клієнтам.

3. ASBR2, будучи клієнтом роутрефлектора, отримує згенерований PE2 vpnv4 маршрут. Так як на ньому включена опція no bgp default route-target filter, ASBR2 инсталирует отриманий маршрут в таблицю маршрутизації.

4. ASBR2 змінює в отриманому від роутрефлектора маршруті next-hop на себе, генерує нову мітку (причому значення мітки може і не змінитися) і відправляє цей маршрут на ASBR1 за ebgp vpnv4 сесії.

5. ASBR1 приймає vpnv4 маршрут від ASBR2 і инсталирует його в табилицу маршрутизації bgp.l3vpn.0 ( на маршрутизаторі дана команда keep all).

6. ASBR1 змінює в отриманому від ASBR2 маршруті next-hop на себе, генерує нову mpls мітку і надсилає цей маршрут на RR1.

7. RR1, отримавши даний маршрут перевіряє доступність next-hop, as-path (стандартний механізм вибору кращого маршруту bgp) і инсталирует даний маршрут в свою таблицю маршрутизації.

8. RR1 передає отриманий від ASBR1 маршрут на PE1.

9. PE1 отримавши від роутрефлектора vpnv4 маршрут перевіряє доступність next-hop, перевіряє чи відповідає extcommunity (rt) в отриманому маршруті сконфигрурированному на маршрутизаторі vrf-import і инсталирует його в таблицю маршрутизації відповідного vrf.

Транспортні мітки до ASBR всередині AS розподіляються стандартним способом — LDP або RSVP-TE.

Тепер розглянемо все вищесказане на прикладі:

Розглянемо як буде відбуватися сигналізація мітки для клієнтського префікса 10.0.1.0/24, який терминируется на PE2 vrf CE2:
PE2#sh ip route vrf CE2 10.0.1.0
Routing Table: CE2
Routing entry for 10.0.1.0/24
Known via "connected", distance 0, 0 metric (connected, via interface)
Redistributing via bgp 2
Advertised by bgp 2
Routing Descriptor Blocks:
* directly connected, via GigabitEthernet3/0.10
Route metric is 0, traffic share count is 1

PE2 генерує vpnv4 маршрут і віддає його за iBGP на роутрефлектор RR2:
PE2#sh ip bgp vpnv4 rd 2:1 10.0.1.0/24
BGP routing table entry for 2:1:10.0.1.0/24, version 2
Paths: (1 available, best #1, table CE2)
Advertised to update-groups:
1
Local
0.0.0.0 from 0.0.0.0 (10.1.10.1)
Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best
Extended Community: RT:1:100 OSPF DOMAIN ID:0x0005:0x000000020200
OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.1.1:0
mpls labels in/out 17/nolabel(CE2)

Згідно висновку вище для даного префікса згенерована мітка 17: mpls labels in/out 17/nolabel(CE2)
Далі PE2 віддає vpnv4 маршрути на роутрефлектор. Маршрутів два, так як це один мережу між PE2 і CE2, а другий – лупбек клієнтського маршрутизатора CE2.
PE2#sh ip bgp vpnv4 all сусідів 10.1.10.10 advertised-routes
BGP table version is 39, local router ID is 10.1.10.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Originating default network 0.0.0.0

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 2:1 (default for vrf CE1)
*> 10.0.1.0/24 0.0.0.0 0 32768 ?
*> 10.1.1.2/32 10.0.1.2 2 32768 ?

Total number of prefixes 2

Роутрефлектор RR2 передає отриманий від PE2 vpnv4 маршрут своїм клієнта, включаючи ASBR2:
RR2#sh ip bgp vpnv4 rd 2:1 сусідів 10.1.10.3 advertised-routes
BGP table version is 21, local router ID is 10.1.10.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Originating default network 0.0.0.0

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 2:1
*>i10.0.1.0/24 10.1.10.1 0 100 0 ?
*>i10.1.1.2/32 10.1.10.1 2 100 0 ?

Total number of prefixes 2

ASBR2 приймає цей маршрут і инсталирует його в таблицю маршрутизації:
ASBR2#sh ip bgp vpnv4 rd 2:1 10.0.1.0/24
BGP routing table entry for 2:1:10.0.1.0/24, version 4
Paths: (1 available, best #1, no table)
Advertised to update-groups:
1
Local
10.1.10.1 (metric 3) from 10.1.10.10 (10.1.10.10)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:1:100 OSPF DOMAIN ID:0x0005:0x000000020200
OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.1.1:0
Originator: 10.1.10.1, Cluster list: 10.1.10.10
mpls labels in/out 26/17

Звертаємо увагу на рядок mpls labels in/out 26/17. ASBR2 генерує нову мітку на in – 26 і відправляє всі наявні у нього vpnv4 маршрути (чи не всі якщо ви фільтрація на out) в сусідню AS на ASBR1:
ASBR2#sh ip bgp vpnv4 rd 2:1 сусідів 10.2.0.1 advertised-routes
BGP table version is 13, local router ID is 10.1.10.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Originating default network 0.0.0.0

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 2:1
*>i10.0.1.0/24 10.1.10.1 0 100 0 ?
*>i10.1.1.2/32 10.1.10.1 2 100 0 ?

Total number of prefixes 2

ASBR1 приймає ці маршрути і инсталирует в таблицю маршрутизації:
bormoglotx@ASBR1> show route receive-протоколу bgp 10.2.0.2 10.0.1.0/24 10.0.1.0/24 detail

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)

bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
* 2:1:10.0.1.0/24 (1 entry, 1 announced)
Accepted
Route Distinguisher: 2:1
VPN Label: 26
Nexthop: 10.2.0.2
AS path: 2 ?
Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0

Крім того, що ASBR2 згенерував нову мітку, він так само і змінив next-hop на себе (Nexthop: 10.2.0.2).
ASBR2 генерує нову мітку (VPN Label: 299888) до префікса 10.0.1.0/24, змінює next-hop на себе (Nexthop: Self) і віддає маршрут на роутрефлектор RR1
bormoglotx@ASBR1> show route advertising-протоколу bgp 10.0.10.10 10.0.1.0/detail 24

bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
* 2:1:10.0.1.0/24 (1 entry, 1 announced)
BGP group RR type Internal
Route Distinguisher: 2:1
VPN Label: 299888
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1] 2 ?
Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0

Роутрефлектор RR1 віддає маршрут своїм клієнтам, включаючи і PE1:
bormoglotx@PE1> show route receive-протоколу bgp 10.0.10.10 10.0.1.0/detail 24

inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)

CE1.inet.0: 6 destinations, 6 routes (active 6, 0 holddown, 0 hidden)
* 10.0.1.0/24 (1 entry, 1 announced)
Import Accepted
Route Distinguisher: 2:1
VPN Label: 299888
Nexthop: 10.0.10.3
Localpref: 100
AS path: 2 ? (Originator) Cluster list: 10.0.10.10
AS path: Originator ID: 10.0.10.3
Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0

bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

* 2:1:10.0.1.0/24 (1 entry, 0 announced)
Import Accepted
Route Distinguisher: 2:1
VPN Label: 299888
Nexthop: 10.0.10.3
Localpref: 100
AS path: 2 ? (Originator) Cluster list: 10.0.10.10
AS path: Originator ID: 10.0.10.3
Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0

Маршрут ми бачимо в двох таблицях: в таблиці vrf CE1.inet.0 і в таблиці bgp vpnv4 маршрутів bgp.l3vpn.0.
Отримуючи vpnv4 маршрути, JunOS перевіряє їх на придатність (AS-PATH, доступність next-hop), чи є вказані в vpnv4 маршруті excommunity в конфиграциях routing instance на import, і якщо маршрут проходить дані перевірки і вибирається кращим згідно зі штатним алгоритму вибору bgp best path, він инсталируется на таблицю bgp.l3vpn.0. І вже це таблиця ip префікс переноситься в таблицю vrf (CE1.inet.0 в нашому випадку).

Data-plane:

З сигналізацією міток ми розібралися. Тепер розглянемо data plane, тобто як буде пересилатися пакет від CE1 (з 10.0.0.2) до CE2 (10.0.1.2) через «mpls хмара».
Для початку запустимо пінг між CE маршрутизаторами і переконаємося, що зв'язність між хостами є:
CE1#ping 10.0.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/91/132 ms

Тепер зробимо трасування:
R5#traceroute 10.0.1.2 numeric timeout 1

Type escape sequence to abort.
Tracing the route to 10.0.1.2

1 10.0.0.1 32 msec 4 msec 12 msec
2 10.0.2.2 [MPLS: Labels 299792/299888 Exp 0] 48 msec 68 msec 52 msec
3 10.0.3.1 [MPLS: Label 299888 Exp 0] 48 msec 60 msec 52 msec
4 10.2.0.2 [MPLS: Label 26 Exp 0] 64 msec 52 msec 52 msec
5 10.1.0.2 [MPLS: Labels 19/17 Exp 0] 48 msec 60 msec 52 msec
6 10.0.1.1 52 msec 52 msec 56 msec
7 10.0.1.2 48 msec 64 msec 108 msec

Видно, що максимальна кількість міток — 2.

Примітка: їх може бути і більше, якщо ви використовуєте traffic-engineereng. У нашому випадку мітки розподіляє тільки ldp.

Тепер розберемося з операціями над мітками при русі пакета по мережі.
На PE1 з клієнтського маршрутизатора CE1 прилітає чистий IP пакет (у нашому випадку з vlan тегом 10, але це не має значення, так як це l3vpn і тег знімається). Маршрут на PE1 говорить про те, що пакет необхідно відправити в mpls тунель. PE1 навішує дві мітки: мітку vrf — 299888 (яку ми отримали від ASBR1) і транспортну мітку до ASBR1 – 299792 (отриману за протоколом ldp):
bormoglotx@PE1> show route table CE1.inet.0 10.0.1.2

CE1.inet.0: 6 destinations, 6 routes (active 6, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.1.0/24 *[BGP/170] 00:15:32, localpref 100, from 10.0.10.10
AS path: 2 ?
to 10.0.2.2 via ge-0/0/0.0, Push 299888, Push 299792(top)
> to 10.0.0.2 via ge-0/0/1.0, Push 299888, Push 299792(top)

bormoglotx@PE1> show interfaces descriptions
Interface Admin Description Link
ge-0/0/0 up up to P1
ge-0/0/1 up up to RR1
ge-0/0/3 up up to SW1
lo0 up up router-id

PE1 надсилає цей пакет в інтерфейс ge-0/0/1 в бік RR1 (в нашому випадку роутрефлектор виконує функцію і P-маршрутизатора).
RR1 отримує пакет зі стеком міток і аналізує верхню позначку 299792:
bormoglotx@RR1> show route table mpls.0 label 299792

mpls.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

299792 *[LDP/9] 01:19:34, 1 metric
> to 10.0.1.1 via ge-0/0/0.0, Pop
299792(S=0) *[LDP/9] 01:19:34, 1 metric
> to 10.0.1.1 via ge-0/0/0.0, Pop

Згідно таблиці mpls.0, RR1 виробляє зняття мітки (php) і відправку пакета в інтерфейс ge-0/0/0.0 у бік ASBR2.
ASBR2 отримує паект тільки з однією міткою 299888. Дивимося, що він повинен зробити:
bormoglotx@ASBR1> show route table mpls.0 label 299888

mpls.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

299888 *[VPN/170] 00:17:02
> to 10.2.0.2 via ge-0/0/3.0, Swap 26

ASBR1 робить своп мітки 299888 на мітку 26 і відправляє пакет через стик з AS2 на ASBR2.

Далі ASBR2 теж виробляє своп мітки 26 на мітку 17 (він її отримав від PE2)
ASBR2#show ip bgp vpnv4 rd 2:1 10.0.1.0/24
BGP routing table entry for 2:1:10.0.1.0/24, version 4
Paths: (1 available, best #1, no table)
Advertised to update-groups:
1
Local
10.1.10.1 (metric 3) from 10.1.10.10 (10.1.10.10)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:1:100 OSPF DOMAIN ID:0x0005:0x000000020200
OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.1.1:0
Originator: 10.1.10.1, Cluster list: 10.1.10.10
mpls labels in/out 26/17

І так як в маршруті next-hop-ом є 10.1.10.1, то ASBR2 повинен додати ще й транспортну мітку (19) до PE2:
ASBR2#sh mpls forwarding table 10.1.10.1
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
23 19 10.1.10.1/32 0 Gi1/0 10.1.0.2
19 10.1.10.1/32 0 Gi2/0 10.1.2.2

Пакет відправляється на RR2 або P2, так як шляху рівнозначні… Подивимося, що буде робити з цим пакетом P2:
P1#sh mpls forwarding table labels 19
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
19 Pop Label 10.1.10.1/32 1180 Gi1/0 10.1.3.1

P2 виробляє зняття мітки і відправляє пакет з однією міткою на PE2.

PE2 отримує пакет з єдиною міткою 17, яка і є міткою vrf. В даному випадку використовується розподіл міток на префікс (одна мітка – одні префікс клієнта), що в реальному житті природно занадто дорого, тому режим розподілу міток необхідно перемкнути – per-vrf (одна мітка на vrf). На відміну ж від Cisco, в JunOS дефолтний механізм розподілу міток – per-next-hop. Якщо у клієнта Ethernet лінк, що природно буде в переважній більшості випадків, то необхідно включити генерацію міток per-vrf командою vrf-table-label. Принцип обробки пакета в даному випадку змінюється, і гідний окремої статті.
PE2#show mpls forwarding table labels 17
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
17 No Label 10.0.1.0/24[V] 0 aggregate/CE1

PE2#sh ip bgp vpnv4 rd 2:1 10.0.1.0/24
BGP routing table entry for 2:1:10.0.1.0/24, version 2
Paths: (1 available, best #1, table CE1)
Advertised to update-groups:
1
Local
0.0.0.0 from 0.0.0.0 (10.1.10.1)
Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best
Extended Community: RT:1:100 OSPF DOMAIN ID:0x0005:0x000000020200
OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.1.1:0
mpls labels in/out 17/nolabel(CE1)

Відповідно до представленої вище інформації, PE2 знімає позначку 17, робить ip lookup в таблиці vrf CE1 і відправляє пакет клієнта.

Конфігурації ASBR:
bormoglotx@ASBR1# show
keep all;
group RR {
type internal;
local address 10.0.10.3;
family inet-vpn {
unicast;
}
export NHS;
neighbor 10.0.10.10;
}
group ASBR-AS2 {
type external;
local address 10.2.0.1;
family inet-vpn {
unicast;
}
peer-as 2;
neighbor 10.2.0.2;
}


ASBR2#sh configuration | b router bgp
router bgp 2
no synchronization
no bgp default route-target filter
bgp log-neighbor-changes
neighbor 10.1.10.10 remote-as 2
neighbor 10.1.10.10 description RR2
neighbor 10.1.10.10 update-source Loopback0
neighbor 10.2.0.1 remote-as 1
neighbor 10.2.0.1 description ASBR1 | AS2
neighbor 10.2.0.1 update-source GigabitEthernet3/0
no auto-summary
!
address-family vpnv4
neighbor 10.1.10.10 activate
neighbor 10.1.10.10 send-community extended
neighbor 10.1.10.10 next-hop-self
neighbor 10.2.0.1 activate
neighbor 10.2.0.1 send-community extended
exit-address-family

ASBR2#sh run int gi3/0
Building configuration...

Current configuration : 143 bytes
!
interface GigabitEthernet3/0
description to ASBR1 | AS1
ip address 10.2.0.2 255.255.255.252
auto negotiation
mpls bgp forwarding
!
end

З Option B думаю розібралися. Перейдемо до Option С.

Option C

Обмін vpnv4 маршрутами здійснюється між роутрефлекторами різних AS безпосередньо за ebgp-multihop сесії, а на ASBR-ри лягає завдання з розподілу маршрутів з mpls мітками до лупбеков роутрефлекторов і PE маршрутизаторів сусідній автономної системи.

Розглянемо як працює control plane:

Розподіл транспортних міток:

1. ASBR2 по протоколу ldp отримує від своїх сусідів мітку до PE2.

2. ASBR2 відповідно налаштованої політиці генерує маршрути з мітками до лубеков автономної системи і bgp labeled-unicast передає дані маршрути на ASBR1, вказуючи в маршруті next-hop-ом.

3. ASBR1 приймає labeled-unicast маршрут від ASBR2 і инсталирует їх в mpls forwarding table.

4. ASBR1 генерує мітки для отриманих від ASBR2 маршрутів, вказує next-hop-ом себе і віддає маршрути на RR1.

5. RR1, отримавши дані маршрути перевіряє маршрут на валідність, инсталирует в свою таблицю маршрутизації і надсилає всім іншим своїм клієнтам.

6. PE1 отримавши від роутрефлектора labeled-unicast маршрут, виробляє його валідацію і инсталирует маршрут в таблицю маршрутизації.

Розподіл міток vrf:

1. PE2 генерує vpnv4 маршрут і передає його на роутрефлектор RR2.

2. Роутрефлектор RR2 пересилає даний маршрут всім своїм клієнтам і RR1 за eBGP multihop сесії, не змінюючи next-hop і значення міток.

3. RR1 передає отриманий від RR2 маршрут всім своїм клієнтам, включаючи і PE1.

4. PE1 перевірять маршрут на придатність і встановлює в таблицю маршрутизації відповідного vrf.

Мітки vrf і транспортні мітки розподілені.

Тепер подивимося, як це все працює на практиці. Спочатку нам необхідно розподілити маршрути лупбеков між автономними системами, так як наша vpnv4 сесія між роутрефлекторами не підніметься через відсутність маршруту до віддаленого роутрефлектора. Ми будемо розподіляти між автономними системами відразу маршрути з мітками, тому між ASBR-мі буде тільки labeled-unicast сесія (ipv4 префікси без міток нам не потрібні). Але якщо вам потрібні обидва сімейства адрес, то необхідно буде вказати, що маршрути labeled-unicast необхідно інсталювати в inet.3(інакше на JunOS ви два сімейства адрес ipv4 і ipv4 labeled-unicast в одній сесії не підніміть).

Конфігурація bgp на ASBR1 (сесія з ASBR2):
bormoglotx@ASBR1> show configuration protocols bgp group ASBR-AS2
type external;
local address 10.2.0.1;
family inet {
labeled-unicast;
}
export Lo-export;
peer-as 2;
neighbor 10.2.0.2;

bormoglotx@ASBR1> show configuration policy-options policy-statement Lo-export
term 1 {
from {
protocol isis;
route-filter 10.0.10.0/24 prefix-length-range /32-/32;
}
then accept;
}
term 2 {
then reject;

Подивимося як відпрацює сигналізація мітки до лупбека PE2.

І так, всередині автономної системи у нас запущений ldp і мітки до лупбеков автоматично розлітаються на всі AS. Природно у ASBR2 є мітки до лупбеков всіх маршрутизаторів AS2. Тепер ASBR2 повинен згенерувати маршрути з мітками до лупбеков своєї AS і передати їх на ASBR1. Подивимося:
ASBR2#sh ip bgp 10.1.10.1/32
BGP routing table entry for 10.1.10.1/32, version 2
Paths: (1 available, best #1, table default)
Advertised to update-groups:
1 2
Local
10.1.0.2 from 0.0.0.0 (10.1.10.3)
Origin incomplete, metric 3, localpref 100, weight 32768, valid, sourced, best
mpls labels in/out 22/nolabel

Як видно з висновку, ASBR2 згенерував мітку до префікса 10.1.10.1 на in, рівну 22.

Подивимося даний маршрут на ASBR1:
bormoglotx@ASBR1> show route receive-протоколу bgp 10.2.0.2 10.1.10.1/detail 32

inet.0: 17 destinations, 20 routes (17 active, 0 holddown, 0 hidden)
* 10.1.10.1/32 (1 entry, 1 announced)
Accepted
Route Label: 22
Nexthop: 10.2.0.2
MED: 3
AS path: 2 ?

Нас цікавить у висновку мітка: 22 і next-hop: 10.2.0.2 (адреса інтерфейсу ASBR2). Тепер ASBR2 знає як дістатися до PE2.

Далі це маршрут по labeled -unicast сесії передається на рефлектор і з нього розподіляється всередині автономної системи між PE маршрутизаторами. Але тут є одне але, якщо ASBR1 передасть маршрут в тому ж вигляді, що і отримав від ASBR2, то нічого не заробить, так як маршруту до мережі 10.2.0.0/30 (мережа між ASBR-ми) всередині автономної системи немає. Тому ASBR1 змінює next-hop на себе і генерує нову мітку:
bormoglotx@ASBR1> show route advertising-протоколу bgp 10.0.10.10 10.1.10.1/detail 32

inet.0: 17 destinations, 20 routes (17 active, 0 holddown, 0 hidden)
* 10.1.10.1/32 (1 entry, 1 announced)
BGP group RR type Internal
Route Label: 299920
Nexthop: Self
Flags: Nexthop Change
MED: 3
Localpref: 100
AS path: [1] 2 ?

Подивимося тепер цей маршрут на PE1:
bormoglotx@PE1> show route протоколу bgp 10.1.10.1/32

inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.1.10.1/32 *[BGP/170] 00:26:35, MED 3, localpref 100, from 10.0.10.10
AS path: 2 ?
> to 10.0.2.2 via ge-0/0/0.0, Push 299920, Push 299776(top)
to 10.0.0.2 via ge-0/0/1.0, Push 299920, Push 299776(top)

inet.3: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.1.10.1/32 *[BGP/170] 00:26:35, MED 3, localpref 100, from 10.0.10.10
AS path: 2 ?
> to 10.0.2.2 via ge-0/0/0.0, Push 299920, Push 299776(top)
to 10.0.0.2 via ge-0/0/1.0, Push 299920, Push 299776(top)

Все вірно, мітка 299920 використовується що б дістатися до PE2. У висновку ми так само бачимо ще одну мітку 299776, тобто у нас вийшов стек міток. Про призначення другої (299776) буде написано трохи нижче).

Чудово, тепер у нас є end-to-end lsp між PE1 і PE2. Власне кажучи між рефлекторами теж тепер є lsp, так як маршрути до RR1 і RR2 теж віддаються з мітками. Після того, як ми розподілили маршрути лупбеков між автономними системами, між роутрефлекторами піднімається сусідство:
bormoglotx@RR1> show bgp neighbor 10.1.10.10
Peer: 10.1.10.10+34875 AS 2 Local: 10.0.10.10+179 AS 1
Type: External State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Options: <Multihop NoNextHopChange Preference LocalAddress Ttl AddressFamily PeerAS Rib-group Refresh>
Address families configured:inet-vpn-unicast
Local Address: 10.0.10.10 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 10.1.10.10 Local ID: 10.0.10.10 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 0
BFD: disabled, down
NLRI for restart configured on peer: inet-vpn-unicast
NLRI advertised by peer: inet-unicast inet-vpn-unicast
NLRI for this session: inet-vpn-unicast
Peer supports Refresh capability (2)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
Peer does not support Receiver functionality
Peer supports 4 AS byte extension (peer-as 2)
Peer does not support Addpath
Table bgp.l3vpn.0 Bit: 20001
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: in sync
Active prefixes: 2
Received prefixes: 2
Accepted prefixes: 2
Suppressed due to damping: 0
Advertised prefixes: 2
Last traffic (seconds): Received 20 Sent 13 Checked 68
Input messages: Total 210 Updates 3 Refreshes 0 Octets 4222
Output messages: Total 212 Updates 2 Refreshes 0 Octets 4205
Output Queue[1]: 0

Між рефлекторами розподіляються vpnv4 маршрути: NLRI for this session: inet-vpn-unicast.
Ми приймаємо 2 префікса від сусіда: Accepted prefixes: 2
І стільки ж віддаємо: Advertised prefixes: 2
Думаю це зрозуміло.

Налаштування рефлекторів:
bormoglotx@RR1# show protocols bgp group RR-AS2
type external;
multihop {
ttl 5;
no-nexthop-change;
}
local address 10.0.10.10;
family inet-vpn {
unicast;
}
peer-as 2;
neighbor 10.1.10.10;


RR2#sh configuration | b router bgp
router bgp 2
bgp log-neighbor-changes
neighbor 10.0.10.10 remote-as 1
neighbor 10.0.10.10 ebgp-multihop 5
neighbor 10.0.10.10 update-source Loopback0
!
address-family vpnv4
neighbor 10.0.10.10 activate
neighbor 10.0.10.10 send-community extended
neighbor 10.0.10.10 next-hop-unchanged
exit-address-family

Примітка: у конфігурації RR2 (Cisco IOS15) частину рядків, що не відносяться до 10.0.10.10 видалені, що б скоротити розмір виводу.

Тепер ми можемо подивитися, як працює розподіл міток vrf:

PE2 генерує маршрут до мережі 10.0.1.0/24, яка терминируется в vrf CE1
PE2#sh ip bgp vpnv4 rd 2:1 10.0.1.0/24
BGP routing table entry for 2:1:10.0.1.0/24, version 2
Paths: (1 available, best #1, table CE1)
Advertised to update-groups:
1
Local
0.0.0.0 from 0.0.0.0 (10.1.10.1)
Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best
Extended Community: RT:1:100 OSPF DOMAIN ID:0x0005:0x000000020200
OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.1.1:0
mpls labels in/out 22/nolabel(CE1)

Як бачимо була сгенерирована мітка 22.

Далі маршрут віддається на RR2:
PE2#sh ip bgp vpnv4 all сусідів 10.1.10.10 advertised-routes
BGP table version is 7, local router ID is 10.1.10.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Originating default network 0.0.0.0

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 2:1 (default for vrf CE1)
*> 10.0.1.0/24 0.0.0.0 0 32768 ?
*> 10.1.1.2/32 10.0.1.2 2 32768 ?

Total number of prefixes 2

Роутрефлектор віддає цей маршрут всім своїм клієнта а так само на RR1:
RR2#sh ip bgp vpnv4 rd 2:1 сусідів 10.0.10.10 advertised-routes
BGP table version is 5, local router ID is 10.1.10.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Originating default network 0.0.0.0

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 2:1
*>i10.0.1.0/24 10.1.10.1 0 100 0 ?
*>i10.1.1.2/32 10.1.10.1 2 100 0 ?

Total number of prefixes 2

Подивимося отриманий маршрут на RR1:
bormoglotx@RR1> show route table bgp.l3vpn.0 10.0.1.0/24

bgp.l3vpn.0: 4 destinations, 4 routes (2 active, 0 holddown, 2 hidden)

Маршрут потрапив в hidden і нікуди більше не поширюється. Виникає питання чому. (Причому в Cisco немає такої біди)
bormoglotx@RR1> show route table bgp.l3vpn.0 10.0.1.0/24 hidden

bgp.l3vpn.0: 4 destinations, 4 routes (2 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both

2:1:10.0.1.0/24
[BGP/170] 00:29:12, localpref 100, from 10.1.10.10
AS path: 2 ?
Unusable

Подивимося причину:
bormoglotx@RR1> show route table bgp.l3vpn.0 10.0.1.0/24 hidden detail

bgp.l3vpn.0: 4 destinations, 4 routes (2 active, 0 holddown, 2 hidden)
2:1:10.0.1.0/24 (1 entry, 0 announced)
BGP Preference: 170/-101
Route Distinguisher: 2:1
Next hop type: Unusable
Address: 0x8f3c5a4
Next-hop reference count: 2
State: <Hidden Ext>
Local AS: 1 Peer AS: 2
Age: 31:00
Task: BGP_2.10.1.10.10+34875
AS path: 2 ?
Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0
Accepted
VPN Label: 22
Localpref: 100
Router ID: 10.1.10.10

У виведенні на проти Next hop type варто Unusable. Роутрефлектор перевірив маршрут на доступність next-hop, але не знайшов в таблиці маршрутизації маршрут до зазначеного next-hop.

Подивимося в таблицю маршрутизації:
bormoglotx@RR1> show route 10.1.10.1/32

inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.1.10.1/32 *[BGP/170] 00:33:04, MED 3, localpref 100, from 10.0.10.3
AS path: 2 ?
> to 10.0.1.1 via ge-0/0/0.0, Push 299920

Маршрут є і навіть з позначкою (логічно, ми ж його поширили з ASBR1 за labeled-unicast). Справа в тому, що в JunOS (на відміну від інших вендорів) є кілька таблиць маршрутизації. Зараз нас цікавить таблиці inet.0 і inet.3.

inet.0 — таблиця маршрутизації, в якій зберігаються ipv4 unicast маршрути.

inet.3 — таблиця маршрутизації, в якій зберігаються ipv4 mpls маршрути. Цією таблицею користується маршрутизатор, якщо він є ingress LSR.

BGP, отримуючи vpnv4 маршрути, намагається разрезольвить next-hop саме у таблиці inet.3. За замовчуванням, bgp labeled unicast маршрути инсталируются в таблицю inet.0 і вони не потрапляють в inet.3. Тобто — роутрефлектор отримав vpnv4 маршрут і намагається разрезольвить next-hop, але не знаходить маршрут до нього в таблиці inet.3 і позначає vpnv4 маршрут як hidden у зв'язку з unusable next-hop.

Необхідно змінити цю поведінку. Для його є кілька важелів:

resolve-vpn — ця команда змінює поведінку JunOS щодо встановлення labeled-unicast маршрутів в таблицю маршрутизації. Тепер JunOS буде встановлювати отримані за bgp labeled-unicast маршрути і таблиці inet.0 і в таблицю inet.3.

rib-groups — дуже гнучкий механізм, можна з допомогою політики перетягнути певні маршрути (в плоть до префікса /32) з однієї таблиці маршрутизації в іншу (в нашому випадку з inet.0 у inet.3) Але з rib-groups потрібно бути уважним, так як можна наламати дров, не чітко розуміючи, що робиш (можливості rib-groups дуже великі).

resolution rib bgp.l3vpn.0 resolution-ribs inet.0 — ця команда дозволяє нікуди нічого не переносити, а лише примушує маршрутизатор резольвить vpnv4 маршрути в таблиці inet.0.

На роутрефлеторе дамо команду resolution rib, а на PE маршрутизаторі resolve-vpn:
bormoglotx@RR1# show routing-options
router-id 10.0.10.10;
autonomous system 1;
resolution {
rib bgp.l3vpn.0 {
resolution-ribs inet.0;
}
}

Тепер маршрути на рефлекторі з'явилися і можу бути поширені всередині автономної системи:
bormoglotx@RR1> show route receive-протоколу bgp 10.1.10.10

inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)

inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

iso.0: 1 destinations, 1 routes (active 1, 0 holddown, 0 hidden)

mpls.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)

bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref path AS
2:1:10.0.1.0/24
* 10.1.10.1 2 ?
2:1:10.1.1.2/32
* 10.1.10.1 2 ?

Подивимося сам маршрут з деталями:
bormoglotx@RR1> show route протоколу bgp rd-prefix 2:1:10.0.1.0/detail 24

bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
2:1:10.0.1.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Route Distinguisher: 2:1
Next hop type: Indirect
Address: 0x934d6d8
Next-hop reference count: 1
Source: 10.1.10.10
Protocol next hop: 10.1.10.1
Push 22
Indirect next hop: 2 no-forward
State: <Active Ext>
Local AS: 1 Peer AS: 2
Age: 11:55 Metric2: 1
Task: BGP_2.10.1.10.10+34875
Announcement bits (1): 0-BGP_RT_Background
AS path: 2 ?
Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0
Accepted
VPN Label: 22
Localpref: 100
Router ID: 10.1.10.10

У висновку видно, що next-hop залишився незмінним при переході через кордон автономної системи, що не характерно для ebgp. Справа в тому, що в конфігурації (показано вище) є команда no-nexthop-change — JunOS, next-hop-unchanged — Cisco, яка змінює поведінку ebgp і не дає міняти next-hop при переході кордону автономної системи. Для чого це потрібно. Якщо не дати цю команду, то у всіх vpnv4 маршрутах роутрефлектор буде ставити себе next-hop-ом, тобто весь vpn трафік полізе через роутрефлектор, якого і так не солодко в житті. Тепер, крім перетравлення купи маршрутів (особливо якщо на ньому FV), йому доведеться і обробляти величезну кількість трафіку. Власне кінець завжди один — дана схема потерпить фіаско, а якщо бути точніше — падіння роутрефлектора з усіма витікаючими. Причому навіть наявність двох резервують рефлекторів вам не допоможе. Але повернемося до нашої тополигии і помотрим vpnv4 маршрут на PE1 (не забуваємо, що ми вже дали команду resolve-vpn, інакше маршрути потраплять в hidden):
bormoglotx@PE1> show configuration protocols bgp group RR
type internal;
local address 10.0.10.1;
family inet {
labeled-unicast {
resolve-vpn;
}
}
family inet-vpn {
unicast;
}
neighbor 10.0.10.10;


bormoglotx@PE1> show route table CE1.inet.0 10.0.1.0/detail 24

CE1.inet.0: 6 destinations, 6 routes (active 6, 0 holddown, 0 hidden)
10.0.1.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Route Distinguisher: 2:1
Next hop type: Indirect
Address: 0x934d2e8
Next-hop reference count: 3
Source: 10.0.10.10
Next hop type: Router, Next hop index: 608
Next hop: 10.0.2.2 via ge-0/0/0.0, selected
Label operation: Push 22, Push 299920, Push 299776(top)
Label TTL action: prop-ttl, prop-ttl, prop-ttl(top)
Protocol next hop: 10.1.10.1
Push 22
Indirect next hop: 94a0658 262151
State: <Secondary Active Int Ext>
Local AS: 1 Peer AS: 1
Age: 39:28 Metric2: 1
Task: BGP_1.10.0.10.10+179
Announcement bits (2): 0-CE1-OSPF 1-KRT
AS path: 2 ?
Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0
Import Accepted
VPN Label: 22
Localpref: 100
Router ID: 10.0.10.10
Primary Routing Table bgp.l3vpn.0


Нам цікаві рядки:
Protocol next hop: 10.1.10.1
Push 22
VPN Label: 22

Сигналізація спрацювала, тепер у нас є lsp між PE маршрутизаторами і мітки vrf.

Data-plane:

Ну тепер подивимося як буде передаватися трафік просигнализированному маршруту.
Для початку перевіримо зв'язність між CE:
CE1#ping 10.0.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/57/68 ms

Відмінно. Тепер можна зробити трасування:
R5#traceroute 10.0.1.2

Type escape sequence to abort.
Tracing the route to 10.0.1.2

1 10.0.0.1 4 msec 4 msec 8 msec
2 10.0.2.2 [MPLS: Labels 299776/299920/22 Exp 0] 48 msec 48 msec 12 msec
3 10.0.3.1 [MPLS: Labels 299920/22 Exp 0] 76 msec 56 msec 36 msec
4 10.2.0.2 [MPLS: Labels 22/22 Exp 0] 48 msec 12 msec 76 msec
5 10.1.2.2 [MPLS: Labels 17/22 Exp 0] 40 msec 52 msec 44 msec
6 10.0.1.1 44 msec 60 msec 48 msec
7 10.0.1.2 44 msec 56 msec 56 msec

Видно стек з трьох міток.

І так, сморим маршрут на PE1 до клієнтського префікса 10.0.1.0/24:
bormoglotx@PE1> show route table CE1.inet.0 10.0.1.0/24

CE1.inet.0: 6 destinations, 6 routes (active 6, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.1.0/24 *[BGP/170] 00:39:25, localpref 100, from 10.0.10.10
AS path: 2 ?
> to 10.0.2.2 via ge-0/0/0.0, Push 22, Push 299920, Push 299776(top)

PE1 навішує три мітки:

22 — позначка vrf, одержана через рефлектори від PE2
299920 — мітка до лупбека PE2, отримана через роутрефлектор від ASBR1
299776 — мітка до ASBR1, отримана за протоколом LDP

та надсилає цей пакет у бік P1: Next hop: 10.0.2.2 via ge-0/0/0.0
bormoglotx@PE1> show interfaces descriptions
Interface Admin Description Link
ge-0/0/0 up up to P1
ge-0/0/1 up up to RR1
ge-0/0/3 up up to SW1
lo0 up up router-id

Примітка: так як ми розподілили мітку до PE2 за labeled-unicast, то P1 немає мітки до лубека PE2. Якщо ми пошлемо пакет з двома мітками, то P1 не буде знати що робити з цією міткою. Тому нам потрібно додати ще одну мітку до ASBR1, тоді P1 буде обробляти цей трафік не підозрюючи що це трафік в сусідню AS (працює вона тільки з верхньої міткою). Іншими словами, ми в lsp до ASBR1 туннелируем lsp про PE2.

Подивимося, що зробить P1 з одержаним пакетом:
bormoglotx@P1> show route table mpls.0 label 299776

mpls.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

299776 *[LDP/9] 01:13:09, 1 metric
> to 10.0.3.1 via ge-0/0/1.0, Pop
299776(S=0) *[LDP/9] 01:13:09, 1 metric
> to 10.0.3.1 via ge-0/0/1.0, Pop

Все логічно, P1 знімає верхню позначку (механізм php) і відправляє пакет вже зі стеком їх двох міток на ASBR1.

ASBR1 виробляє своп верхньої мітки (теги до PE2), на мітку, яку йому повідомив ASBR2:
bormoglotx@ASBR1> show route table mpls.0 label 299920

mpls.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

299920 *[VPN/170] 01:13:51
> to 10.2.0.2 via ge-0/0/3.0, Swap 22

Примітка: вийшов дуже наочно — мітка 22 була сгенерирована ASBR2 для досягнення PE2, в той же час як мітка 22 була сгенерирована і PE2 як vrf мітка. Тому у нас пакет між ASBR1 і ASBR2 буде йти зі стеком з двох однакових позначок 22/22. Реально ж це дві різні мітки (за призначенням) і те що вони в даному випадку однакові — випадковість.

Далі пакет потрапляє на ASBR2.
ASBR2#sh mpls forwarding table labels 22
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
22 18 10.1.10.1/32 0 Gi1/0 10.1.0.2
17 10.1.10.1/32 13378 Gi2/0 10.1.2.2

ASBR2 виробляє своп верхньої мітки в стеку на мітку 18 або 17 (у нас еквівалентні шляху). Ці мітки він отримав з протоколу ldp:
ASBR2#show mpls ldp bindings 10.1.10.1 32
lib entry: 10.1.10.1/32, rev 18
local binding: label: 22
remote binding: lsr: 10.1.10.2:0, label: 17
remote binding: lsr: 10.1.10.10:0, label: 18

Припустимо що пакет йде на P2, значить ASBR2 виробляє своп верхньої мітки на мітку 17.
Дивимося що буде робити P2:
P1#sh mpls forwarding table labels 17
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
17 Pop Label 10.1.10.1/32 12936 Gi1/0 10.1.3.1

P2 знімає позначку і відправляє пакет вже з однією міткою (міткою vrf) на PE2.
Залишилося тільки перевірити, що буде робити PE2 з пакетом з міткою 22.
PE1 дивиться в mpls forwarding table, знімає позначку, робить ip lookup в таблиці CE1 і відправляє пакет інтерфейс GigabitEthernet3/0.10, який дивиться в SW2, до якого підключений спеціальний маршрутизатор CE2:
PE2#sh mpls forwarding table labels 22
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
22 No Label 10.0.1.0/24[V] 3296 aggregate/CE1

PE2#sh ip route vrf CE1 10.0.1.0

Routing Table: CE1
Routing entry for 10.0.1.0/24
Known via "connected", distance 0, 0 metric (connected, via interface)
Redistributing via bgp 2
Advertised by bgp 2
Routing Descriptor Blocks:
* directly connected, via GigabitEthernet3/0.10
Route metric is 0, traffic share count is 1

У даному прикладі я використовував схему зі стеком з трьох міток. Є варіант з використанням стека з 2-х міток. Відмінності в тому, що маршрути, одержувані ASBR-ми, повинні бути перерозподілені протокол IGP. Тоді ldp почне розподіляти мітки і до лупбеков сусідній автономної системи, але особисто мені цей варіант не подобається, як мінімум тому що ми засовуємо bgp маршрути в igp, що не дуже добре. Все інше аналогічно описаному вище.

Сподіваюся я доніс до читача принцип роботи даних опцій. Стаття вийшла дуже велика і писалася не один день, якщо хтось хоче щось додати чи помітив якийсь недолік (все таки я людина), прошу писати в лічку — поправимо і додамо. Якщо є питання — пишити в коментарі, по можливості відповім. Спасибі за увагу!

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.