Особенно интересны ситуации, когда по формулировке проблемы кажется, что она на 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 — скорее всего, где-то повреждена шина.
На самом деле понадобилось сделать всего два шага. Зорким зрением инженера была усмотрена причина проблемы:
За активную работу по проблеме, оперативный ответ и предоставленное фото спасибо Виктора Бирюкова.
