Коммутатор не пингует подключенное устройство?

Question

[Леонид]

Итак.
Имеется коммутатор AT-8000GS/24POE (Allied Telesis). 24 порта медных и 4 оптических.
Порты находятся в разных VLAN. Коммутатор также имеет свою подсеть/VLAN.
Проблема - пропала связь с устройствами подключенными на порты под одним VLAN.
Если вытащить патч-корд из коммутатора и подключить к ноутбуку с адресом из потерянной подсети, то устройство видится, пингуется, можно зайти на веб-интерфейс.
Если подключить ноутбук к любому из портов объединённых общей VLAN, то связь с устройством есть.
Индикация портов на коммутаторе также говорит о рабочих линках на портах.

Индикация POE

Правда индикатор POE говорит о

На порту обнаружена перегрузка, короткое замыкание
или воздействие внешнего напряжения

forum.alliedtelesis.ru/MY/Translation/Install_Guid... - 23-я страница.
Но он также мигает раз в 3 сек. Однако устройства на портах POE не потребляют и более сотни в аналогичных случаях работают. Питание на порту отключал.

Однако, если зайти на коммутатор по SSH и дать команду PING на IP проблемного VLAN, то связи нет, таймаут и адрес недоступен.
Порты в режиме access. Линки подтверждаются и программно и аппаратно. ACL нет, адреса статические. Порты помечены как untagged. Уже и не знаю куда смотреть.

Усложняем

Коммутатор находится в стеке с 5-ю аналогичными. Первый, вышеописанный, соединён оптикой с главным оптическим коммутатором.
Оптический порт - trunk, all vlan, в качестве шлюза адрес оптического коммутатора из подсети коммутаторов, который является маршрутизатором (прописаны все VLAN и ассоциируемые с ними IP-адреса). К оптическому подсоединён третий коммутатор AT-8000GS/24POE, а к нему сервер (порт access, проблемный VLAN). Сервер видит устройства на других коммутаторах этого VLAN, пингует их и общий шлюз на оптическом коммутаторе. Виден также проблемный коммутатор. Брандмауэр вырублен, антивируса нет.

С портов проблемного коммутатора сервер из той же подсети не виден. Если прописать проблемный vlan свободный порт другого коммутатора в стеке, то сервер пингуется, однако с сервера подключенное устройство не видно.

UPD 1 Нарисовал примерно диаграмму:

Коммутаторы все видят друг друга, за исключением тех, что не пингуются. Это 2 промежуточных коммутатора, с них пинг идёт, на них нет.
С 10.5.0.110 пинг проходит вплоть до сервера СКУД, в обе стороны, причём с самого коммутатора только до шлюза 10.0.128.1, а ноутбука в 7-ом VLAN вплоть до сервера.
Что сделал: удалил/прописал заново VLAN 7 на 10.5.0.110 - не помогло.

UPD 2 Перекинул проблемные устройства в соседний стэк. Прописал VLAN 7. Заработало. Схема подключения ничем не отличается, настройки те же. Только оптические порты соседние. Буду разбираться и диагностировать порты.

UPD3
Вероятно нашёл проблему, но решить пока не могу. Уточнение шлюз AT-x610-24SPs/X IP 10.5.0.1 Layer 3
В обоих промежуточных коммутаторах 10.5.0.92 и 10.5.0.97 в качестве шлюза указан 10.5.0.0. ARP таблицы обоих пусты.
forum.alliedtelesis.ru/viewtopic.php?f=6&t=3349 Задал вопрос на форуме производителя.

Destination Mask NextHop Interface Protocol

--------------------------------------------------------------------

10.5.0.0 255.255.255.0 10.5.0.92 vlan5-0 INTERFACE

UPD4
Клубок стал распутываться. Ключом стало значение: Destination 10.5.0.0
10.5.0.0 - указан как шлюз. Стал разбираться - а может быть в сети устройство с таким адресом - оказалось нет.
10.5.0.0 - это зарезервированный адрес сети 10.5.0.1-10.5.0.254
Стало быть шлюз не указан вообще.
Это говорит лично мне о том, что маршрутизация на крутом управляемом коммутаторе работает как на тупом хабе, ну или полу-тупом.
Далее: коммутаторы 10.5.0.92 и 10.5.0.97 - оптические, всего с 4-мя резервными(дублирующими) медными портами. Просто так к ним не подключишься. В сети их нет.
Подключился через SSH c помощью преобразователя USB на консольный порт. Выдернул один из транковых оптических портов. Переделал транковый медный порт дублирующий на режим access. Подключился ноутбуком с установленным адресом 10.5.0.15 255.255.255.0 - связи нет. Прописал шлюзом 10.5.0.92 (на нём экспериментировал) и ВУАЛЯ!

Пинга с коммутатором нет, зато нашлись несколько подобных устройств, которых не было видно в сети 10.5.0.0.
Потом удалось сравнить конфиг 10.5.0.92 с полностью аналогичным коммутатором. Нашлось много левых настроек.
Допустим: после команды show ip route
проблемном 92-ом отображается Interface vlan5 , а на аналоге Interface vlan5-0
Хотя во всех других местах VLAN5 отображается одинаково.

В итоге мы имеем отсутствие прописанных шлюзов и , возможно, сегментацию сети, как писал nApoBo3 в комментариях.

Comments

[nApoBo3]

Ping работает на l3, значит у коммутатора должен быть ip и он должен быть привязан к интерфейсу, вероятно если не проходит ping, значит между этими интерфейсами отсутствует "связность" на l3. Если ip коммутатора в той же подсети, что и конечного устройства он будет искать по мак таблице и интерфейс коммутатора должен быть в таком случае в том же vlan. Но это теория, как на практике у Allied Telesis оно работает я не подскажу.

[hint000]

Много деталей, такое сложно раскурить, просто проходя мимо. Нужен или удалённый доступ или физический доступ. Казалось бы - на фриланс, так ведь нет же. Похоже, сеть немаленькая, и на фриланс такое отдавать рисковано. Остаётся вариант обратиться к системному интегратору. Три шкуры сдерут, но хотя бы решат и не завалят всю сеть.
P.S. Рисуйте наглядную схему, её очень не хватает при множестве деталей. Я понимаю, у вас эта схема в голове, но у нас-то - нет. :)

[Леонид]

hint000, Хорошо. Попробую. Я просто не могу понять - при тех же условиях другое оборудование работает и связь есть. Настройки абсолютно одинаковые.
Есть ещё нюанс - линия была медный коммутатор - оптический1 - оптический главный - медный. По сети коммутаторов оптический1 нет связи. Однако всё работает. Остальные коммутаторы видят друг друга. Решил убрать оптический1. Перенастроил и переподключил проблемную линию сразу на главный. Но ситуация не изменилась.

[Леонид]

nApoBo3, Хорошо. Т.е. при наличии разных VLAN на коммутаторе L2 и отсутствии головного L3 маршрутизатора пинг между разными VLAN в пределах одного коммутатора ходить не обязан.
Можно ли выяснить причину отсутвия ответа если пинг в одну сторону от одного оконечного устройства до другого проходит, а назад только до шлюза?

[nApoBo3]

Леонид, у вас очень запутанное описание и похоже вы путаетесь в терминах. Нарисуйте l2 и l3 схемы, так будет понятнее.
Если пакет в одну сторону проходит, а обратно нет, то дело или в маршрутах или в фаерволе.
Гипотетически, ещё может быть хитрый косяк с вланами, когда у вас пакеты в одну сторону теряю vlan и доходят, а обратно маркируются и не доходят, но с ходу такую конфигурацию не распишу, и не уверен, что она вообще возможна.

[Леонид]

nApoBo3, Схему нарисовал, уж как умею.

[nApoBo3]

Леонид, в каких vlan находятся указанные ip адреса?
С каких ip на какие не ходит пинг?

[Леонид]

nApoBo3,
Подсеть СКУД VLAN 7 10.0.128.1 - 10.0.192.254
С порта подключения контроллера я могу пропинговать сервер. Обратно нет.
Подсеть коммутаторов VLAN 5 10.5.0.1 - 10.5.0.254
Не пингуется два промежуточных коммутатора в обе стороны.
Если поставить на ноутбуке адрес контроллера 10.0.145.65, то пинг идёт до сервера, за исключением промежуточных коммутаторов 10.5.0.92, 10.5.0.97.
Если с сервера 10.0.128.3 пинговать, то не видны 10.0.145.65, 10.5.0.92 и 10.5.0.97
Пока мысли что проблема в промежуточных коммутаторах, но остальные VLAN на них работают, причём тот же СКУД.

[fpir]

Леонид, Слушайте, а с производительностью свичей всё хорошо? Была похожая непонятная ситуация, когда свич не тянул всю маршрутизацию. Снизил нагрузку на процессор-память, всё заработало.
А пинги на свичи, когда они доходят, ровные?

[Леонид]

fpir, Насчёт загруженности, скорее всего нет, сеть не нагружена, да и работала почти год.
Пинги ровные и одинаковые.

[fpir]

Леонид, У меня по каналам тоже было свободно, упиралось в производительность самого свича. Он маршрутизировал 6 VLANов с, порядка, 100 устройств, типа СКУД, камер, VoIP. Завёл маршрутизацию 2х VLAN на другой свич и всё заработало нормально.

[nApoBo3]

Леонид,
1. Проверьте, что при пинге с 10.0.145.65 на 10.0.128.3 пингуется именно ваш СКУД сервер, возможно у вас не один такой адрес в сети.
2. Поправьте маску в СКУД сети( по меньшей мере на 10.0.145.65 и 10.0.128.3 ). С такой маской с 10.0.128.3 и не должен пинговаться 10.5.0.92 и 10.5.0.97.
3. Распишите нормально пинги. На схеме пронумеруйте коммутаторы.
Формат типа такого: ip адрес x.x.x.x порт номер 20 коммутатора 4 VLAN7 пинг на y.y.y.y порт номер 15 коммутатора 7 VLAN 7 не проходит/проходит.
4. Судя по всему( описание у вас очень много деталей опускает ) пинги у вас не проходят через l3 коммутатор когда пинг должен идти по "l2 уровню"( одна подсеть ). Значит у вас на нем нет "коммутации" на l2 уровне, т.е. у вас фактически два раздельных VLAN7 разделенных l3 коммутатором. Но в этом я не уверен.

[Леонид]

nApoBo3,
1. Отключал, пинговал, один адрес -иначе ничего бы не работало.
2. Как я написал в уточнении, в других подобных случаях всё работает, отличается только стеки. ARP-таблицы промежуточных коммутаторов пусты.
4. Действительно VLAN7 могут быть разными, но тогда неясно, почему другие стеки подключенные на коммутатор 10.5.0.92 работают без проблем.

[nApoBo3]

Леонид, Какие остальные стеки, у вас она схеме один стек? Что значит работают без проблем, пинг вообще не показатель, что что-то работает или нет.
Я до сих пор не понимаю от куда куда у вас не идут/идут пинг.
Если какие-то остальные стеки работают, значит они или имеют отличая на l3 уровне или на l2( вместе с "l1" ).
Но судя по текущему описанию у вас отсутствует l2 связность через 10.5.0.1. При таком сценарии, все что идет через шлюзы будет работать, а все что работает в рамках локальной подсети будет работать только в зоне разделенной l3 коммутатором.

[Леонид]

nApoBo3,
1. Фактически к коммутатору 10.5.0.92 подключено 7 стеков коммутаторов (10.5.0.104 - 10.5.0.110). По функционалу, настройкам, подключенным устройствам они идентичны. Проще говоря каждый стек - это 1 этаж здания.
2. Работают без проблем - 7 идентичных устройств при одинаковых настройках подключены к ядру (10.5.0.92). Но почему-то проблема есть только на одном. Думал проблема в стеке и устройствах СКУД, но после переключения последних в соседний стек (на схеме не показан 10.5.0.109) линки поднялись.
3. Максимально упрощая схему и задачу:
Имеем три коммутатора 10.5.0.110(конечный) ---10.5.0.92(промежуточный)---10.5.1.1(маршрутизатор)
Конечный не видит промежуточный, но видит маршрутизатор.
Промежуточный видит только маршрутизатор
Маршрутизатор видит конечный, но не видит промежуточный.

В итоге мы имеем что промежуточный не виден с обоих концов, но концы видят друг друга.

[nApoBo3]

Леонид, нет в сети такого "видит", в сети есть только пакет( ну еще состояние ).
Пакет может ходить не разных уровнях, условно l2, l3 и т.д. ( очень условные уровни ).
На l2 сеть сегментируется VLAN и физическими устройствами.
На l3 адресами и масками( ну еще межсетевыми экранами ).
Адреса в сети которые вы указали ничего не говорят ни о l2 топологии( может быть между ними просто нет линка на l2 ), ни о l3( для этого еще нужны маски и маршруты ).
Вы упускаете из задачи значимые детали.

Если у вас ping c 10.5.0.92 до 10.5.1.1 идет, а пинг с 10.5.1.1 до 10.5.0.92 нет. То вы упускаете какую-то значимую диагностическую деталь. Это может быть или, что эти адреса разные( адреса одинаковые, но привязаны к разным устройствам или в реальности вы ping делает не этого адреса, а другого адреса того же устройства ), или где-то вы работаете с пакетами( фаервол, NAT, прямая модификация пакетов и т.д. ).
Если ping идет в одну сторону, то он должен идти и в обратную( поскольку пакеты они при ping идут и туда и обратно ) если нигде в трафик руками по дороге не вмешиваться.

Пример:
10.5.0.92 вообще не отвечает на ping
10.5.0.92 и 10.5.0.110 находятся в разных l2 сегментах и имеют маски 16.
10.5.1.1 имеет маску 16 и находится в двух l2 сегментах имеющих связность с 10.5.0.92 и 10.5.0.110 соответвенно.

В такой конфигурации у вас будет именно такая картина.
10.5.0.92 может пинговать 10.5.1.1.
10.5.0.92 не может пинговать 10.5.0.110
10.5.1.1 может пинговать 10.5.0.110
10.5.1.1 не может пинговать 10.5.0.92
10.5.0.110 может пинговать 10.5.1.1.
10.5.0.110 не может пинговать 10.5.0.92

[Леонид]

nApoBo3, Спасибо за то, что отвечаете на мои вопросы и находите время. Ответом ранее я немного ошибся, главный коммутатор имеет адрес 10.5.0.1/24. Остальные коммутаторы имеют тот же префикс и ту же подсеть. Однако буду проверять ещё раз.

Answer 1

[Денис Сечин]

Начнём с простого маки на порту проблемного влана есть ? Пинг вообще откуда делаешь с коммутатора доступа ? У него что терминалия нескольких вланов?

Comments

[Леонид]

@deni4ka, Маки отсутствуют. То бишь получается что проблемный коммутатор не видит их на подключенных устройствах.
Пинг делал со всех коммутаторов проблемной линии. Проблемное устройство не пингуется. Пинг есть только в пределах ближайшего оконечного коммутатора, к которому подключено оконечное устройство и только в пределах портов под одним VLAN.
Не совсем понимаю "терминалия"...

[Денис Сечин]

Леонид, а этот аксесный порт на котором нет маков, что находится за ним ?

[Леонид]

Денис Сечин, Контроллер СКУД от Perco CT/L04.
7 портов на проблемном, главном коммутаторе в стеке, 4 на соседнем. Соседний коммутатор маки своих четырех контроллеров видит, но ситуация та же. В сети их нет.

[Денис Сечин]

Леонид, просьба нарисовать схему включения можно в draw.io

[Леонид]

Денис Сечин, Обновил вопрос.

Answer 2

[Drno]

Вы написали что комутатор сообщает о проблеме POE.
Прозвоните кабель, подключите с другой стороны от комутатора другое устройство с poe, для проверки
Принисите нерабочее устройство к комутатору и присоедените корртким патч кордом...

Ноут работает, тк не проверяется «живо» ли poe
Проверьте физически кабель, обжатия

Comments

[Леонид]

Кабель целый. LAN Tester - всё норма, связь с устройством есть. Устройства не POE. До отключения питания - постоянно искали потребителя.
Устройство работает и на коротком кабеле и на длинном.
Обжатия норм, единственно удивляет на прямом кабеле индикация порта на коммутаторе MDIX (кроссовер) вместо MDI (прямой). Но уже год в сотне случаев работает без проблем.