Неожиданная причина потери пакетов на MPLS сети между двумя узлами

Особенно интересны ситуации, когда по формулировке проблемы кажется, что она на 15-20 минут, но при ближайшем рассмотрении охватывает недоумение. Как такое вообще возможно? С какой стороны подойти?

Вот об одной из таких фантастических загадок я и хочу рассказать.

Началось всё весьма прозаически: потери пакетов на MPLS сети между двумя узлами.

Примерно в таком виде была представлена схема сети. Без указания интерфейсов, IP-адресов, IGP и прочего.

PE-устройства имеют пиринг по BGP c P. Нижняя ветка имеет большие потери. Поэтому, увеличив приоритет верхней, удалось увести трафик на стабильный канал. С нижним же можно теперь творить любые бесчинства работать.

Удалёнка по VPN и вперёд на абразуру отладки.

И вот кажется, сейчас за пару минут ты разберёшься, закроешь запрос и почитаешь спокойно телекомзу. Ага!

Первое, что нужно сделать – убедиться в том, что проблема действительно имеет место.

[PE1]ping lsp -a 172.16.255.55 -c 50 ip 172.16.255.77 32

LSP PING FEC: IPV4 PREFIX 172.16.255.77/32/ : 100 data bytes, press CTRL_C to break

[Вырезано]

— FEC: IPV4 PREFIX 172.16.255.77/32 ping statistics —

50 packet(s) transmitted

45 packet(s) received

10.00% packet loss

round-trip min/avg/max = 65/92/175 ms

Что логично — она есть.

Причём, если увеличить размер ICMP пакетов со стандартного до 1000, например, то потери вырастают до чудовищных 90% Отмечаем себе в ячейку эту особенность.

[PE1]ping lsp -a 172.16.255.55 -c 50 -s 1000 ip 172.16.255.77 32

LSP PING FEC: IPV4 PREFIX 172.16.255.77/32/ : 1000 data bytes, press CTRL_C to break

[Вырезано]

— FEC: IPV4 PREFIX 172.16.255.77/32 ping statistics —

50 packet(s) transmitted

5 packet(s) received

90.00% packet loss

round-trip min/avg/max = 65/92/175 ms

Теперь надо определить топологию сети.

Отправляемся в пешее путешествие по LSP:

Начинаем обратный отсчёт, чтобы найти на каком хосте начинаются потери.

1) на 17.222 они, конечно, есть.

[PE1]ping -c 20 172.16.17.222

[Вырезано]

— 172.16.17.222 ping statistics —

20 packet(s) transmitted

16 packet(s) received

20.00% packet loss

round-trip min/avg/max = 16/18/31 ms

[PE1]ping -c 20 172.16.8.61

[Вырезано]

— 172.16.8.61 ping statistics —

20 packet(s) transmitted

15 packet(s) received

25.00% packet loss

round-trip min/avg/max = 15/20/30 ms

3) на 6.45 есть

[PE1]ping -c 20 172.16.6.45

[Вырезано]

— 172.16.6.45 ping statistics —

20 packet(s) transmitted

16 packet(s) received

20.00% packet loss

round-trip min/avg/max = 10/12/27 ms

4) А на 7.21 уже нет:

[PE1]ping -c 20 172.16.7.21

[Вырезано]

— 172.16.7.21 ping statistics —

20 packet(s) transmitted

20 packet(s) received

0.00% packet loss

round-trip min/avg/max = 10/9/18 ms

Отсюда и будем плясать.

По очереди заходим на все устройства и проверяем таблицу FIB.

C PE1 на P3:

С Р1 на Р3:

С Р3 на Р1:

После этого я наконец имею представление о схеме подключения устройств.

Как видите у нас тут резервирование на резервировании. 3 линка между Р2 и Р3, 4 линка между Р1 и Р2.

Всё это рулится ISIS. (И напомню, что PE ещё резервируется по BGP на другую ветку.)

Разумеется, в такой ситуации первое подозрение на проблемы по физике — между двумя устройствами либо нет одного из L3-линков, но трафик туда всё же нарпавляется, либо рассогласование скорости/дуплекса.

Но тщательнейшая проверка каждого из 8 линков не дала ровным счётом никакого результата. Между всеми непосредственно подключенными парами устройств пинг изумительный — ни намёка на потерю. Никаких ошибок CRC и вообще любых других нет.

Может, уже всё исправилось?

[PE1]ping -c 20 172.16.6.45

PING 172.16.6.45: 56 data bytes, press CTRL_C to break

[Вырезано]

— 172.16.6.45 ping statistics —

20 packet(s) transmitted

16 packet(s) received

20.00% packet loss

round-trip min/avg/max = 17/17/18 ms

В сухом остатке имеем:

На физику между устройствами грешить не получится.

Хм, чешем голову, соображаем, что ещё может быть

а) отбрасывания из-за перегрузки линка или по политикам QoS

Сразу нет. Ни по настройками, ни по статистике никаких отбрасываний нет ни на одном устройстве.

б) политики обработки трафика отбрасывают часть пакетов или перенаправляют их на некорректный next-hop.

Traffic-policy на некоторых интерфейсах были, но они никак не влияли на отбрасывания, потому что объём трафика был значительно ниже порога.

traffic classifier COOL_CLASS operator or

if-match mpls-exp 5

if-match dscp ef

traffic behavior COOL_BEHA

car cir 500000 cbs 15000000 green pass red discard

traffic policy COOL_POL

share-mode

classifier COOL_CLASS behavior COOL_BEHA

Для эксперимента я даже попробовал удалить политики с интерфейса.

Мимо.

Есть ещё одна возможная причина: пакеты балансируются и уходят различными путями к получателю.

Весьма маловероятный вариант, потому что такое возможно только в режиме per-packet. Per-flow все пакеты одной TCP-сессии, вероятнее всего, направит в один интерфейс. Но режим Per-packet не включен.

Как бы то ни было проверить и это нужно.

Используем для этого самый верный безошибочный путь.

Создаём классификатор трафика, который будет определять источник:

acl name LOST_TEST

rule 5 permit ip source 172.16.5.65 0

traffic classifier LOST_TEST operator or

if-match acl name LOST_TEST

Ничего с трафиком делать не будем — пустой behavior:

traffic behavior LOST_TEST

Включаем подсчёт статистики и связываем классификатор с behavior:

traffic policy LOST_TEST

statistics enable

classifier LOST_TEST behavior LOST_TEST

То есть в статистике мы должны увидеть весь IP-трафик с адреса 172.16.5.65

Аплинк интерфейс на P1 у нас один GE1/0/0 — на него и вешаем.

Точно такие же политики создадим и на других устуройствах на пути и повешаем на все интерфейсы.

Пускаем пинг в 10 пакетов.

[PE1]ping -c 10 172.16.6.45

PING 172.16.6.45: 56 data bytes, press CTRL_C to break

[Вырезано]

— 172.16.6.45 ping statistics —

10 packet(s) transmitted

6 packet(s) received

40.00% packet loss

round-trip min/avg/max = 17/17/18 ms

Итак. 10 пакетов отправлено, 6 получено.

Вперёд! На поиски чёрной дыры.

С интерфейса PE1 ушли все 10.

Дальше P1:

То есть Р1 получил корректно все 10 пакетов.

Теперь поочерёдно все 4 аплинка на P2 под микроскоп.

Опа! Через линейную плату в 9-м слоту отправилось всего лишь 6 пакетов. WTF? В пределах одного устройства мы получили 10, а отправили только 6? Причём, вспомним, что при увеличении размера пакета потери увеличиваются.

Надо бы в точности установить феномен проблемы. Помнится пинг уже даже на Р2 с РЕ1 проходит отлично:

[PE1]ping -c 10 172.16.7.5

PING 172.16.7.5: 56 data bytes, press CTRL_C to break

[Вырезано]

— 172.16.7.5 ping statistics —

10 packet(s) transmitted

10 packet(s) received

0.00% packet loss

round-trip min/avg/max = 16/17/19 ms

Получили 10

Отправили те же 10, но они ушли через другой интерфейс

Пробуем выключить Gi9/0/1 и вуаля:

[PE1]ping -c 100 172.16.6.45

PING 172.16.6.45: 56 data bytes, press CTRL_C to break

[Вырезано]

— 172.16.6.45 ping statistics —

100 packet(s) transmitted

100 packet(s) received

0.00% packet loss

round-trip min/avg/max = 15/17/18 ms

Проблема уже почти локализована — это либо интерфейс GE9/1/0, либо плата в 9-м слоту.

Если честно, то до последнего не хочется допускать программную ошибку, несмотря на то, что они всё же бывают. Особенно, когда самостоятельно пройден такой длинный путь. Поэтому пробежался ещё раз по конфигу на предмет странностей — ноль.

Если бы не волшебная подсказка иностранных коллег, то в этот момент запрос пришлось бы эскалировать разработчикам и, скорее всего, решение бы подзатянулось.

А подсказка заключалась в том, что архитектура оборудования такого класса включает в себя отдельные платы коммутации, которые соединены с линейными общей шиной на шасси.

То есть различные функции L1/L2 уровня разнесены на разные платы — линейные занимаются непосредственно передачей трафика, а также коммутацией пакетов в пределах одной платы, для быстрой взаимосвязи между различными платами, а также воизбежание избыточных линков между слотами, существуют эти самые фабрики коммутации — Switch Fabric Unit.

В нашем случае трафик передаётся с интерфейса в 1-м слоту (трафик входит в GE1/0/0) на оинтерфейс в 9-м (трафик выходит из GE9/1/0). Соответственно, однозначно используются коммутационные платы. Всего их 4 штуки, которые осуществляют резервирование 3+1.

Область поисков немного расширяется — линйная плата в 9-м слоту, 4 модуля коммутации и интерконнект между ними.

Для проверки исправности взаимосвязи между LPU и SFU используется команда display switch-port lpu Х и вот что она выводит в нашем случае:

OPI — это output — направление от платы на шасси. Тут всё нормально.

IPE — это inbound — направление с шасси на плату. LinkLost.

То есть ход мыслей верный — мы видим LinkLost между LPU 9 и какой-то из SFU. Существуют специальные карты соответсвий между этими данными и конкертными SFU.

Забегая вперёд, скажу, что они бы нам не понадобились, но я всё же уточнил у разработчиков — этом случае Linklost с платой SFU в 19-м слоту.

Итак, проблема точно аппаратная.

План действий следующий:

1) Рестарт линейной платы в 9-м слоту. Проверка статуса, проверка пинга.

2) Если не помогло — извлечь плату, проверить на наличие повреждений и, возможно, заменить её на новую. Проверка статуса, проверка пинга.

3) Если не помогло — рестарт платы в 19-м слоту. Проверка статуса, проверка пинга. Потерь других сервисов при этом быть не должно благодаря резервированию.

4) Если не помогло — извлечь плату, проверить на наличие повреждений и, возможно, заменить её на новую. Проверка статуса, проверка пинга.

Таким образом мы почти однозначно установим причину. Если всё это не поможет — привлекаем R&D — скорее всего, где-то повреждена шина.

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

За активную работу по проблеме, оперативный ответ и предоставленное фото благодарю Виктора Бирюкова.