Сегодня речь пойдет о команде vrf-table-label. Вначале вспомним о способах генерации vrf меток. Метки могут быть сгенерированны тремя способами — per-vrf, per-prefix и per-next-hop.
Соответственно маршрутизатор начинает генерировать vpnv4 префиксы и передавать их на роутрефлекторы. В нашем случае роутрефлектор имеет адрес 10.0.10.10:
PE1 отдает на рефлектор четыре маршрута: две connected сети и два /32 (лупбеки CE маршрутизаторов), которые получает по ospf. Посмотрим, какие метки были сгенерированны для данных префиксов:
Для наглядности выделим из выводов только значения меток:
Видно, что для префиксов из диапазона 10.0.0.0/8 сгенерирована метка 299888, а для префиксов из диапазона 20.0.0.0/8 метка 299904. Но есть один не очень приятный нюанс — в данном случае JunOS не производит ip lookup. Чем это грозит? Вы не сможете использовать фильтры, так как ip заголовок не анализируется.
а для пакетов с меткой 299888 — в интерфейс ge-0/0/3.10:
Как видите, маршрутизатор будет снимать метку и отправлять пакет в интерфейс в зависимости от входящей метки, не делая ip lookup-а, в чем мы сейчас и убедимся.
Теперь посмотрим таблицу маршрутизации на CE2:
Все отлично — маршруты есть. Теперь можем запустить трассировку до 20.0.0.2 — адрес CE1-2:
Все предсказуемо — стандартная трассировка через Option C.
А теперь запустим трассировку до 20.0.0.1 — это адрес интерфейса PE1 в сторону клиента (в самом начале статьи показана настройка интерфейса):
Сравнивая вывод с предыдущим, мы видим что до 20.0.0.1 на один хоп больше. Как так, ведь 20.0.0.1 — шлюз для сети 20.0.0.0/24? Если смотреть внимательнее, то мы видим, что пакет с PE-маршрутизатора (10.0.2.1 — core facing interface) был отправлен на CE маршрутизатор (адрес 20.0.0.2) и вернулся обратно на PE-маршрутизатор (20.0.0.1). Как я и сказал, JunOS не сделал ip lookup и просто переслал пакет в интерфейс клиента, а вот уже клиентский маршрутизатор проверил адрес назначения ip пакета и отправил его обратно на PE1 (см рисунок ниже):
То есть в нашем случае маршрутизатор принял пакет с меткой из ядра сети, посмотрел в таблице mpls.0 что необходимо сделать с пакетом, снял метку и отправил в интерфейс в сторону клиента.
Если мы повесим какой-либо фильтр на нашем PE маршрутизаторе на клиентский интерфейс или настроим qos, то ввиду вышесказанного трафик не будет обрабатываться согласно установленным фильтрам.
И теперь запустим пинг до сети 20.0.0.0/24 с CE2:
Фильтр есть, но он не работает. Изменим эту ситуацию, включив опцию vrf-table label:
Попробуем снова запустить пинг до сети 20.0.0.0/24 с CE2:
Теперь хост недостижим — фильтр отрабатывает. Снимем фильтр и снова запустим пинг для проверки:
Все отлично. Теперь мы увидели наглядно, какие подводные камни нас ожидают при дефолтном механизме распределения меток vrf в JunOS. Так как выше мы уже дали команду vrf-table-label и деактивировали фильтр, то приступим к обсуждению работы маршрутизатора с включенной опцией vrf-table-label.
Как видите, теперь у нас только одна метка на все маршруты из vrf CE1:
Снова запустим трассировку с CE2 до 20.0.0.1:
Теперь icmp пакеты не идут петлей через CE1-2.
Сам маршрут на PE1 теперь выглядит несколько иначе:
Говоря обычным языком, при получении пакета с меткой 16 необходимо снять метку и сделать ip lookup в таблице CE1.inet.0. Почему же в Juniper данная функция не реализована при генерации меток per-nex-hop? Дело в архитектуре оборудования Juniper — PFE не может сделать и mpls и ip lookup одновременно. Для реализации двойного lookup-а нам понадобится так называемый Tunnel Services PIC, далее туннельный PIC (интерфейс vt-fpc/pic/port.unit-number ). Вот так выглядит PIC в составе шасси M120:
Примечание: О создании vt-интерфейса и добавлении его в vrf можно почитать тут
Данный интерфейс не доступен для конфигурирования. На каждый vrf создается отдельный lsi интерфейс, который ассоциируется с генерируемой для данного vrf меткой. К примеру, создадим еще один vrf и посмотрим, сколько lsi интерфейсов теперь:
Интерфейс lsi создается и для vpls routing-instance (команда no-tunnel-services), трафик в таком случае обрабатывается как описано выше, за исключением того, что vpls оперирует исключительно mac адресами, не зная ничего о клиентских ip адресах, но это уже совсем другая история.
per-prefix — одна метка — один клиентский префикс, то есть если у нас 100 клиентских vrf и у каждого клиента по 100 префиксов, то мы получим 100х100=10 000 меток, что очень расточительно по сегодняшним меркам. Данный метод распределения меток vrf по дефолту используется в маршрутизаторах Cisco.
per-next-hop — одна метка на все префиксы клиента, которые имеют один и тот же next-hop. Если клиентский маршрутизатор подключен к PE маршрутизатору одним линком, то все префиксы будут иметь один и тот же next-hop, а значит одну и ту же метку. Данный механизм распределения меток vrf по дефолту в JunOS.
per-vrf — одна метка на весь vrf. С точки зрения распределения меток этот режим очень экономичен: если у нас 100 клиентских vrf и у каждого клиента по 100 префиксов, то мы получим 100х1=100 меток. При таком распределении меток vrf маршрутизатор должен делать помимо mpls lookup еще и ip lookup.
Как было написано выше, по умолчанию JunOS использует распределение меток per-next-hop. Если вы хотите изменить это поведение, то вам придется дать команду vrf-table-label (для любителей замороченных конфигураций механизм распределения меток можно задать с помощью политики) либо использовать тоннельный PIC. Теперь разберем как все работает с данной командой и без нее. Будем использовать вот такую схему с Option C.
Без команды vrf-table label (и создания vt-интерфейса).
Конфигурация vrf на PE1 выглядит следующим образом:
bormoglotx@PE1> show configuration routing-instances CE1
instance-type vrf;
interface ge-0/0/3.10;
interface ge-0/0/3.20;
route-distinguisher 1:1;
vrf-target {
import target:2:100;
export target:2:100;
}
protocols {
ospf {
export ospf-export;
area 0.0.0.0 {
interface ge-0/0/3.10;
interface ge-0/0/3.20;
}
}
}
bormoglotx@PE1> show configuration interfaces ge-0/0/3
description "to SW1";
vlan-tagging;
unit 10 {
description "to CE1 site 1";
vlan-id 10;
family inet {
address 10.0.0.1/24;
}
}
unit 20 {
description "to CE1 site 2";
vlan-id 20;
family inet {
address 20.0.0.1/24;
}
}
Соответственно маршрутизатор начинает генерировать vpnv4 префиксы и передавать их на роутрефлекторы. В нашем случае роутрефлектор имеет адрес 10.0.10.10:
bormoglotx@PE1> show route advertising-protocol bgp 10.0.10.10
CE1.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.0.0.0/24 Self 100 I
* 10.1.1.1/32 Self 2 100 I
* 20.0.0.0/24 Self 100 I
* 20.1.1.1/32 Self 2 100 I
PE1 отдает на рефлектор четыре маршрута: две connected сети и два /32 (лупбеки CE маршрутизаторов), которые получает по ospf. Посмотрим, какие метки были сгенерированны для данных префиксов:
bormoglotx@PE1> show route advertising-protocol bgp 10.0.10.10 detail
CE1.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
* 10.0.0.0/24 (1 entry, 1 announced)
BGP group RR type Internal
Route Distinguisher: 1:1
VPN Label: 299888
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1] I
Communities: target:2:100
* 10.1.1.1/32 (1 entry, 1 announced)
BGP group RR type Internal
Route Distinguisher: 1:1
VPN Label: 299888
Nexthop: Self
Flags: Nexthop Change
MED: 2
Localpref: 100
AS path: [1] I
Communities: target:2:100 rte-type:0.0.0.0:1:0
* 20.0.0.0/24 (1 entry, 1 announced)
BGP group RR type Internal
Route Distinguisher: 1:1
VPN Label: 299904
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1] I
Communities: target:2:100
* 20.1.1.1/32 (1 entry, 1 announced)
BGP group RR type Internal
Route Distinguisher: 1:1
VPN Label: 299904
Nexthop: Self
Flags: Nexthop Change
MED: 2
Localpref: 100
AS path: [1] I
Communities: target:2:100 rte-type:0.0.0.0:1:0
Для наглядности выделим из выводов только значения меток:
bormoglotx@PE1> show route advertising-protocol bgp 10.0.10.10 detail | match label
VPN Label: 299888
VPN Label: 299888
VPN Label: 299904
VPN Label: 299904
Видно, что для префиксов из диапазона 10.0.0.0/8 сгенерирована метка 299888, а для префиксов из диапазона 20.0.0.0/8 метка 299904. Но есть один не очень приятный нюанс — в данном случае JunOS не производит ip lookup. Чем это грозит? Вы не сможете использовать фильтры, так как ip заголовок не анализируется.
Проверим это на практике.
Согласно представленному ниже выводу, PE1, получив пакет с меткой 299904 просто отправляет его в интерфейс ge-0/0/3.20:
bormoglotx@PE1> show route table mpls.0 label 299904
mpls.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
299904 *[VPN/170] 00:46:19
> to 20.0.0.2 via ge-0/0/3.20, Pop
а для пакетов с меткой 299888 — в интерфейс ge-0/0/3.10:
bormoglotx@PE1> show route table mpls.0 label 299888
mpls.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
299888 *[VPN/170] 00:46:25
> to 10.0.0.2 via ge-0/0/3.10, Pop
Как видите, маршрутизатор будет снимать метку и отправлять пакет в интерфейс в зависимости от входящей метки, не делая ip lookup-а, в чем мы сейчас и убедимся.
Проверим наличие vpnv4 маршрутов на PE2:
PE2#sh ip bgp vpnv4 rd 1:1 labels
Network Next Hop In label/Out label
Route Distinguisher: 1:1
10.0.0.0/24 10.0.10.1 nolabel/299888
10.1.1.1/32 10.0.10.1 nolabel/299888
20.0.0.0/24 10.0.10.1 nolabel/299904
20.1.1.1/32 10.0.10.1 nolabel/299904
Теперь посмотрим таблицу маршрутизации на CE2:
CE2#sh ip rou | b Ga
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
O E2 10.0.0.0/24 [110/10] via 10.0.1.1, 00:22:32, GigabitEthernet1/0.10
C 10.0.1.0/24 is directly connected, GigabitEthernet1/0.10
L 10.0.1.2/32 is directly connected, GigabitEthernet1/0.10
O E2 10.1.1.1/32 [110/10] via 10.0.1.1, 00:22:32, GigabitEthernet1/0.10
C 10.1.1.2/32 is directly connected, Loopback0
20.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O E2 20.0.0.0/24 [110/10] via 10.0.1.1, 00:22:32, GigabitEthernet1/0.10
O E2 20.1.1.1/32 [110/10] via 10.0.1.1, 00:22:32, GigabitEthernet1/0.10
Все отлично — маршруты есть. Теперь можем запустить трассировку до 20.0.0.2 — адрес CE1-2:
CE2#traceroute 20.0.0.2
Type escape sequence to abort.
Tracing the route to 20.0.0.2
1 10.0.1.1 36 msec 32 msec 8 msec
2 10.1.3.2 [MPLS: Labels 20/18/299904 Exp 0] 56 msec 64 msec 60 msec
3 10.1.2.1 [MPLS: Labels 18/299904 Exp 0] 72 msec 108 msec 40 msec
4 10.2.0.1 [MPLS: Labels 299952/299904 Exp 0] 60 msec 88 msec 60 msec
5 10.0.3.2 [MPLS: Labels 299808/299904 Exp 0] 76 msec 68 msec 64 msec
6 10.0.2.1 [MPLS: Label 299904 Exp 0] 60 msec 52 msec 64 msec
7 20.0.0.2 60 msec 60 msec 56 msec
Все предсказуемо — стандартная трассировка через Option C.
А теперь запустим трассировку до 20.0.0.1 — это адрес интерфейса PE1 в сторону клиента (в самом начале статьи показана настройка интерфейса):
CE2#traceroute 20.0.0.1
Type escape sequence to abort.
Tracing the route to 20.0.0.1
1 10.0.1.1 40 msec 4 msec 16 msec
2 10.1.3.2 [MPLS: Labels 20/18/299904 Exp 0] 80 msec 64 msec 60 msec
3 10.1.2.1 [MPLS: Labels 18/299904 Exp 0] 56 msec 60 msec 72 msec
4 10.2.0.1 [MPLS: Labels 299952/299904 Exp 0] 48 msec 76 msec 112 msec
5 10.0.3.2 [MPLS: Labels 299808/299904 Exp 0] 68 msec 96 msec 64 msec
6 10.0.2.1 [MPLS: Label 299904 Exp 0] 80 msec 68 msec 4 msec
7 20.0.0.2 92 msec 72 msec 64 msec
8 20.0.0.1 96 msec 48 msec 88 msec
Сравнивая вывод с предыдущим, мы видим что до 20.0.0.1 на один хоп больше. Как так, ведь 20.0.0.1 — шлюз для сети 20.0.0.0/24? Если смотреть внимательнее, то мы видим, что пакет с PE-маршрутизатора (10.0.2.1 — core facing interface) был отправлен на CE маршрутизатор (адрес 20.0.0.2) и вернулся обратно на PE-маршрутизатор (20.0.0.1). Как я и сказал, JunOS не сделал ip lookup и просто переслал пакет в интерфейс клиента, а вот уже клиентский маршрутизатор проверил адрес назначения ip пакета и отправил его обратно на PE1 (см рисунок ниже):
То есть в нашем случае маршрутизатор принял пакет с меткой из ядра сети, посмотрел в таблице mpls.0 что необходимо сделать с пакетом, снял метку и отправил в интерфейс в сторону клиента.
Если мы повесим какой-либо фильтр на нашем PE маршрутизаторе на клиентский интерфейс или настроим qos, то ввиду вышесказанного трафик не будет обрабатываться согласно установленным фильтрам.
Повесим на интерфейс в сторону клиента фильтр:
bormoglotx@PE1# show firewall family inet filter To-CE1-2
term 1 {
from {
destination-address {
20.0.0.0/24;
}
}
then {
reject;
}
}
term 2 {
then accept;
}
[edit]
bormoglotx@PE1# show interfaces ge-0/0/3.20
description "to CE1 site 2";
vlan-id 20;
family inet {
filter {
output To-CE1-2;
}
address 20.0.0.1/24;
}
И теперь запустим пинг до сети 20.0.0.0/24 с CE2:
CE2#ping 20.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/69/72 ms
Фильтр есть, но он не работает. Изменим эту ситуацию, включив опцию vrf-table label:
[edit]
bormoglotx@PE1# set routing-instances CE1 vrf-table-label
Попробуем снова запустить пинг до сети 20.0.0.0/24 с CE2:
CE2#ping 20.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.0.2, timeout is 2 seconds:
UUUUU
Success rate is 0 percent (0/5)
Теперь хост недостижим — фильтр отрабатывает. Снимем фильтр и снова запустим пинг для проверки:
[edit]
bormoglotx@PE1# deactivate interfaces ge-0/0/3.20 family inet filter
[edit]
bormoglotx@PE1# show | compare
[edit interfaces ge-0/0/3 unit 20 family inet]
! inactive: filter { ... }
CE2#ping 20.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/88/148 ms
Все отлично. Теперь мы увидели наглядно, какие подводные камни нас ожидают при дефолтном механизме распределения меток vrf в JunOS. Так как выше мы уже дали команду vrf-table-label и деактивировали фильтр, то приступим к обсуждению работы маршрутизатора с включенной опцией vrf-table-label.
Посмотрим маршруты, которые PE1 анонсирует на роутрефлектор:
bormoglotx@PE1> show route advertising-protocol bgp 10.0.10.10
CE1.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.0.0.0/24 Self 100 I
* 10.1.1.1/32 Self 2 100 I
* 20.0.0.0/24 Self 100 I
* 20.1.1.1/32 Self 2 100 I
bormoglotx@PE1> show route advertising-protocol bgp 10.0.10.10 detail
CE1.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
* 10.0.0.0/24 (1 entry, 1 announced)
BGP group RR type Internal
Route Distinguisher: 1:1
VPN Label: 16
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1] I
Communities: target:2:100
* 10.1.1.1/32 (1 entry, 1 announced)
BGP group RR type Internal
Route Distinguisher: 1:1
VPN Label: 16
Nexthop: Self
Flags: Nexthop Change
MED: 2
Localpref: 100
AS path: [1] I
Communities: target:2:100 rte-type:0.0.0.0:1:0
* 20.0.0.0/24 (1 entry, 1 announced)
BGP group RR type Internal
Route Distinguisher: 1:1
VPN Label: 16
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1] I
Communities: target:2:100
* 20.1.1.1/32 (1 entry, 1 announced)
BGP group RR type Internal
Route Distinguisher: 1:1
VPN Label: 16
Nexthop: Self
Flags: Nexthop Change
MED: 2
Localpref: 100
AS path: [1] I
Communities: target:2:100 rte-type:0.0.0.0:1:0
Как видите, теперь у нас только одна метка на все маршруты из vrf CE1:
bormoglotx@PE1> show route advertising-protocol bgp 10.0.10.10 detail | match label
VPN Label: 16
VPN Label: 16
VPN Label: 16
VPN Label: 16
Снова запустим трассировку с CE2 до 20.0.0.1:
CE2#traceroute 20.0.0.1
Type escape sequence to abort.
Tracing the route to 20.0.0.1
1 10.0.1.1 32 msec 16 msec 20 msec
2 10.1.3.2 [MPLS: Labels 20/18/16 Exp 0] 76 msec 48 msec 68 msec
3 10.1.2.1 [MPLS: Labels 18/16 Exp 0] 68 msec 48 msec 56 msec
4 10.2.0.1 [MPLS: Labels 299952/16 Exp 0] 52 msec 48 msec 52 msec
5 10.0.3.2 [MPLS: Labels 299808/16 Exp 0] 52 msec 52 msec 52 msec
6 20.0.0.1 76 msec 52 msec 72 msec
Теперь icmp пакеты не идут петлей через CE1-2.
Сам маршрут на PE1 теперь выглядит несколько иначе:
bormoglotx@PE1> 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:04:23
to table CE1.inet.0, Pop
Говоря обычным языком, при получении пакета с меткой 16 необходимо снять метку и сделать ip lookup в таблице CE1.inet.0. Почему же в Juniper данная функция не реализована при генерации меток per-nex-hop? Дело в архитектуре оборудования Juniper — PFE не может сделать и mpls и ip lookup одновременно. Для реализации двойного lookup-а нам понадобится так называемый Tunnel Services PIC, далее туннельный PIC (интерфейс vt-fpc/pic/port.unit-number ). Вот так выглядит PIC в составе шасси M120:
Примечание: О создании vt-интерфейса и добавлении его в vrf можно почитать тут
Теперь алгоритм обработки пакета будет изменен: маршрутизатор принял пакет с меткой из ядра сети, посмотрел в таблице mpls.0 что необходимо сделать с пакетом, снял метку и отправил в интерфейс vt, далее пакет из vt интерфейса снова попадает на PFE, но уже без метки и PFE может сделать ip lookup (и далее отправить в сторону клиента).
Но необходимость в туннельном PIC накладывает определенные ограничения на использование данной функции. Поэтому, если у вас нет такого PIC, то вы можете дать команду vrf-table-label и JunOS автоматически создает виртуальный интерфейс lsi (label switching interface) (поддерживается платформами ACX, M, MX, T Series), который выполняет точно такую же функцию, что и vt-интерфейс:
bormoglotx@PE1> show interfaces terse | match lsi
lsi up up
lsi.0 up up inet
Данный интерфейс не доступен для конфигурирования. На каждый vrf создается отдельный lsi интерфейс, который ассоциируется с генерируемой для данного vrf меткой. К примеру, создадим еще один vrf и посмотрим, сколько lsi интерфейсов теперь:
bormoglotx@PE1> show configuration routing-instances ?
Possible completions:
<[Enter]> Execute this command
<instance_name> Routing instance name
CE1 Routing instance name
CE2 Routing instance name
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
| Pipe through a command
bormoglotx@PE1> show interfaces terse | match lsi
lsi up up
lsi.0 up up inet
lsi.1 up up inet
Посмотреть какой lsi unit соответствует какой-либо routing instance можно командой: show interfaces lsi routing-instance instance-name, к примеру в нашем случае:
bormoglotx@PE1> show interfaces lsi routing-instance CE1 | match logical
Logical interface lsi.0 (Index 71) (SNMP ifIndex 524)
bormoglotx@PE1> show interfaces lsi routing-instance CE2 | match logical
Logical interface lsi.1 (Index 81) (SNMP ifIndex 525)
Интерфейс lsi создается и для vpls routing-instance (команда no-tunnel-services), трафик в таком случае обрабатывается как описано выше, за исключением того, что vpls оперирует исключительно mac адресами, не зная ничего о клиентских ip адресах, но это уже совсем другая история.
Спасибо за внимание!
Комментарии (0)