Как работает MPLS VPN

Всем привет. Сегодня наш разговор пойдет о такой технологии, как MPLS VPN. В предыдущей статье сеть была  этой технологии. Я демонстрировал, как защищаться от флуда маршрутов со стороны клиента. В этой статье мы разберем, как работает сама сеть.

Я немного отступлю от обычной схемы своего повествования. Мой рассказ будет о том, что происходит в сети. А как что конфигурируется, можно прочитать в конфиге в конце статьи, да и в интернете масса примеров. Но вот что в интернете очень сложно найти, так это поэтапное описания, как такая сеть работает, какие этапы проходит пакет, почему не нужно организовывать туннели и самое главное, как проверить все ли правильно.

Итак, что же это такое мультипротокольная коммутация по меткам и почему она лучше маршрутизации? Основная суть заключается в том, что между  заголовками канального и сетевого уровней (а в некоторых стандартах вроде Frame Relay или ATM в заголовок канального уровня) маршрутизатором PE (Provider Edge) вставляется метка и этот пакет пересылается следующему маршрутизатору MPLS или, как его еще называют, LSR (Label Switch Router). Получив такой пакет, LSR читает метку и в соответствии с таблицей меняет текущую метку на метку следующего прыжка в направлении  пункта назначения и отправляет пакет в нужный интерфейс, который также записан в таблице.

В чем же выигрыш? С первого взгляда процесс мало отличается от маршрутизации, так же изучается таблица, меняются MAC-адреса и пакет следует дальше. Зачем было городить огород и делать еще одну таблицу?

А вся соль в том, что нет никакого изучения таблицы меток. LSR сразу обращается к записи, порядковый номер которой в таблице равен значению метки. В результате достигается очень высокая скорость обработки потока пакетов. Почти так же быстро, как коммутация второго уровня. Почти, потому что заголовок второго уровня надо менять все-таки и производить все связные с этим операции. Еще одно относительно узкое место — PE маршрутизаторы, которым теперь не только таблицу маршрутизации изучать нужно при пересылке пакетов, но еще и таблицу меток. Таким образом, выигрывая в производительности в одном месте, теряем в другом. Но зато выигрыш в ядре сети очень существенный, что и обусловило популярность MPLS у провайдеров.

Давайте теперь перейдем ближе к делу и посмотрим на практике, как это работает. Для демонстрации замены меток в процессе передачи пакетов добавим к нашей предыдущей схеме еще два маршрутизатора. Зачем — будет понятно в процессе. Вот так теперь выглядит наша сеть.

MPLS_VPN_Logic

Итак, у нас здесь есть CE маршрутизаторы D_apad и D_Vostok, подключенные к PE маршрутизаторам Zapad и Vostok. Маршрутизаторы Yug1,2 и Sever1,2 изображают ядро сети провайдера. Подключение клиентов организовано с использование BGP (это не очень важно), а внутри сети провайдера маршрутизация осуществляется с использованием OSPF (это важно, совместно с LDP может работать только IGP). Ну и наконец, для распространения меток используется LDP.

Немного о распространении меток. Метки назначаются на PE маршрутизаторах сетям записанным таблице маршрутизации. Просто назначаются по порядку, начиная с 16 (почему с 16 не составит труда найти в интернете). Затем, с использованием LDP в данном случае, информация о назначенных метках передается на соседние маршрутизаторы, которые в свою очередь назначают свои метки для подсетей, переданных PE маршрутизаторами и передают их дальше уже с новыми метками. И так далее, и так далее. С первого раза может непонятно. Прошу набраться терпения, в процессе рассказа все станет ясно.

Посмотрим на таблицу меток на маршрутизаторе Zapad.

Zapad#sh mpls forwarding-table
Local     Outgoing   Prefix           Bytes Label  Outgoing   Next Hop
Label     Label      or Tunnel Id     Switched     interface
16        Pop Label  192.168.0.6/32   0            Et1/2      10.100.3.1
17        Pop Label  10.100.6.0/30    0            Et1/2      10.100.3.1
18        16         192.168.0.4/32   0            Et1/2      10.100.3.1
19        18         192.168.0.3/32   0            Et1/1      10.100.1.1
21        192.168.0.3/32              0            Et1/2      10.100.3.1
20        24         10.100.2.0/30    0            Et1/1      10.100.1.1
21        19         10.100.4.0/30    0            Et1/2      10.100.3.1
22        No Label   10.1.10.0/30[V]  0            aggregate/Zapad
23        No Label   192.168.10.1/32[V]   \
                                     1140          Et1/0      10.1.10.2
24        19         192.168.0.2/32   0            Et1/1      10.100.1.1
25        Pop Label  10.100.5.0/30    0            Et1/1      10.100.1.1
26        Pop Label  192.168.0.5/32   0            Et1/1      10.100.1.1

Итак, что мыздесь видим. Первый столбец Local Label это и есть список меток, который присвоил маршрутизато подсетям из таблицы маршрутизации, и по этому столбцу будут происходить обращения к таблице, когда маршрутизатор получит MPLS пакет.

Второй столбец – исходящая метка. Это та метка, которая будет присвоена пакету, отправляемому в MPLS сеть. Pop Label обозначает, что MPLS заголовок будет вырезан, а пакет  будет отправлен узлу указанному как Next Hop, который будет принимать решение о его дальнейшей пересылке с  использованием уже обычной маршрутизацией. No Label в данном случае означает, что MPLS на соответствующих интерфейсах не включен. И в самом деле, обе подсети, у которых стоит No Label относятся к vrf Zapad, а там ни на одном интерфейсе MPLS не включен.

Давайте теперь посмотрим, какие приключения ожидают пакет в процессе путешествия по сети. Для этого мы пропингуем интерфейс lo0 на маршрутизаторе D_Vostok от имени интерфейса lo0 на маршрутизаторе D_Zapad. Посмотрим, что нам покажет WireShark и расспросим маршрутизаторы, не врет ли он нам.

Поехали.

D_Zapad#ping 192.168.20.1 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 92/108/120 ms

Все в порядке, сеть работает, пакеты бегают. Смотрим, что показывает наш снифер.

01_D_Z--Z

От маршрутизатора D_Zapad к маршрутизатору Zapad бежит совершенно обычный кадр Ethernet с IPv4 пакетом. Смотрим дальше. Линк между Zapad и Yug_1.

 02_Z--Y1

И здесь мы видим интересную вещь. Вместо одного заголовка MPLS мы видим два. Как же так получилось? Идем на маршрутизатор Zapad и смотрим, что он по этому поводу может пояснить. Сначала проверяем таблицу маршрутизации vrf Zapad, так как интерфейс, на котором мы получаем наш пакет, принадлежит именно этому виртуальному маршрутизатору.

Zapad#sh ip route vrf Zapad | beg Gat
 Gateway of last resort is not set
 10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
 C        10.1.10.0/30 is directly connected, Ethernet1/0
 L        10.1.10.1/32 is directly connected, Ethernet1/0
 B        10.2.10.0/30 [200/0] via 192.168.0.3, 02:32:28
 192.168.10.0/32 is subnetted, 1 subnets
 B        192.168.10.1 [20/0] via 10.1.10.2, 02:57:22
 192.168.20.0/32 is subnetted, 2 subnets
 B        192.168.20.1 [200/0] via 192.168.0.3, 02:32:28
 B        192.168.20.2 [200/0] via 192.168.0.3, 02:32:28

Итак, здесь мы видим, что наша сеть назначения 192.168.20.1/32 находится за узлом 192.168.0.3, но вот маршрута к этому узлу здесь нет. Где же его искать? Поскольку у нас включен MPLS, будем проверять таблицу передачи MPLS.

Zapad#sh mpls forwarding-table
Local     Outgoing   Prefix           Bytes Label  Outgoing   Next Hop
Label     Label      or Tunnel Id     Switched     interface
16        Pop Label  192.168.0.6/32   0            Et1/2      10.100.3.1
17        Pop Label  10.100.6.0/30    0            Et1/2      10.100.3.1
18        16         192.168.0.4/32   0            Et1/2      10.100.3.1
19        18         192.168.0.3/32   0            Et1/1      10.100.1.1
          21         192.168.0.3/32   0            Et1/2      10.100.3.1
20        24         10.100.2.0/30    0            Et1/1      10.100.1.1
21        19         10.100.4.0/30    0            Et1/2      10.100.3.1
22        No Label   10.1.10.0/30[V]  0            aggregate/Zapad
23        No Label   192.168.10.1/32[V]   \
                                      1140         Et1/0      10.1.10.2
24        19         192.168.0.2/32   0            Et1/1      10.100.1.1
25        Pop Label  10.100.5.0/30    0            Et1/1      10.100.1.1
26        Pop Label  192.168.0.5/32   0            Et1/1      10.100.1.1

И здесь мы уже видим, что для отправки пакета к узлу 192.168.0.3 нужно присвоить этому пакету метку 18 и отправить его через интерфейс Et1/1 узлу 10.100.1.1 либо присвоить метку 21 и через интерфейс Et1/2 отправить узлу 10.100.3.1. Именно это и показывает нам WireShark. В первом заголовке MPLS указана метка 21, а MAC адрес назначения соответствует узлу 10.100.3.1

Zapad#sh arp 10.100.3.1
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.100.3.1             98   ca02.1544.001c  ARPA   Ethernet1/2

Хорошо. Здесь разобрались. Но откуда взялся второй MPLS заголовок с меткой 24? Метка 24 есть, но она указывает на узел 192.168.0.2, а о нем никакого разговора и упоминания не было.

Здесь нужно вспомнить заголовок статьи, что у нас не только MPLS, но еще и VPN. То есть, раз есть два заголовка одного протокола, значит есть туннелирование, т.е. сеть в сети. И действительно, vrf для клиентов организуется именно для этого – сделать сеть в сети.

Тут читатель может задать резонный вопрос. Мы же MPLS на виртуальных маршрутизаторах не конфигурировали. Логичнее было бы увидеть IP туннелирование. Откуда берется MPLS?

Здесь речь идет об одном из расширений протокола BGP – Multiprotocol BGP или MP-BGP. В конфиге bgp-процесса на маршрутизаторе Zapad есть такая секция:

!
address-family vpnv4
 neighbor 192.168.0.3 activate
 neighbor 192.168.0.3 send-community extended
exit-address-family
!

Аналогичная есть и на маршрутизаторе Vostok. Именно эта секция отвечает за включение MP-BGP между маршрутизаторами Zapad и Vostok и передачу маршрутов между vrf  на этих маршрутизаторах. Как это работает, лучше всего проиллюстрирует debug bgp update. Для появления апдейта выключим и включим lo1 на D_Vostok.

Zapad#
*Mar 16 17:40:02.695: BGP(4): 192.168.0.3 rcvd UPDATE w/ attr: nexthop 
192.168.0.3, origin i, localpref 100, metric 0, merged path 31, AS_PATH , 
extended community RT:1:1000
*Mar 16 17:40:02.711: BGP(4): 192.168.0.3 rcvd 1:100:192.168.20.2/32, 
label 29
*Mar 16 17:40:02.743: BGP(4): Revise route installing 1 of 1 routes for 
192.168.20.2/32 -> 192.168.0.3(Zapad) to Zapad IP table
*Mar 16 17:40:02.763: BGP(0): 10.1.10.2 send UPDATE (format) 192.168.20.2/32, 
next 10.1.10.1, metric 0, path 31, extended community RT:1:1000

В этом выводе мы видим, что в рамках расширенного сообщества (а проще VPN сети) RT:1:1000 (это тот самый, который мы создавали командами import и export) получено обновление с новым маршрутом к подсети 192.168.20.2/32, которая относится к RD 1:100 и его метка (этого маршрута) 29. Список всех таких маршрутов с соответствующими им метками:

Zapad#sh bgp vrf Zapad all labels
For address family: VPNv4 Unicast
Network          Next Hop      In label/Out label
Route Distinguisher: 1:100 (Zapad)
10.1.10.0/30     0.0.0.0         22/nolabel(Zapad)
10.2.10.0/30     192.168.0.3     nolabel/23
192.168.10.1/32  10.1.10.2       23/nolabel
192.168.20.1/32  192.168.0.3     nolabel/24
192.168.20.2/32  192.168.0.3     nolabel/29

Теперь видно, откуда взялся второй (а если быть точным, то первый) заголовок MPLS.

Посмотрим, как пакеты с метками дальше путешествуют по сети. Вот пакет между маршрутизаторами Yug_1 и Yug_2:

03_Y1--Y2

Мы видим, что поменялся Ethernet заголовок (естественно) и поменялась верхняя метка с одновременным уменьшением TTL. Что нам по этому поводу скажет маршрутизатор Yug_1:

Yug_1#sh mpls forw
Local     Outgoing   Prefix           Bytes Label  Outgoing   Next Hop
Label     Label      or Tunnel Id     Switched     interface
16        Pop Label  192.168.0.4/32   0            Et1/1      10.100.6.1
17        Pop Label  192.168.0.1/32   2276         Et1/0      10.100.3.2
18        Pop Label  10.0.0.1/32      0            Et1/0      10.100.3.2
19        Pop Label  10.100.4.0/30    0            Et1/1      10.100.6.1
20        Pop Label  10.100.1.0/30    0            Et1/0      10.100.3.2
21        18         192.168.0.3/32   15707        Et1/1      10.100.6.1
22        22         10.100.2.0/30    0            Et1/1      10.100.6.1
23        24         192.168.0.2/32   0            Et1/0      10.100.3.2
          23         192.168.0.2/32   0            Et1/1      10.100.6.1
24        25         10.100.5.0/30    0            Et1/0      10.100.3.2
25        26         192.168.0.5/32   0            Et1/0      10.100.3.2

Все верно. Все пакеты с меткой 21 должны получить метку 18 и отправлены узлу 10.100.6.1 через интерфейс Et1/1. Т.е. мы видим, что MPLS метка имеет локальное значение, только для данного маршрутизатора. Действительно, если мы глянем на таблицу пересылки маршрутизатора Zapad, то там мы тоже найдем метку 21. Только указывать она будет на совсем другую подсеть.

Но пока мы тут разглагольствуем, наш пакет уже побежал дальше и прошел маршрутизатор Yug_2. Посмотрим, что с ним произошло.

04_Y2--V

Здесь мы видим, что остался только один заголовок MPLS. Проверяем таблицу передачи на маршрутизаторе Yug_2.

Yug_2#sh mpls forw
 Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
 Label      Label      or Tunnel Id     Switched      interface
 16         Pop Label  192.168.0.6/32   0             Et1/0      10.100.6.2
 17         Pop Label  10.100.3.0/30    0             Et1/0      10.100.6.2
 18         Pop Label  192.168.0.3/32   2039          Et1/1      10.100.4.2
 19         19         192.168.0.1/32   961           Et1/0      10.100.6.2
 20         20         10.0.0.1/32      0             Et1/0      10.100.6.2
 21         Pop Label  10.100.2.0/30    0             Et1/1      10.100.4.2
 22         22         10.100.1.0/30    0             Et1/0      10.100.6.2
 23         23         192.168.0.5/32   0             Et1/1      10.100.4.2
            23         192.168.0.5/32   0             Et1/0      10.100.6.2
 24         24         192.168.0.2/32   0             Et1/1      10.100.4.2
 25         25         10.100.5.0/30    0             Et1/1      10.100.4.2

Действительно,  если попадается пакет в меткой 18, то эту метку нужно вырезать. Но как же так, ведь Yug_2 еще не PE маршрутизатор. Почему же метка вырезается здесь?

А происходит просто разделение нагрузки. Подсеть 192.168.0.3/32 это уже следующий маршрутизатор (это сообщил OSPF), и получается, что если на него придет пакет с меткой, придется выполнять двойную работу: и по MPLS таблице обработать, и по таблице маршрутизации. Зачем это делать, если метку может вырезать предыдущий маршрутизатор, а пакет все равно отправить по назначению с использованием соответствующего заголовка Ethernet кадра.

Именно это мы и наблюдаем. Метка вырезана, пакет отправлен узлу 10.100.4.2 через интерфейс Et1/1.

Что же будет делать с этим пакетом маршрутизатор Vostok? Смотрим таблицу передачи:

Vostok#sh mpls forw
 Local     Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
 Label     Label      or Tunnel Id     Switched      interface
 16        16         192.168.0.6/32   0             Et1/1      10.100.4.1
 17        Pop Label  192.168.0.4/32   0             Et1/1      10.100.4.1
 18        17         10.100.3.0/30    0             Et1/1      10.100.4.1
 19        Pop Label  10.100.6.0/30    0             Et1/1      10.100.4.1
 20        20         192.168.0.1/32   0             Et1/1      10.100.4.1
 21        21         10.0.0.1/32      0             Et1/1      10.100.4.1
 22        22         10.100.1.0/30    0             Et1/1      10.100.4.1
 23        No Label   10.2.10.0/30[V]  0             aggregate/Vostok
 24        No Label   192.168.20.1/32[V]   \
                                       0             Et1/2      10.2.10.2
 25        No Label   192.168.20.2/32[V]   \
                                       0             Et1/2      10.2.10.2
 26        23         192.168.0.5/32   760           Et1/1      10.100.4.1
 27        Pop Label  192.168.0.2/32   800           Et1/0      10.100.2.1
 28        Pop Label  10.100.5.0/30    0             Et1/0      10.100.2.1

Метка 24 как раз и указывает нам, куда нужно отправлять пакет. В данном случае не нужно никакое промежуточное действие, связанное с тем, что интерфейс Et1/2 принадлежит к vrf. Точно так же мы можем, например, задать статический маршрут с указанием интерфейса. Независимо от принадлежности указанного интерфейса к какому-либо vrf, пакет будет передан. То же правило справедливо и для таблицы MPLS.

Проверяем, как выглядит пакет после маршрутизатора Vostok:

05_V--D_V

Ну вот, как и ожидалось, обычный icmp пакет безо всяких дополнений.

На этом приключения данного icmp-запроса заканчиваются, а у вас, я надеюсь, добавилось понимания, как работает MPLS VPN.

Аверьянов Кирилл
network-lab.ru

Как всегда, конфиги:D_Vostok D_Zapad Sever_1 Sever_2 Vostok Yug_1 Yug_2 Zapad


Комментарии:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Hide me
Получать регулярно свежие материалы, лабораторные и вебинары
Email Имя
Show me