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

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

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

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

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

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

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

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

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

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

tcpdump

и пройти по топологии

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

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

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

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

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

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

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

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

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

Запустите на «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 больше?

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

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

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

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

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

длинк небось

длинк небось

обновляй 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

hold-queue 4096

зачем это?

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

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

зачем это?

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

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

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

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

4.2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предварительно: за этой 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

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

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

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

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

Не no hold…, а default hold…

Не no hold…, а default hold…

4.2. не ожидал такого от анонимуса

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

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

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

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