Типовые проблемы L3VPN MPLS сетей · PDF file• mpls добавляет 1-4 меток по 4 байта к клиентскому пакету, что обязывает

© 2011 Cisco and/or its affiliates. All rights reserved. 1

Cisco Support Community Expert Series Webcasts in Russian: Типовые проблемы L3VPN MPLS сетей

Игорь Тумкин инженер русского центра технической поддержки Cisco TAC

17.04.2012


•  Сегодня на семинаре эксперт Cisco TAC

•  Вы можете задавать вопросы по теме «Типовые проблемы L3VPN MPLS сетей»

Игорь Тумкин CCIE in Routing and Switching, &

Service Provider

2

Expert’s photo


Сегоднешняя презентация включает опросы аудитории

Пожалуйста, участвуйте!


Если Вы хотите получить копию слайдов сегоднешнего семинара, пожалуйста, используйте следующие ссылки:

https://supportforums.cisco.com/community/russian/routing

или, https://supportforums.cisco.com/docs/DOC-23809


a)  Я знаю основы MPLS, но ничего не знаю об MPLS VPN

b)   Я знаю теорию MPLS VPN, но не имею практического опыта.

c)  Я опробовал эту технологию в лаборатории.

d)   Я регулярно работаю с этой технологией.

Каков уровень Ваших знаний по технологии MPLS VPN?

6 © 2011 Cisco and/or its affiliates. All rights reserved.

Используйте Q&A панель, чтобы послать вопрос. Наши эксперты ответят на них


Типовые проблемы L3VPN MPLS сетейИгорь Тумкин

17.04.2012

Инженер Cisco TAC


• Проблемы связанные с MTU; •  Broken LSP;

•  LDP flapping or down; •  LDP-IGP синхронизация •  'traceroute' in L3VPN MPLS;

• OSPF Down-bit.


Проблемы связанные с MTU


•  MPLS добавляет 1-4 меток по 4 байта к клиентскому пакету, что обязывает MPLS интерфейсы иметь увеличенный MTU

•  1-2 метки используются в стандартном MPLS VPN и еще 1-2 метки могут быть добавлены MPLS Traffic Engineering Tunnels и MPLS TE Fast Re-Route

•  Т.о. на 16 байт может увеличиться пакет в L3 VPN

•  L2 VPN overhead дополнительно включает еще и L2 header

•  Т.е. клиентский пакет размером 1500 в ядре сети может вырасти до 1530 и более


•  Симптомы: медленно работает Интернет.

•  Триггер: неизвестен - «клиент: мы ничего не меняли».

•  Подробности: медленно работают TCP приложения, пинг работает без проблем.

•  Troubleshooting: пинг большими пакетами с DF битом показывает, что пакеты с размером больше чем (например) 1492 байта теряются.

•  Root cause: изменилась топология, и трафик с двумя MPLS метками перешел на линк с MTU 1500


1.  Увеличение MTU на MPLS интерфейсах минимум на 8 байт для basic L3VPN и на 30 байт для EoMPLS. Часто используют MTU 1600 или максимально возможное. Главное, чтобы оно было одинаковым по обе стороны линка, а желательно и на всей сети.

2.  Частное решение – увеличение только MPLS MTU.

3.  Workaround – использование команды ‘ip tcp adjust-mss’


Broken LSP


•  Большинство MPLS сервисов (таких как L3 VPN) нуждаются в непрерывном LSP (label switch path) от PE до PE

•  Так как P маршрутизаторы имеют информацию только о верхней (IGP) метке, если LSP нарушен и верхней метки нет, пакет будет потерен


•  Трафик MPLS VPN или AToM не проходит, хотя Control Plane в порядке (например, на PE маршрутизаторах имеются все маршруты, метки, BGP работает штатно и т.п.)


•  Быстрый способ определить, где LSP прерывается – использовать обычный ‘traceroute’ с PE. TTL-forwarding должен быть выключен для локального трафика командой «no mpls ip propagate-ttl local»

•  Первый хоп в выводе этой команды будет означать, что MPLS заголовок отсутствует


1.  LDP сессия не работает на промежуточном линке

2.  Суммаризация префиксов в ядре MPLS сети


•  Отсутсвие LDP сессии на промежуточном линке приводит к тому, что маршрутизатор, посылающий пакеты на этот линк не может выставить IGP (верхнюю) метку, и вынужден снять ее. Т.о. открывается нижняя (VPN) метка, и следующий в цепочке маршрутизатор получает пакет с неизвестной ему меткой и отбрасывает его

•  Причины неисправностей с LDP сессиями будут рассмотрены в следующем разделе


•  LSP (label switching path) создается в MPLS сети для каждого префикса, и маршрутизаторы на пути выделяют свои метки для этого префикса

•  Если префикс суммаризируется где-то на пути, создается отдельный LSP для суммаризированного префикса

•  Т.о. получается составной LSP для исходного префикса


•  Суммаризация выполнене на маршрутизаторе А, он анонсирует 10.1.1.0/22 с меткой implicit-null

•  Предыдущий на пути маршрутизатор отрабатывает PHP, т.е. снимает верхнюю метку, что и приводит к проблеме


•  Данная проблема (broken LSP) специфична в основном для /32 префиксов на PE loopbacks

•  Чтобы исключить случайное попадание PE loopback в суммаризацию, обычно выделяют для лупбэков отдельную subnet /24


LDP flapping or down


•  Используется UDP 646 мультикаст на all-routers (224.0.0.2). Основные диагностические команды:

•  PE1#sh mpls ldp discovery Local LDP Identifier: 192.168.2.100:0 Discovery Sources: Interfaces: Ethernet0/0 (ldp): xmit/recv LDP Id: 192.168.2.2:0 LDP Id: 192.168.2.3:0

•  PE1#sh mpls ldp parameters ...Discovery hello: holdtime: 15 sec; interval: 5 sec ....


•  Используется TCP 646 между loopbacks маршрутизаторов, которые выбраны как LDP Router ID

•  По умолчанию LDP Router ID становится старший IP адрес из loopbacks, но лучше не полагаться на дефолт и установить его командой «mpls ldp router-id loopback 0»

•  Т.о. необходима IP маршрутизация между этими loopbacks

•  Если такая маршрутизация неприемлима, можно использовать команду «mpls ldp discovery transport-address interface»


•  Не работает обнаружение соседей

•  Не устанавливается LDP сессия

•  LDP сессия падает из-за Discovery Timer expired

•  LDP сессия падает из-за Session Timer expired


•  Проверить мультикаст доступность ‘ping 224.0.0.2’

•  Если 224.0.0.2 не отвечает, проверить, что интерфейс слушает 224.0.0.2 командой ‘show ip interface’

•  Проверить, что маршрутизатор посылает Discovery пакеты командой ‘show mpls ldp discovery’ – должно присутствовать ‘xmit’ на соответствующем интерфейсе

•  Проверить командой ‘show mpls ldp discovery’, что обе стороны используют LDP, а не TDP

•  Проверить, что ACL не фильтрует UDP 646


•  Проверить IP доступность между Loopbacks обоих

маршрутизаторов

•  Проверить, что ACL не фильтрует TCP 646


•  Сообщение типа: %LDP-5-NBRCHG: LDP Neighbor 192.168.2.4:0 (3) is DOWN (Discovery Hello Hold Timer expired)

•  Default timeout is 15 sec. Можно проконтролировать командой ‘show mpls ldp parameters’

•  Такая ошибка означает, что маршрутизатор не получал Discovery Hello пакетов в течении 15 секунд

•  Это означает, что:

- передающая сторона не посылала эти пакеты;

-  на принимающей стороне interface congested/High CPU приводит к потере пакетов (обычно при этом также падают другие протоколы – IGP, PIM, etc)


•  Если Discovery пакеты (периодически) не передаюся, это связано либо с High CPU, либо с некорректно настроенным QOS на интерфейсе. Встречается редко.

•  Обычно потери Discovery пакетов происходят на приемной стороне

•  Не будем рассматривать экстремально высокую загрузку CPU, когда все протоколы падают, т.к. это должно исследоваться отдельно

•  Если на том же интерфейсе есть BGP соседи, рекомендуется увеличить соответствующие буферы, т.к. BGP пакеты имеют такой же приоритет и используют те же буферы


•  На 7600/6500 платформах при использовании ‘mls qos’ необходимо конфигурировать ‘mls qos trust dscp’ (где это применимо), иначе DSCP будет обнулено и приоритет пакетов утерян

•  Увеличить input queue на интерфейсе командой ‘hold-queue input 4096’, особенно если интерфейс 1GBps или 10Gbps и BGP full view на соседях (при этом есть потери в ‘input-queue’ на интерфейсе)

•  Увеличить параметры SPD: - ‘spd extended-headroom 1000'; - ‘ip spd queue max-threshold 3999'; - 'ip spd queue min-threshold 3800‘ - 'spd headroom 2000'; - параметры SPD можно проконтролировать командой ‘show ip spd’


•  В логах ошибки типа: %LDP-5-NBRCHG: LDP Neighbor 192.168.2.4:0 (3) is DOWN (Session KeepAlive Timer expired)

•  Default Session hold time = 180 sec. Можно проконтролировать командой ‘show mpls ldp parameters

•  Часто это означает проблемы с IP connectivity. Нужно проверить возраст маршрута на Loopback соседа

•  Если машруты на обоих сторонах стабильны, и проблемы связаны с загрузкой интерфейса и/или CPU, то далее применимы те же методы, что и с пакетами Discovery


a)  Прекрасно знаю и использую

b)   Неплохо знаю, но не использую

c)  Что-то слышал

d)   Не знаю, что это такое

Насколько хорошо Вы знаете технологию LDP-IGP синхронизации


LDP-IGP синхронизация


•  LDP-IGP синхронизация предназначена для предотвращения передачи трафика в ситуации ‘broken LSP’, например, когда где-то на пути трафика не работает LDP, что приводит в снятию верхней метки и фактически потере пакетов.

•  LDP-IGP синхронизация решает 2 основные проблемы:

1.  LDP сессия перешла в состояние Down где-то на пути трафика.

2.  Новый (или ранее упавший) IGP сосед появился на пути трафика. LDP сессия еще не установилась


•  Т.к. IGP не знает, что LDP Down, с точки зрения маршрутизации ничего не меняется и трафик идет по тому же пути

•  На линке без LDP с пакета снимается верхняя метка, и следующий маршрутизатор (P) дропает пакет, т.к. ничего не знает о VPN метках

•  Решение: синхронизировать LDP c IGP.

Команда: (config-router)#mpls ldp sync

•  IGP устанавливает cost = max-metric (65535) на линка, пока не поднимется хотя бы один LDP сосед. В этом случае, если есть альтернативный маршрут, трафик будет доставлен без потерь


•  При отсутствии альтернативных маршрутов, IGP должен подняться раньше LDP, т.к. LDP нуждается в маршрутизации Loopbacks

•  Поэтому в таком случае LDP-IGP синхронизация работает по следующему алгоритму:

•  Если Loopback соседа недоступен (с точки зрения маршрутизации), IGP будет поднято, но cost на этом линке будет max-metric, пока LDP сессия не установится, после этого IGP анонсирует нормальный cost

•  Если Loopback соседа доступен, или если ни одного LDP соседа не было обнаружено на этом линке (по UDP), то IGP не поднимается совсем, пока хотя бы одно LDP сессия не поднимется или истечет “synch holddown timer” (по умолчанию, установленный на бесконечность)


•  LDP синхронизация сама по себе тоже может привести к неожиданной проблеме:

•  После ‘interface flap’ IGP не поднимается!

•  Это происходит, если альтернативного пути для достижения Loopback соседа фактически нет, но есть дефолт, так что формально система считает, что Loopback достижим и ждет поднятия LDP сессии. Можно проверить командой «show mpls ldp igp sync interface»

•  Решение: убрать дефолт или установить “synch holddown timer” командой «(config)#mpls ldp igp sync holddown»


•  LDP синхронизация с помощью IGP пытается убрать трафик с линков, где не установлена LDP сессия. Используются только link-state IGP (OSPF, ISIS). Правила:

•  Если Loopback соседа недоступен, IGP поднимается, link cost set to max-metric пока не поднимется LDP сессия

•  Если Loopback соседа доступен или не обнаружено LDP соседей на интерфейсе, IGP не поднимается, пока LDP сессия не установится или “synch holddown timer” кончится

•  Когда IGP adjacency поднялось, оно остается UP, даже если LDP падает, но при этом link cost устанавливается в max-metric, пока LDP не поднимется назад


‘Traceroute' in L3VPN MPLS


•  По умолчанию IP TTL копируется в MPLS TTL (последние 8 бит метки), когда пакеты входят в MPLS облако. Это называется «TTL propagation».

•  При прохождении MPLS облака уменьшается только MPLS TTL (IP TTL остается нетронутым).

•  При покидании MPLS облака MPLS TTL копируется в IP TTL.


•  иллюстрация


•  «Traceroute» посылает пакеты с увеличивающимся TTL и полагается на ICMP ‘TTL exceeded’ ответные пакеты, генерируемые маршрутизаторами на пути

•  Проблема: P маршрутизаторы в MPLS облаке не имеют маршрутной информации об источнике, на котором запущен “traceroute”, если он в VRF

•  Решение: генерируемый ICMP пакет посылается не в соответсвии с машрутной информацией по ‘IP destination’, а упаковывается в такой же MPLS header, как и оригинальный пакет, и посылается дальше по тому же пути (а не обратно к источнику). И только PE маршрутизатор сняв все метки, посылает этот ICMP пакет в соответсвии с машрутной информацией в сторону источника.



•  Замечание: «traceroute» не может быть использован для troubleshooting в MPLS сетях, т.к. проблема на любом хопе приводит к полному отсутствию откликов в выводе команды

•  Чтобы скрыть топологию MPLS облака провайдеры часто отключают TTL propagation, при этом MPLS TTL не копирует IP TTL, а устанавливается в 255

•  Интересная особенность: если Traceroute посылать на Loopback CE маршрутизатора, то можно получить отсутствие всех откликов, кроме последнего. Это может быть вызвано anti-spoofing ACL на СЕ и тем фактом, что т.к. не используется Aggregate Label, PE не делает дополнительный IP lookup, а просто посылает пакет со снятой меткой в сторону CE.


OSPF Down-bit


•  OSPF Down-bit – это 7-й бит поля флагов в Summary LSA (type-3 LSA)

•  Предназначен для предотвращения петель маршрутизации в multihome CE setup между MPLS/VPN backbone и OSPF domain (CE)

•  PE устанавливает Down-bit при передаче Summary LSA в сторону CE

•  PE проверяет Down-bit во входящих Summary LSA со стороны СЕ. При наличии Down-bit, LSA игнорируется


MPLS-VPN Backbone

Area 1

Network = Net-1

PE-1"

CE-1"

VPN-IPv4 Update RD:Net-1, Next-hop=PE-1 RT=xxx:xxx OSPF-Route-Type= 1:2:0 OSPF-Domain: xxx

Area 2

PE-2"

CE-2"Type-3 (Summary-LSA) Down bit is set Link-State-ID: Net-1 Adv. Router: PE-2

PE-3" Type-3 (Summary-LSA) Down bit is set Link-State-ID: Net-1 Adv. Router: PE-2

VPN-IPv4 Update RD:Net-1, Next-hop=PE-3 RT=xxx:xxx OSPF-Route-Type= 1:2:0 OSPF-Domain: xxx


•  Установка и проверка Down-bit происходят по умолчанию автоматически

•  Система считается себя PE, если OSPF запущен в VRF

•  Типичная проблема – один из маршрутизаторов CE имеет интерфейс в VRF. С точки зрения дизайна, это CE, т.к. там нет ни MPLS, ни vpnv4 BGP, но маршрутизатор считает себя PE и выполняет проверку Down-bit. Это приводит к тому, что часть OSPF маршрутов не вставляется в RIB

•  Решение: команда ‘capability vrf-lite’ отключает проверку Down-bit. Естественно, ее нельзя отключать на MPLS PE маршрутизаторах


a)  Особенности использования IGP в MPLS VPN (OSPF, EIGPR)

b)   BGP in MPLS VPN setup

c)  L2VPN, VPLS

d)   mVPN

e)  InterAS MPLS

f)   Архитектура платформы 7600

g)   Архитектура платформы ASR1000

Какие темы будущих семинаров Вам интересны? Выберите из предложенных или предложите свои


Используйте Q&A панель, чтобы послать вопрос. Наши эксперты ответят на них


•  Reference 1 http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6557/prod_presentation0900aecd80312051.pdf

•  Reference 2 http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a0080093fcd.shtml

•  Support pages: http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a0080144ab2.shtml

•  http://www.cisco.com/en/US/tech/tk436/tk428/tsd_technology_support_troubleshooting_technotes_list.html

•  http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/gslsppt.html


Эксперт ответит на некоторые Ваши вопросы. Используйте Q&A панель, чтобы задать еще вопросы


Заполнившие опросник автоматически участвуют в лотерее:

$20 Подарочный сертификат

Для участия в опросе, пожалуйста, используйте линк в окне чата или всплывающее окно по завершению семинара


Получить дополнительную информацию, а также задать вопросы экспертам в рамках данной темы вы можете в течение двух недель, на странице, доступной по ссылке https://supportforums.cisco.com/community/russian/expert-corner/ask-the-experts Вы можете получить видеозапись данного семинара и текст сессии Q&A в течении ближайших 5 дней по следующей ссылке https://supportforums.cisco.com/community/russian/expert-corner/webcast


на английском

Сессия продлится с 23 апреля по 4 мая.

Эксперт

Marwan Al-shawi

В имеете возможность узнать о дизайне отказоустойчивых сетей LAN, WAN и инфраструктурах дата-центров.

Marwan Al-shawi - старший сетевой инженер и технический консультант в Dimension Data Australia, мировом партнере Cisco. Dimension Data Australia является частью крупнейшей телекоммуникационной компании в Азии и Японии.

Присоединяйтесь к обсуждению @

https://supportforums.cisco.com/community/netpro/expert-corner

Тема: Network Path Redundancy Design



Вторник, 2 мая, 19:00 по Москве (UTC +4) 8:00 a.m. по Сан-Франциско (PDT UTC -7) 11:00 a.m. по Нью-Йорку (EDT UTC -5), 4:00 p.m. по Лондону (BST UTC +1) 5:00 p.m. по Брюсселю (CEST UTC +2)

Вебинар проведет Salman Asadullah

Весь мир готовится к 6-му июня - дню мирового запуска IPv6. В этот день все крупнейшие Internet Players окончательно включат IPv6 в своих продуктах и сервисах. Этот вебинар прольет свет на грядущий день запуска IPv6 и расскажет как к нему подготовиться.

В течение мероприятия, Эксперт Salman Asadullah расскажет что такое день мирового запуска IPv6, о его последствиях и как это повлияет на пользователей. Салман так же поделится опытом как правильно подготовиться к запуску.

В этой интерактивной сессии Вы сможете задать вопросы по заданной теме

Регистрируйтесь:

https://supportforums.cisco.com/community/netpro/expert-corner#view=webcasts

Тема: Готовимся к мировому запуску IPv6



Мероприятие начинается 17 апреля в 14:30 по московскому времени на Facebook

Эксперт

Rahul Govindan

В этом мероприятии вы сможете узнать о том как настроить некоторые функции клиента AnyConnect (например xml профили) и разрешить проблемы, которые могут возникнуть.

Присоединяйтесь на Facebook @ http://www.facebook.com/events/330053187054340/

Так же эксперт проведет Спроси Эксперта с 17 по 27 апреля

Примите участие в дискуссии @ https://supportforums.cisco.com/community/netpro/expert-corner

Тема: Configuring and Troubleshooting AnyConnect Client Features



Мероприятие заканчивается 20-го апреля

Эксперты: Pete Newcomb и Jim Brown

В данной сессии Спроси Эксперта вы сможете узнать о новом релизе Cisco Prime Network Registrar, ведущем решении от компании Cisco для интеграции DNS, DHCP и управления адресным пространством IP (IPAM) для IPv4 и IPv6.

Пит - работает на позиции Technical Marketing Engineer более чем 30 лет.

Джим - Customer Support Engineer, более 14-ти лет работающий с командой разработчиков Network Registrar

Присоединяйтесь к дискуссии @


Тема: Cisco Prime Network Registrar



Мероприятие заканчивается 20-го апреля.

Эксперт

Chris Ward

У вас есть уникальная возможность задать вопросы, касающиеся новой архитектуры Hosted Collaboration Solution и о ее развертывании, эксперту Крису Варду.

Крис - Technical Marketing Engineer, работающий над Cisco Hosted Collaboration Solution.

Присоединяйтесь @


Тема: Cisco Hosted Collaboration Solution


https://supportforms.cisco.com/community/russian http://www.facebook.com/CiscoRu

http://twitter.com/CiscoRussia

http://www.youtube.com/user/CiscoRussiaMedia

http://itunes.apple.com/us/app/cisco-technical-support/id398104252?mt=8

http://www.linkedin.com/groups/CSC-Cisco-Support-Community-3210019

Newsletter Subscription: https://tools.cisco.com/gdrp/coiga/showsurvey.do?surveyCode=589&keyCode=146298_2&PHYSICAL%20FULFILLMENT%20Y/N=NO&SUBSCRIPTION%20CENTER=YES

Спасибо за Ваше время

Пожалуйста, участвуйте в опросе

Thank you.

Documents

Типовые проблемы L3VPN MPLS сетей · PDF file• mpls добавляет 1-4 меток по 4 байта к клиентскому пакету, что обязывает