html текст
All interests
  • All interests
  • Design
  • Food
  • Gadgets
  • Humor
  • News
  • Photo
  • Travel
  • Video
Click to see the next recommended page
Like it
Don't like
Add to Favorites

Неожиданная причина потери пакетов на 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 — скорее всего, где-то повреждена шина.

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

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

Читать дальше
Twitter
Одноклассники
Мой Мир

материал с telekomza.ru

1

      Add

      You can create thematic collections and keep, for instance, all recipes in one place so you will never lose them.

      No images found
      Previous Next 0 / 0
      500
      • Advertisement
      • Animals
      • Architecture
      • Art
      • Auto
      • Aviation
      • Books
      • Cartoons
      • Celebrities
      • Children
      • Culture
      • Design
      • Economics
      • Education
      • Entertainment
      • Fashion
      • Fitness
      • Food
      • Gadgets
      • Games
      • Health
      • History
      • Hobby
      • Humor
      • Interior
      • Moto
      • Movies
      • Music
      • Nature
      • News
      • Photo
      • Pictures
      • Politics
      • Psychology
      • Science
      • Society
      • Sport
      • Technology
      • Travel
      • Video
      • Weapons
      • Web
      • Work
        Submit
        Valid formats are JPG, PNG, GIF.
        Not more than 5 Мb, please.
        30
        surfingbird.ru/site/
        RSS format guidelines
        500
        • Advertisement
        • Animals
        • Architecture
        • Art
        • Auto
        • Aviation
        • Books
        • Cartoons
        • Celebrities
        • Children
        • Culture
        • Design
        • Economics
        • Education
        • Entertainment
        • Fashion
        • Fitness
        • Food
        • Gadgets
        • Games
        • Health
        • History
        • Hobby
        • Humor
        • Interior
        • Moto
        • Movies
        • Music
        • Nature
        • News
        • Photo
        • Pictures
        • Politics
        • Psychology
        • Science
        • Society
        • Sport
        • Technology
        • Travel
        • Video
        • Weapons
        • Web
        • Work

          Submit

          Thank you! Wait for moderation.

          Тебе это не нравится?

          You can block the domain, tag, user or channel, and we'll stop recommend it to you. You can always unblock them in your settings.

          • schetnikov
          • домен telekomza.ru

          Get a link

          Спасибо, твоя жалоба принята.

          Log on to Surfingbird

          Recover
          Sign up

          or

          Welcome to Surfingbird.com!

          You'll find thousands of interesting pages, photos, and videos inside.
          Join!

          • Personal
            recommendations

          • Stash
            interesting and useful stuff

          • Anywhere,
            anytime

          Do we already know you? Login or restore the password.

          Close

          Add to collection

             

            Facebook

            Ваш профиль на рассмотрении, обновите страницу через несколько секунд

            Facebook

            К сожалению, вы не попадаете под условия акции