Любой инженер, сталкивавшийся с MPLS, знает что метки могут распределяться двумя способами: DU (Downstream Unsolicited) и DD (Downstream On-Demand). В первом случае маршрутизатор начинает генерировать и передавать всем своим LDP соседям метки до префиксов, к которым он является next-hop. Во втором случае LSR будет генерировать метку до префикса и передавать ее только по запросу вышестоящего маршрутизатора. Пример первого случая — протокол LDP, второй случай — RSVP-TE. А как распределяются метки в VPLS? Давайте разберемся.
Для начала что такое VPLS и зачем он нужен. Virtual Private LAN Services — это эмуляция LAN для географически (и не только) распределенных сетей. Между разнесенными сайтами клиента (или элементами дата-центра) создаются виртуальные L2 соединения, в результате чего клиент видит сеть провайдера как подключение к коммутатору (к которому подключены и остальные его сайты):
Картинку взял с сайта inetzero.
Существует две реализации VPLS. Одна реализация предусматривает BGP сигнализацию (драфт Компелла), вторая установление target LDP сессий между PE маршрутизаторами (драфт Мартини).
Во втором случае все просто. Метки распределяются по принципу Downstream Unsolicited с помощью Label mapping сообщений протокола LDP с типом FEC 128 (выделенная строка — сгенерированная метка):
Сложнее понять, как распределяет метки VPLS, использующий BGP как сигнализацию (драфт Компелла). Данная реализация VPLS использует control plane для следующих задач:
1. Автоматический поиск PE-маршрутизаторов, к которым подключены сайты клиента.
2. Распределение MPLS меток для реализации полносвязанной L2 топологии между сайтами клиента.
Для начала необходимо создать на каждом PE-маршрутизаторе, к которому подключены сайты клиента, routing instance с типом VPLS:
Настраиваем BGP сигнализацию. Для данного типа VPLS нам необходимо включить address family l2vpn signaling:
Настраиваем интерфейсы в сторону клиента (к примеру так):
и не забываем увеличить значение MTU на интерфейсах в сторону ядра сети, так называемые core-face интерфейсы.
Теперь можно посмотреть установилось ли наше соединение:
Как видим соединение установлено. На выводе ниже видно, что между маршрутизаторами клиента поднялось OSPF соседство и появились маршруты до лупбеков:
Передаваемые по сети пакеты будут выглядеть следующим образом (какое нужно установить MTU, можете посчитать сами):
Все работает. Теперь посмотрим, какие метки распределены между сайтами:
Нас интересует эта строка вывода:
Incoming label: 262154, Outgoing label: 262145
То есть PE1 для отправки пакета от CE1 к CE2 будет использовать метку 262145, а с меткой 262154 PE1 будет принимать пакеты, идущие от CE2 к CE1. Но как эти метки генерируются и передаются? Разберемся поподробнее. Для этого посмотрим дамп трафика BGP сессии между PE1 и PE2 (сейчас BGP-сессия установлена между пирами, но в реальной жизни в 99 процентах случаев используется роут-рефлекторы):
Первая задача сигнализации решается с помощью всем небезызвестных Route Target и Route Distinguisher. В строке extended community приведенного дампа видно значение RT, как и при L3VPN, оно используется для фильтрации маршрутной информации. Автоматический поиск обязывает данный тип routing-instance иметь сконфигурированное значение RD ( к слову говоря в пределах одного VPLS домена оно может быть одинаковым).
Нам же сейчас необходимо понять как реализован механизм распределения меток. Интерес для нас представляет строка NLRI. В строке указаны несколько значений, но в отличии от L3VPN или VPLS LDP Signaling, нет точного указания на сгенерированную метку. Разберем каждое значение данного поля.
Первые два поля думаю всем понятны:
RD 100:0.0.0.100 — это RD (думаю все знают, что такое RD, и пояснять не надо)
CE-ID — тут указан Site-id, сконфигурированный администраторами сети.
А вот следующие три параметра нам не знакомы. Дело в том, что VPLS (драфт Компелла) распределяет метки не по одной, а блоками по 8 (по умолчанию) меток в блоке. Эти поля как раз и характеризуют распределенный блок меток.
Label-Block Offcet — это сдвиг метки от базы меток;
Label-Block Size — размер блока меток, в JunOS по умолчанию он равен 8 меткам;
Label Base — это база блока меток.
Теперь начинается математика. PE-маршрутизатор, к которому подключен сайт клиента, отправляет всем остальным PE-маршрутизаторам BGP Update сообщение, содержащее:
1. RD
2. CE-ID
3. Label-Block Offcet
4. Label-Block Size
5. Label Base
Так как VPLS это набор LSP, вложенных в другие LSP, то нам нужно знать:
1. С какой меткой отправить пакет на какой либо сайт
2. От какого сайта прилетел пакет с указанной меткой
PE-маршрутизатор, получив указанное выше BGP Upgrade сообщение производит следующие операции. используя полученные от соседа данные:
Outgoing Label = Label Base удаленного сайта — Label-Block Offcet удаленного сайта + свой Site ID
В нашем случае PE2 произведет следующие операции: значение базы 262153, отнимает от этого значение сдвиг меток (у нас 1) и прибавляет к этому значению свой Site-ID. Это и будет являться исходящей меткой до сайта, от которого данное BGP Update сообщение пришло:
Получаем, что-бы от сайта CE2 добраться до сайта CE1, PE2 должен отправить пакет с меткой: 262153(база)-1(сдвиг)+2(site-id)=262154. Смотрим вывод:
Все верно, исходящая метка 262154. Теперь, PE1, получая пакет с указанной меткой 262154, знает, что этот пакет отправлен с PE2 сайта CE2.
Входящая метка рассчитывается точно так же, только значение базы и сдвиг берутся свои собственные (сгенерированные нами для других PE маршрутизаторов), а как идентификатор сайта используется site-id необходимого PE маршрутизатора:
Incoming label = свой Label Base — свой Label-Block Offcet+ Site ID удаленного сайта
Давайте изменим конфигурацию и произведем расчет еще раз. Теперь у нас максимальное количество сайтов 10, а наши сайты имеют идентификаторы 9 (CE1) и 6 (CE2) (остальные 8 сайтов нет смысла конфигурировать для понимания принципа, так как вычисления будут те же, но их станет больше). Попробуем снова рассчитать значение меток. Посмотрим на дампы трафика:
От PE1 к PE2:
От PE2 к PE1:
Мы имеем такие данные.
От PE1:
RD 100:0.0.0.100
CE-ID 9
Label-Block Offcet 1
Label-Block Size 8
Label Base 262169
От PE2:
RD 200:0.0.0.200
CE-ID 6
Label-Block Offcet 1
Label-Block Size 8
Label Base 262153
Теперь рассчитаем, какие входящие и исходящие метки должны быть у сайтов.
PE1 (сайт 9):
Входящая метка от сайта 6: 262169-1+6=174
Исходящая метка к сайту 6: 262153-1+9=161
PE2 (сайт 6):
Входящая метка от сайта 9: 262153-1+9=161
Исходящая метка к сайту 9: 262169-1+6=174
И проверим произведенные расчеты:
На PE1:
На PE2:
Как видите мы рассчитали все верно.
Если вы еще не поняли как работает данный механизм, прошув веселые картинки под спойлер
Хочу добавить, что если у клиента будет например 10 или 12 сайтов, то нам нужен не один стандартный блок меток, а два. Поэтому в сообщение BGP Update может быть несколько значений сдвига меток и базы:
И еще одно дополнение — JunOS по умолчанию использует блок из 8 меток, даже если вам надо соединить всего два или три сайта. Но с помощью команды set label-block-size можно изменить количество меток в блоке. JunOS поддерживает 2, 4, 8 или 16 меток в блоке. Но надо учитывать, что если вы измените данное значение на уже работающем VPLS домене, то все установленные в данном VPLS домене соединения будут разорваны и установлены заново, с новыми параметрами.
Для начала что такое VPLS и зачем он нужен. Virtual Private LAN Services — это эмуляция LAN для географически (и не только) распределенных сетей. Между разнесенными сайтами клиента (или элементами дата-центра) создаются виртуальные L2 соединения, в результате чего клиент видит сеть провайдера как подключение к коммутатору (к которому подключены и остальные его сайты):
Картинку взял с сайта inetzero.
Существует две реализации VPLS. Одна реализация предусматривает BGP сигнализацию (драфт Компелла), вторая установление target LDP сессий между PE маршрутизаторами (драфт Мартини).
Во втором случае все просто. Метки распределяются по принципу Downstream Unsolicited с помощью Label mapping сообщений протокола LDP с типом FEC 128 (выделенная строка — сгенерированная метка):
Сложнее понять, как распределяет метки VPLS, использующий BGP как сигнализацию (драфт Компелла). Данная реализация VPLS использует control plane для следующих задач:
1. Автоматический поиск PE-маршрутизаторов, к которым подключены сайты клиента.
2. Распределение MPLS меток для реализации полносвязанной L2 топологии между сайтами клиента.
Для начала необходимо создать на каждом PE-маршрутизаторе, к которому подключены сайты клиента, routing instance с типом VPLS:
routing-instances {
vpls-bgp-cutomer1 {
instance-type vpls;
interface ge-0/0/1.0;
route-distinguisher 100:100;
vrf-target {
import target:1:1;
export target:2:2;
}
protocols {
vpls {
site-range 5;
no-tunnel-services;
site ce1 {
site-identifier 1;
}
}
}
}
}
Настраиваем BGP сигнализацию. Для данного типа VPLS нам необходимо включить address family l2vpn signaling:
root# show protocols bgp
group internal {
type internal;
local-address 10.1.1.1;
family l2vpn {
signaling;
}
neighbor 10.3.3.3;
}
Настраиваем интерфейсы в сторону клиента (к примеру так):
root# show interfaces ge-0/0/1
vlan-tagging;
encapsulation vlan-vpls;
unit 0 {
encapsulation vlan-vpls;
vlan-id 512;
family vpls;
}
и не забываем увеличить значение MTU на интерфейсах в сторону ядра сети, так называемые core-face интерфейсы.
Теперь можно посмотреть установилось ли наше соединение:
root# run show vpls connections
Layer-2 VPN connections:
Legend for connection status (St)
EI -- encapsulation invalid NC -- interface encapsulation not CCC/TCC/VPLS
EM -- encapsulation mismatch WE -- interface and instance encaps not same
VC-Dn -- Virtual circuit down NP -- interface hardware not present
CM -- control-word mismatch -> -- only outbound connection is up
CN -- circuit not provisioned <- -- only inbound connection is up
OR -- out of range Up -- operational
OL -- no outgoing label Dn -- down
LD -- local site signaled down CF -- call admission control failure
RD -- remote site signaled down SC -- local and remote site ID collision
LN -- local site not designated LM -- local site ID not minimum designated
RN -- remote site not designated RM -- remote site ID not minimum designated
XX -- unknown connection status IL -- no incoming label
MM -- MTU mismatch MI -- Mesh-Group ID not available
BK -- Backup connection ST -- Standby connection
PF -- Profile parse failure PB -- Profile busy
RS -- remote site standby SN -- Static Neighbor
VM -- VLAN ID mismatch
Legend for interface status
Up -- operational
Dn -- down
Instance: vpls-bgp-cutomer1
Local site: ce1 (1)
connection-site Type St Time last up # Up trans
2 rmt Up Jan 16 20:50:51 2016 1
Remote PE: 10.3.3.3, Negotiated control-word: No
Incoming label: 262154, Outgoing label: 262145
Local interface: lsi.1048832, Status: Up, Encapsulation: VPLS
Description: Intf - vpls vpls-bgp-cutomer1 local site 1 remote site 2
Как видим соединение установлено. На выводе ниже видно, что между маршрутизаторами клиента поднялось OSPF соседство и появились маршруты до лупбеков:
R7(config)#
*Jan 16 16:52:54.554: %OSPF-5-ADJCHG: Process 1, Nbr 20.1.1.1 on GigabitEthernet1/0.512 from LOADING to FULL, Loading Done
R7(config)#sh
R7(config)#do sh ip rou
R7(config)#do sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
100.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 100.0.0.0/24 is directly connected, GigabitEthernet1/0.512
L 100.0.0.2/32 is directly connected, GigabitEthernet1/0.512
O 100.1.1.1/32 [110/2] via 100.0.0.1, 00:00:54, GigabitEthernet1/0.512
C 100.1.1.2/32 is directly connected, Loopback0
R7(config)#do ping 100.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/40/88 ms
Передаваемые по сети пакеты будут выглядеть следующим образом (какое нужно установить MTU, можете посчитать сами):
Все работает. Теперь посмотрим, какие метки распределены между сайтами:
Instance: vpls-bgp-cutomer1
Local site: ce1 (1)
connection-site Type St Time last up # Up trans
2 rmt Up Jan 16 20:50:51 2016 1
Remote PE: 10.3.3.3, Negotiated control-word: No
Incoming label: 262154, Outgoing label: 262145
Local interface: lsi.1048832, Status: Up, Encapsulation: VPLS
Description: Intf - vpls vpls-bgp-cutomer1 local site 1 remote site 2
Instance: vpls-bgp-customer1
Local site: ce2 (2)
connection-site Type St Time last up # Up trans
1 rmt Up Jan 16 20:50:49 2016 1
Remote PE: 10.1.1.1, Negotiated control-word: No
Incoming label: 262145, Outgoing label: 262154
Local interface: lsi.1048576, Status: Up, Encapsulation: VPLS
Description: Intf - vpls vpls-bgp-customer1 local site 2 remote site 1
Нас интересует эта строка вывода:
Incoming label: 262154, Outgoing label: 262145
То есть PE1 для отправки пакета от CE1 к CE2 будет использовать метку 262145, а с меткой 262154 PE1 будет принимать пакеты, идущие от CE2 к CE1. Но как эти метки генерируются и передаются? Разберемся поподробнее. Для этого посмотрим дамп трафика BGP сессии между PE1 и PE2 (сейчас BGP-сессия установлена между пирами, но в реальной жизни в 99 процентах случаев используется роут-рефлекторы):
Первая задача сигнализации решается с помощью всем небезызвестных Route Target и Route Distinguisher. В строке extended community приведенного дампа видно значение RT, как и при L3VPN, оно используется для фильтрации маршрутной информации. Автоматический поиск обязывает данный тип routing-instance иметь сконфигурированное значение RD ( к слову говоря в пределах одного VPLS домена оно может быть одинаковым).
Нам же сейчас необходимо понять как реализован механизм распределения меток. Интерес для нас представляет строка NLRI. В строке указаны несколько значений, но в отличии от L3VPN или VPLS LDP Signaling, нет точного указания на сгенерированную метку. Разберем каждое значение данного поля.
Первые два поля думаю всем понятны:
RD 100:0.0.0.100 — это RD (думаю все знают, что такое RD, и пояснять не надо)
CE-ID — тут указан Site-id, сконфигурированный администраторами сети.
А вот следующие три параметра нам не знакомы. Дело в том, что VPLS (драфт Компелла) распределяет метки не по одной, а блоками по 8 (по умолчанию) меток в блоке. Эти поля как раз и характеризуют распределенный блок меток.
Label-Block Offcet — это сдвиг метки от базы меток;
Label-Block Size — размер блока меток, в JunOS по умолчанию он равен 8 меткам;
Label Base — это база блока меток.
Теперь начинается математика. PE-маршрутизатор, к которому подключен сайт клиента, отправляет всем остальным PE-маршрутизаторам BGP Update сообщение, содержащее:
1. RD
2. CE-ID
3. Label-Block Offcet
4. Label-Block Size
5. Label Base
Так как VPLS это набор LSP, вложенных в другие LSP, то нам нужно знать:
1. С какой меткой отправить пакет на какой либо сайт
2. От какого сайта прилетел пакет с указанной меткой
PE-маршрутизатор, получив указанное выше BGP Upgrade сообщение производит следующие операции. используя полученные от соседа данные:
Outgoing Label = Label Base удаленного сайта — Label-Block Offcet удаленного сайта + свой Site ID
В нашем случае PE2 произведет следующие операции: значение базы 262153, отнимает от этого значение сдвиг меток (у нас 1) и прибавляет к этому значению свой Site-ID. Это и будет являться исходящей меткой до сайта, от которого данное BGP Update сообщение пришло:
Получаем, что-бы от сайта CE2 добраться до сайта CE1, PE2 должен отправить пакет с меткой: 262153(база)-1(сдвиг)+2(site-id)=262154. Смотрим вывод:
Instance: vpls-bgp-customer1
Local site: ce2 (2)
connection-site Type St Time last up # Up trans
1 rmt Up Jan 16 20:50:49 2016 1
Remote PE: 10.1.1.1, Negotiated control-word: No
Incoming label: 262145, Outgoing label: 262154
Local interface: lsi.1048576, Status: Up, Encapsulation: VPLS
Description: Intf - vpls vpls-bgp-customer1 local site 2 remote site 1
Все верно, исходящая метка 262154. Теперь, PE1, получая пакет с указанной меткой 262154, знает, что этот пакет отправлен с PE2 сайта CE2.
Входящая метка рассчитывается точно так же, только значение базы и сдвиг берутся свои собственные (сгенерированные нами для других PE маршрутизаторов), а как идентификатор сайта используется site-id необходимого PE маршрутизатора:
Incoming label = свой Label Base — свой Label-Block Offcet+ Site ID удаленного сайта
Давайте изменим конфигурацию и произведем расчет еще раз. Теперь у нас максимальное количество сайтов 10, а наши сайты имеют идентификаторы 9 (CE1) и 6 (CE2) (остальные 8 сайтов нет смысла конфигурировать для понимания принципа, так как вычисления будут те же, но их станет больше). Попробуем снова рассчитать значение меток. Посмотрим на дампы трафика:
От PE1 к PE2:
От PE2 к PE1:
Мы имеем такие данные.
От PE1:
RD 100:0.0.0.100
CE-ID 9
Label-Block Offcet 1
Label-Block Size 8
Label Base 262169
От PE2:
RD 200:0.0.0.200
CE-ID 6
Label-Block Offcet 1
Label-Block Size 8
Label Base 262153
Теперь рассчитаем, какие входящие и исходящие метки должны быть у сайтов.
PE1 (сайт 9):
Входящая метка от сайта 6: 262169-1+6=174
Исходящая метка к сайту 6: 262153-1+9=161
PE2 (сайт 6):
Входящая метка от сайта 9: 262153-1+9=161
Исходящая метка к сайту 9: 262169-1+6=174
И проверим произведенные расчеты:
На PE1:
Instance: vpls-bgp-cutomer1
Local site: ce1 (9)
connection-site Type St Time last up # Up trans
6 rmt Up Jan 16 21:10:58 2016 1
Remote PE: 10.3.3.3, Negotiated control-word: No
Incoming label: 262174, Outgoing label: 262161
Local interface: lsi.1048833, Status: Up, Encapsulation: VPLS
Description: Intf - vpls vpls-bgp-cutomer1 local site 9 remote site 6
На PE2:
Instance: vpls-bgp-customer1
Local site: ce2 (6)
connection-site Type St Time last up # Up trans
9 rmt Up Jan 16 21:10:53 2016 1
Remote PE: 10.1.1.1, Negotiated control-word: No
Incoming label: 262161, Outgoing label: 262174
Local interface: lsi.1048577, Status: Up, Encapsulation: VPLS
Description: Intf - vpls vpls-bgp-customer1 local site 6 remote site 9
Как видите мы рассчитали все верно.
Если вы еще не поняли как работает данный механизм, прошу
в картинках
Рассмотрим данную топологию:
VPLS создаст полносвязанную топологию между всеми тремя сайтами клиента:
PE1 отправляет на PE2 и PE3 BGP Update сообщения с указанными на иллюстрации данными:
PE2 и PE3 по формуле высчитывают значения исходящих меток до PE1, а PE1 просчитывает входящие метки от PE2 и PE3:
Следующие изображения иллюстрируют описанный выше процесс на PE2:
И на PE3:
В итоге на всех PE-маршрутизаторах есть и входящие и исходящие метки для всех сайтов:
VPLS создаст полносвязанную топологию между всеми тремя сайтами клиента:
PE1 отправляет на PE2 и PE3 BGP Update сообщения с указанными на иллюстрации данными:
PE2 и PE3 по формуле высчитывают значения исходящих меток до PE1, а PE1 просчитывает входящие метки от PE2 и PE3:
Следующие изображения иллюстрируют описанный выше процесс на PE2:
И на PE3:
В итоге на всех PE-маршрутизаторах есть и входящие и исходящие метки для всех сайтов:
Хочу добавить, что если у клиента будет например 10 или 12 сайтов, то нам нужен не один стандартный блок меток, а два. Поэтому в сообщение BGP Update может быть несколько значений сдвига меток и базы:
И еще одно дополнение — JunOS по умолчанию использует блок из 8 меток, даже если вам надо соединить всего два или три сайта. Но с помощью команды set label-block-size можно изменить количество меток в блоке. JunOS поддерживает 2, 4, 8 или 16 меток в блоке. Но надо учитывать, что если вы измените данное значение на уже работающем VPLS домене, то все установленные в данном VPLS домене соединения будут разорваны и установлены заново, с новыми параметрами.
