LINUX.ORG.RU
ФорумAdmin

Потеря пакетов в определенном VLAN


0

1

Есть сервер A, гигабитный интерфейс попилен на VLAN-ы, допустим: vlan100: 10.0.0.15/16 vlan101: 10.10.0.15/16 vlan110: 172.16.1.4

Через несколько коммутаторов от A стоит сервер B, с которого я делаю пинг до A:

# ping -i 0.1 10.0.0.15 -c 500
...
...
500 packets transmitted, 500 received, 0% packet loss, time 49897ms
rtt min/avg/max/mdev = 0.078/0.160/0.280/0.029 ms

# ping -i 0.1 10.10.0.15 -c 500
...
...
500 packets transmitted, 500 received, 0% packet loss, time 49897ms
rtt min/avg/max/mdev = 0.125/0.177/0.302/0.029 ms

# ping -i 0.1 172.16.1.4 -c 500
500 packets transmitted, 424 received, 15% packet loss, time 50507ms
rtt min/avg/max/mdev = 0.069/0.148/0.466/0.030 ms

куда смотреть?

★★★★★

на каком-нибудь коммутаторе какие-нибудь приоритеты для какого-нибудь VLAN не заданы случайно ? Или маршрут, для этого VLAN, другой... Но, в общем случае, странно. А просто кабелем напрямую нет возможности дотянуться на пробу ? Чтобы идею про коммутаторы сразу убрать...

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

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

Нет, приоритетов никаких нет, маршрутизации тоже - direct connect.

На самом деле все топология немного сложнее. На сервере A крутится Asterisk, клиенты начали жаловаться что постоянно кратковременно пропадает слышимость одного из абонетов во время разговора. Так вот в VLAN 110 - клиентские пиры. 90% трафика - RTP. Но общая нагрузка не более 3-4mb/s.

Я сейчас сделал ради эксперимента по разгрузке порта такое - VLAN 110 перевел на соседний eth, который воткнут в тот же коммутатор. Потери продолжаются.

Turbid ★★★★★
() автор топика
Ответ на: комментарий от Turbid

маршрутизации тоже - direct connect.

Я имел ввиду, вариант, когда коммутаторы не в цепочку, а кольцом каким-нибудь. Не IP маршрутизацию, а маршрут проключения VLAN.

AS ★★★★★
()
Ответ на: комментарий от AS

Я имел ввиду, вариант, когда коммутаторы не в цепочку, а кольцом каким-нибудь. Не IP маршрутизацию, а маршрут проключения VLAN.

Нет, там звезда обыкновенная

Turbid ★★★★★
() автор топика

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

А если используется *STP, то посмотреть на число изменений топологий.

vel ★★★★★
()

Схему бы поподробнее, между свичами везде транки? Или этот влан где-то акцесом идет?

Ну и плюсую про ошибки на портах и STP. Т.к. для каждого влана (обычно) работает отдельный инстанс спаннинг три, то это похоже на его шалости.

Ну и на самих серваках посмотреть интерфейсы тожа неплохо.

blind_oracle ★★★★★
()

Запустите на «A» tcpdump на icmp-пакеты с записью в файл, а потом по файлу посчитайте сколько пакетов (запросов/ответов) было. Хотя бы будет понятно, в каком направлении теряются пакеты.

И не понятно, в вашем примере у вас между A и B пакеты разными физическими маршрутами идут или почему минимальное время ping'а в случае с 10.10.0.15 раза в 2 больше?

mky ★★★★★
()
Ответ на: комментарий от blind_oracle

Схему бы поподробнее, между свичами везде транки? Или этот влан где-то акцесом идет?

Я сейчас схему еще раз проверил - эти серваки вообще в один свитч подключены, оказывается.

Turbid ★★★★★
() автор топика
Ответ на: комментарий от mky

Запустите на «A» tcpdump на icmp-пакеты с записью в файл, а потом по файлу посчитайте сколько пакетов (запросов/ответов) было. Хотя бы будет понятно, в каком направлении теряются пакеты.

500 packets transmitted, 466 received, 6% packet loss, time 50161ms
rtt min/avg/max/mdev = 0.119/0.158/0.482/0.029 ms

явно видно что выпало из этого куска:

00:26:09.846883 IP 172.16.1.4 > 172.16.1.10: ICMP echo reply, id 15549, seq 379, length 64
00:26:09.946854 IP 172.16.1.10 > 172.16.1.4: ICMP echo request, id 15549, seq 380, length 64
00:26:09.946879 IP 172.16.1.4 > 172.16.1.10: ICMP echo reply, id 15549, seq 380, length 64
00:26:10.046801 IP 172.16.1.10 > 172.16.1.4: ICMP echo request, id 15549, seq 381, length 64
00:26:10.046826 IP 172.16.1.4 > 172.16.1.10: ICMP echo reply, id 15549, seq 381, length 64
00:26:13.804849 IP 172.16.1.10 > 172.16.1.4: ICMP echo request, id 15549, seq 416, length 64
00:26:13.804878 IP 172.16.1.4 > 172.16.1.10: ICMP echo reply, id 15549, seq 416, length 64
00:26:13.904840 IP 172.16.1.10 > 172.16.1.4: ICMP echo request, id 15549, seq 417, length 64
00:26:13.904865 IP 172.16.1.4 > 172.16.1.10: ICMP echo reply, id 15549, seq 417, length 64
00:26:14.003868 IP 172.16.1.10 > 172.16.1.4: ICMP echo request, id 15549, seq 418, length 64

И не понятно, в вашем примере у вас между A и B пакеты разными физическими маршрутами идут или почему минимальное время ping'а в случае с 10.10.0.15 раза в 2 больше?

Не понятно. Говорю же, что они вообще в один коммутатор подключены, в логах которого ничего интересного.

Turbid ★★★★★
() автор топика
Последнее исправление: Turbid (всего исправлений: 1)

Ну и пинги теряются не равномерно, а видно что секунд 10-20 поток идет норм, потом фриз на 2-3 секунды и дальше поскакали

Turbid ★★★★★
() автор топика
Ответ на: комментарий от blind_oracle

Ну и на самих серваках посмотреть интерфейсы тожа неплохо.

Что именно нужно посмотреть?

Turbid ★★★★★
() автор топика
Ответ на: комментарий от redixin

длинк небось

обновляй libastral

Cisco 3560

Вот настройки портов:

interface GigabitEthernet0/12
 description server B
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 100,101,110
 switchport mode trunk
 switchport nonegotiate
 no cdp enable
 hold-queue 4096 in
 hold-queue 4096 out
end

interface GigabitEthernet0/24
 description server A
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 100,101,110
 switchport mode trunk
 switchport nonegotiate
 no cdp enable
 hold-queue 4096 in
 hold-queue 4096 out
end

Turbid ★★★★★
() автор топика
Ответ на: комментарий от Turbid

hold-queue 4096

зачем это?

вобщем я бы смотрел ту сторону, которая жалуется на фризы. например убрал бы 110 со всех портов кроме 12 и 24, и если пинги начнут бегать ок — значит проблема где то там.

redixin ★★★★
()

У меня на одной гигабитной длинковской карточке отказывается работать 4ый влан, он не отвечает на арп, остальные вланы нормально работают. Ради смеха измени номер влана.

swelf
()
Ответ на: комментарий от redixin

зачем это?

буфер, на случай одновременно попадания пакетов на порт, иначе пока первый пакет будет обрабатываться остальные будут отброшены.

Turbid ★★★★★
() автор топика
Ответ на: комментарий от Turbid

эти серваки вообще в один свитч подключены, оказывается.

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

AS ★★★★★
()
Ответ на: комментарий от Turbid

буфер, на случай одновременно попадания пакетов на порт, иначе пока первый пакет будет обрабатываться остальные будут отброшены.

4.2

кстати, откуда инфа? мне просто поржать

и да, как насчет удалить влан с остальных портов, и убедиться что в остальной сети нет длинков, никто не поднял себе ip/mac сервера, etc

redixin ★★★★
()
Последнее исправление: redixin (всего исправлений: 1)
Ответ на: комментарий от Turbid

Посмотрите загрузку процессора коммутатора.

Коммутатор ничего в логи не пишет? Вобще, провал в 3 секунды, ИМХО, как-то совсем странно — слишком мало для чего-то серьёзного и слишком много для обычных потерь пакетов.

Попробуйте добавить в tcpdump arp-пакеты. Интерестно посмотреть, будут ли непосредственно перед возобновлением ping'а пакеты с arp запросами/ответами. И snmp запросами коммутатор не мучают?

mky ★★★★★
()
Ответ на: комментарий от mky

с arp запросами/ответами

вот это наиболее вероятная причина

redixin ★★★★
()
Ответ на: комментарий от AS

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

Телепорта до датацентра пока не изобрели ;)

Turbid ★★★★★
() автор топика
Ответ на: комментарий от redixin

Кстати, в тему длинков и арп. Жили сервера А и Б, соединенные через cat3550, жили не тужили, была связь через несколько вланов, в том числе через влан 3000 с чем-то, понадобилось поднять этот влан на длинке 2108, включенном в каталист. При создании влана на длинке, связь между серверами по этому влану пропадала. Оказалось, что длинк арп запросы в неизменном(почти, немного нулей добалял в конец пакета) виде отбивает обратно в порт из которого они пришли. В итоге арп ответы каталист посылал уже не серверу сделавшему запрос, а длинку.

swelf
()
Ответ на: комментарий от redixin

кстати, откуда инфа? мне просто поржать

http://blogthefirst.ru/комманда-hold-queue-inout-cisco-зачем-нужна-и-как-работа/

согласен, здесь: http://www.cisco.com/en/US/docs/ios/12_3/interface/command/reference/int_d1g.... немного иначе. завтра дам цисководам разобраться.

и да, как насчет удалить влан с остальных портов, и убедиться что в остальной сети нет длинков, никто не поднял себе ip/mac сервера, etc

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

Turbid ★★★★★
() автор топика
Ответ на: комментарий от Turbid

завтра дам цисководам разобраться

ничего им не нужно давать, и там и там все правильно написано: «Cisco не рекомендует править параметр hold-queue заданный поумолчанию.»

там по дефолту 64, и этого более чем достаточно. оставьте дефолты (no hold queue in (out))

нашел порт, удаление влана с которого решает проблему

так вот где длинк зарыт %)

redixin ★★★★
()
Ответ на: комментарий от Turbid

Предварительно: за этой 3560 еще одна 3560, линк по 10G. А вот уже на второй в логе есть такое:

Jan 15 23:16:16.046: %SPANTREE_VLAN_SW-2-MAX_INSTANCE: Platform limit of 128 STP instances exceeded. No instance created for VLAN131 (port Gi0/17).

а теперь самое интересное - за этим 17-ым портом 100500 вланов, но на порт поленились их прописывать, а просто сделали так:

interface GigabitEthernet0/17
 description ASR_netflow_clients
 switchport trunk encapsulation dot1q
 switchport mode trunk
end

Чую я, истинна где-то рядом. Всем спасибо за советы. Завтра расскажу чем дело кончилось.

Turbid ★★★★★
() автор топика
Последнее исправление: Turbid (всего исправлений: 2)
Ответ на: комментарий от swelf

Оказалось, что длинк арп запросы в неизменном(почти, немного нулей добалял в конец пакета) виде отбивает обратно в порт из которого они пришли.

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

redixin ★★★★
()
Ответ на: комментарий от redixin

Почему запросы не доходят, они доходят с сервера А(пусть порт 1 каталиста) до сервера Б(порт 2), оба они на каталисте висят, но так же они идут на длинк2108(порт 3), на котором влан тоже есть, длинк отбивает обратно этот запрос, в итоге на каталисте теперь мак сервера А висит на порту 3, и каталист ответ от сервера Б посылает именно туда.

swelf
()
Ответ на: комментарий от redixin

Где ты 4.2-то увидел, регистрат? Сбрасывать значения до дефолта через `no` — моветон.

anonymous
()

Как и обещал - разбор полетов.

Дальше по топологии на одной из веток сети, методом отключения на транках глючного VLAN, был обнаружен DES-3200-28, в одном из портов которого был прописан один VLAN, но, внимание!, не тот который глючил. Но в FDB таблице коммутатора с того порта валились маки с глючного VLAN. Отключение порта решило проблему.

Что именно дальше за этим D-Link - хз, т.к. это сеть уже другого оператора.

Turbid ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.