+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

MPLS BGP VPNv4 с OSPF между PE и CPE

MPLS BGP VPNv4 с OSPF между PE и CPE, RouterOS

lillis

Guest

04.07.2016 16:40:00

Привет! Недавно начал экспериментировать с VPNv4 и VRF на Mikrotik, настраивая несколько маршрутизаторов P, PE и CPE. Вот как выглядит моя схема

Я настроил следующее:
- OSPF как IGP в MPLS ядре (P1, P2, PE1 и PE2)
- MPLS на всех интерфейсах, не выходящих к клиентам (P1, P2, PE1 и PE2)
- P1 как BGP route reflector с семейством адресов VPNv4, который затем устанавливает пира с PE1 и PE2
- VRF на интерфейсах PE1 и PE2, смотрящих в сторону клиента (RD 1:1, импорт 1:1, экспорт 1:1)
- OSPF на VRF-интерфейсах с перераспределением BGP-маршрутов (VPNv4)
- OSPF на CPE1-1 и CPE1-2

Я вижу, что маршруты появляются на каждом CPE, и они могут пинговать внутренние сети друг друга (192.168.10.1 и 192.168.20.1). Сначала, когда я делал traceroute между CPE1-1 и CPE1-2, первые 4 прыжка не проходили, а на 5-м доходил (propagate TTL включён).

[admin@CPE1-1] > tool trace 192.168.20.1
ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS
1 100% 6 timeout
2 100% 6 timeout
3 100% 6 timeout
4 100% 5 timeout
5 192.168.20.1 0% 5 8.8ms 7 3.8 8.8 1.9

Потребовалось время, чтобы понять, что клиентские сети на PE1 и PE2 (10.12.0.0/24 и 10.56.0.0/24) не находятся в основной таблице маршрутизации, а лежат в таблицах VRF, и из-за этого lookup на обоих PE не проходил. Я добавил статические маршруты для этих сетей в основную таблицу каждого PE, и теперь вижу маршрутизаторы PE в traceroute.

[admin@CPE1-1] > tool trace 192.168.20.1
ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS
1 10.12.0.2 0% 2 3ms 2.1 1.2 3 0.9
2 100% 2 timeout
3 100% 1 timeout
4 10.45.0.5 0% 1 7.3ms 7.3 7.3 7.3 0
5 192.168.20.1 0% 1 10.6ms 10.6 10.6 10.6 0

Правильно ли добавлять статические маршруты именно так? Как видите, два прыжка всё ещё не проходят. Наверное, это те участки, где идёт трафик через моё MPLS ядро? Почему они не проходят, и почему клиент не видит MPLS-метки?

Если я делаю traceroute с выключенным propagate TTL, эти два прыжка просто исчезают, как видно ниже:

[admin@CPE1-1] > tool trace 192.168.20.1
ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS
1 10.12.0.2 0% 3 1ms 1.3 1 1.6 0.2
2 10.45.0.5 0% 3 3.9ms 4.1 3.9 4.2 0.1
3 192.168.20.1 0% 3 6.3ms 6.7 5.7 8.2 1.1

Если я делаю traceroute с PE1 на PE2 (и на loopback, и на крайний интерфейс, propagate TTL снова включён) — я вижу MPLS-метки:

[admin@PE1] > tool traceroute 5.5.5.5
ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS
1 10.23.0.3 0% 4 2.6ms 4.4 2.6 6.4 1.5 MPLS:L=47,E=0
2 10.34.0.4 0% 4 2.9ms 3.9 2.9 4.7 0.8 MPLS:L=40,E=0
3 5.5.5.5 0% 4 2.4ms 4.3 2.4 7.2 2

[admin@PE1] > tool traceroute 10.56.0.5
ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS
1 10.23.0.3 0% 4 2.8ms 3 2.8 3.2 0.2 MPLS:L=52,E=0
2 10.34.0.4 0% 4 2.9ms 2.8 2.4 3.3 0.4 MPLS:L=44,E=0
3 10.56.0.5 0% 4 2.5ms 2.7 2.5 2.9 0.2

Так почему же клиент не видит MPLS-метки?

Altare

Guest

24.08.2016 14:26:00

Да, на e0 на PE2 — это будет точка, где P2 убирает внешний лейбл, так что ты все равно должен видеть vpn-лейбл. Если здесь вообще нет лейбла, то это объясняет, почему traceroute зависает на P1 и P2. Помни, что ты ищешь ICMP-сообщения о превышении времени, исходящие от P1 и P2.

unixlamaster

Guest

21.07.2016 08:31:00

Привет, у меня тоже есть вопрос. Собирал по ручной схеме http://wiki.mikrotik.com/wiki/Manual:Layer-3_MPLS_VPN_example, результат и конфиги во вложении. Я добавил строку: /mpls set propagate-ttl = no, но это не работает!!!

PC2> trace 10.1.1.1
traceroute to 10.1.1.1, максимум 8 прыжков, нажмите Ctrl + C для остановки
1 * * *
2 * * *
3 * 10.1.1.1 5.976 ms (ICMP type: three, code: 3, Destination port unreachable)

Что делать? Как построить транспортную MPLS-сеть так, чтобы она не была видна в трассировке?

PE-B.txt (1.05 KB)
PE-C.txt (924 Bytes)
PE-D.txt (1.03 KB)

shaoranrch

Guest

21.07.2016 14:45:00

Привет! Нет, это не так. На то есть причина: маршруты VRF должны храниться только в своей таблице, при этом только маршрутизаторы PE (в соответствующей VRF-таблице) и CE (в главной таблице) должны знать об этих маршрутах, а маршрутизаторам P знать о них не нужно. Это позволяет использовать пересекающиеся префиксы у разных клиентов и при этом не загружать основную сеть сотнями или даже тысячами маршрутов. Подумай сам, какой смысл это делать? Теперь представь, как это будет масштабироваться, если для каждого маршрута в VRF-таблицах нужно добавлять статический маршрут, а что будет, если VRF A (Клиент A) использует 192.168.0.0/24, а VRF B (Клиент B) тоже использует 192.168.0.0/24? Как, по-твоему, будет маршрутизироваться трафик? L3VPN использует MPLS со стеком из двух меток — одна внешняя для транспортировки внутри MPLS-сети, а вторая внутренняя идентифицирует VPN, которому принадлежит этот трафик. Последняя метка доступна только маршрутизаторам PE и позволяет им понять, в какую таблицу маршрутизации (VRF) нужно смотреть, чтобы правильно направить трафик.

lillis

Guest

15.08.2016 16:17:00

Хорошо, я понял. Я снова удалил статические маршруты. Но не понимаю, почему при трассировке от CPE1-1 до CPE1-2 на другом конце у меня первые четыре прыжка не проходят. Я следовал этому руководству http://www.tech-blog.info/wp/?p=104, где говорится, что я должен получать ответ, хотя бы от 0.0.0.0.
[admin@CPE1-1] > tool traceroute 10.56.0.6
ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS
1 100% 3 timeout
2 100% 2 timeout
3 100% 2 timeout
4 100% 2 timeout
5 10.56.0.6 0% 2 4.9ms 10.1 4.9 15.3 5.2

Когда я отключаю “propagate ttl”, получаю вот такое:
[admin@CPE1-1] > tool traceroute 10.56.0.6
ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS
1 100% 3 timeout
2 100% 3 timeout
3 10.56.0.6 0% 3 7ms 6.5 6 7 0.5

Есть идеи, почему так?

Altare

Guest

19.08.2016 13:34:00

Зачем использовать route reflector? Просто настройте iBGP между PE1 и PE2. Нет необходимости запускать BGP на P-роутах с включенным MPLS. Почему клиент не увидит MPLS-метки? Конечно, вы же не хотите, чтобы клиент видел вашу внутреннюю инфраструктуру? Не забывайте, что LSP односторонний. Чтобы у TTL истек срок действия, пакет сначала должен дойти до выхода LSP. Подумайте: если P1 должен отправить ICMP-сообщение «time exceeded» инициатору, у него должен быть маршрут к этому инициатору. А его нет, поэтому сообщение придется отправлять дальше по пути. http://www.ciscopress.com/articles/article.asp?p=680824&seqNum=4

Altare

Guest

19.08.2016 13:52:00

Я только что увидел ещё одну тему, где говорится, что RouterOS не поддерживает распространение меток через BGP. Похоже, это и есть проблема — у P2 нет информации о VPN-метках, поэтому когда TTL заканчивается внутри MPLS-ядерной сети, P2 пересылает каждое сообщение ICMP "время истекло" без VPN-метки. А без VPN-метки обратный путь начинает использовать глобальную таблицу маршрутизации и, соответственно, не находит маршрут обратно к источнику. При обычном трафике (без истечения TTL) P2 просто снимает верхнюю метку, оставляя VPN-метку на месте. Попробуйте добавить BGP на P2, чтобы VPN-метки могли обмениваться через LDP.

lillis

Guest

20.08.2016 14:44:00

Ты прав, я не хочу показывать клиенту свою ядровую сеть. Я это скрываю, когда выключаю настройку «propagate TTL» в MPLS, но сейчас хочу открыть доступ, чтобы разобраться в проблеме. Мне удалось подтянуть это с ядровым MPLS, но с VPNv4-маршрутом клиента не получается. Мне нужен route reflector, потому что хочу масштабировать сеть с добавлением новых роутеров по мере расширения. Я также добавил BGP на P2, но это ничего не изменило. Когда я «прячу» ядровую сеть, в трассировке всё равно выпадают две прыжка, и пакет не доходит до клиента. Понимаю, почему так происходит — нет.

Altare

Guest

22.08.2016 07:03:00

Когда время жизни (TTL) истекает на любом из P-маршрутизаторов, им приходится формировать ICMP-ответ источнику. Если эти два P-маршрутизатора не имеют VRF клиента и соответствующих маршрутов, они не смогут собрать ICMP-сообщения обратно к источнику. Это, конечно, сводит на нет всю идею использования MPLS. ICMP-пакет должен отправляться по исходному пути с сохранённой меткой VPN, но, подозреваю, этого не происходит, поскольку при использовании глобальной таблицы маршрутизации MPLS-метки отображаются нормально. Попробуйте сделать захват пакетов на выходящем пути, чтобы увидеть, что именно содержится в ICMP-пакете "time exceeded". Если вы не увидите внутреннюю метку VPN, это объяснит, почему traceroute не работает.

lillis Guest	#10 0 23.08.2016 14:46:00 Что вы имеете в виду под маршрутом выхода? Если я прослежу от CPE1-1 до CPE1-2 и сделаю захват пакетов на PE2?

lillis

Guest

#11

25.08.2016 15:34:00

Я запускаю трассировку с CPE1-1 на CPE1-2, и на интерфейсе e0 PE2 у меня активен сниффер пакетов, но что-то тут странное. Не уверен, проблема ли в самом перехвате или GNS3 просто не может корректно захватывать трафик. Всё это делаю в лабораторной среде GNS3 с включённым сниффером, который стримит данные на мой физический компьютер (192.168.154.1), где у меня запущен Wireshark. Посмотрите вложение и обратите внимание на ICMP-пакеты между 192.168.154.1 (компьютером с Wireshark) и 192.168.154.5 (PE2). Там не только ICMP, но ещё LDP, OSPF и всякая другая фигня внутри. Думаю, так происходит, когда захватываешь трафик и стримишь его на сервер Wireshark вот таким образом? PE2_e0.zip (1.18 KB)

Altare Guest	#12 0 01.09.2016 13:40:00 Что-то здесь не так. Обычно в сообщениях ICMP unreachable видно данные пакета, которые их вызвали, но я вижу только пакеты управляющей плоскости, а не пользовательской (то есть пинг с CE1 до CE2).

ZeroByte Guest	#13 0 01.09.2016 13:52:00 Вставьте коммутатор между двумя Mikrotik'ами, чтобы можно было напрямую захватывать трафик в Wireshark.

lillis

Guest

#14

08.09.2016 19:33:00

Я купил несколько маленьких RB750, настроил такую же топологию и сделал новый трассинг. На этот раз мне удалось поймать несколько ICMP-пакетов (см. вложение), но при отключённой опции Propagate TTL всё равно получаю 2 прыжка с ошибкой.
[admin@CPE1] > tool traceroute 10.56.0.6
ADDRESS LOSS SENT LAST AVG BEST WORST
1 100% 211 timeout
2 100% 211 timeout
3 10.56.0.6 0% 210 0.5ms 0.5 0.4 0.9
PE2_e0_new.zip (606 Bytes)

lillis

Guest

#15

12.09.2016 20:58:00

Хорошо, теперь я сделал новый снифер пакетов на всех роутерах и всех интерфейсах, и теперь могу видеть правильные метки MPLS (как внутренние, так и внешние) на всём пути между CPE1 и CPE2. Так что там всё выглядит нормально. Traceroute.zip (2.2 KB)

roel Guest	#16 0 16.12.2016 04:55:00 Привет, Sir lillis! Ты уже решил свою проблему? У меня тут такая же ситуация.

roel Guest	#17 0 17.12.2016 02:24:00 Привет, ребята, кто-нибудь уже решил эту проблему? Я пытался найти информацию об этом, но не вижу, чтобы у других поставщиков сталкивались с такой же проблемой. Помогите, пожалуйста.

marrold

Guest

#18

17.12.2016 18:58:00

Боюсь, я не могу помочь, но у меня такая же проблема. Я повторил конфигурацию, показанную на Wiki, которая очень похожа на этот блог-пост. В обоих явно видно, что PE-маршрутизаторы отвечают на traceroute, а у меня отвечает только конечный пункт назначения.

[admin@RouterA] > / tool traceroute 10.7.7.5
# ADDRESS LOSS SENT LAST AVG BEST WORST
1 100% 3 timeout
2 100% 2 timeout
3 10.7.7.5 0% 2 12.6ms 15.4 12.6 18.2

Полагаю, дело в том, что ответы ICMP TTL exceeded используют основную таблицу маршрутизации и поэтому не знают, как добраться обратно до источника traceroute, хотя в примерах выше это работало. Кто-нибудь может подсказать, что я делаю не так?

Топология

Router A
/ip address
add address=10.1.1.1/24 interface=ether1 network=10.1.1.0
/routing ospf network
add area=backbone network=10.1.1.0/24

/system identity
Router B
/interface bridge add name=lobridge
/routing ospf instance
set [ find default=yes ] redistribute-bgp=as-type-1 routing-table=vrf1
/ip address
add address=10.1.1.2/24 interface=ether2 network=10.1.1.0
add address=10.2.2.2/24 interface=ether3 network=10.2.2.0
add address=10.9.9.2 interface=lobridge network=10.9.9.2
/ip firewall mangle
add chain=input in-interface=ether2
/ip route
add distance=1 dst-address=10.9.9.3/32 gateway=10.2.2.3
add distance=1 dst-address=10.9.9.4/32 gateway=10.2.2.3
/ip route vrf
add export-route-targets=10.1.1.1:111 import-route-targets=10.1.1.1:111 interfaces=ether2 route-distinguisher=10.1.1.1:111 routing-mark=vrf1
/mpls
set propagate-ttl=no
/mpls ldp
set enabled=yes transport-address=10.9.9.2
/mpls ldp interface
add interface=ether3
/routing bgp instance vrf
add redistribute-connected=yes redistribute-ospf=yes routing-mark=vrf1
/routing bgp peer
add address-families=vpnv4 name=peer1 remote-address=10.9.9.3 remote-as=65530 update-source=lobridge
/routing ospf network
add area=backbone network=10.1.1.0/24

/system identity
set name=RouterB

Router C
/interface bridge add name=lobridge
/ip address
add address=10.2.2.3/24 interface=ether3 network=10.2.2.0
add address=10.3.3.3/24 interface=ether2 network=10.3.3.0
add address=10.9.9.3 interface=lobridge network=10.9.9.3
/ip route
add distance=1 dst-address=10.9.9.2/32 gateway=10.2.2.2
add distance=1 dst-address=10.9.9.4/32 gateway=10.3.3.4
/mpls
set propagate-ttl=no
/mpls ldp
set enabled=yes transport-address=10.9.9.3
/mpls ldp interface
add interface=ether2
add interface=ether3
/routing bgp instance vrf
add redistribute-connected=yes redistribute-ospf=yes routing-mark=vrf1
/routing bgp peer
add address-families=vpnv4 name=peer1 remote-address=10.9.9.2 remote-as=65530 route-reflect=yes update-source=lobridge
add address-families=vpnv4 name=peer2 remote-address=10.9.9.4 remote-as=65530 route-reflect=yes update-source=lobridge

/system identity
Router D
/interface bridge
add name=lobridge
/routing ospf instance
set [ find default=yes ] redistribute-bgp=as-type-1 routing-table=vrf1
/ip address
add address=10.3.3.4/24 interface=ether2 network=10.3.3.0
add address=10.4.4.4/24 interface=ether3 network=10.4.4.0
add address=10.9.9.4 interface=lobridge network=10.9.9.4
/ip route
add distance=1 dst-address=10.9.9.2/32 gateway=10.3.3.3
add distance=1 dst-address=10.9.9.3/32 gateway=10.3.3.3
/ip route vrf
add export-route-targets=10.1.1.1:111 import-route-targets=10.1.1.1:111 interfaces=ether3 route-distinguisher=10.1.1.1:111 routing-mark=vrf1
/mpls
set propagate-ttl=no
/mpls ldp
set enabled=yes transport-address=10.9.9.4
/mpls ldp interface
add interface=ether2
/routing bgp instance vrf
add redistribute-connected=yes redistribute-ospf=yes routing-mark=vrf1
/routing bgp peer
add address-families=vpnv4 name=peer1 remote-address=10.9.9.3 remote-as=65530 update-source=lobridge
/routing ospf network
add area=backbone network=10.4.4.0/24

/system identity
set name=RouterD

Router E
/ip address
add address=10.4.4.5/24 interface=ether1 network=10.4.4.0
add address=10.7.7.5/24 interface=ether2 network=10.7.7.0
/routing ospf network
add area=backbone network=10.4.4.0/24
add area=backbone network=10.7.7.0/24
/system identity
set name=RouterE

lillis Guest	#19 0 27.12.2016 16:37:00 Ответ, который я в итоге получил от тренера Mikrotik, был такой: возможно, это появилось в более новых версиях прошивки. Во всех примерах, которые я находил, использовалась очень старая прошивка, но сам я это не проверял.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры