Доброго времени суток!

Как всегда, новая модель коммутатора и маленькие отличия в командах конфигурации.

Использую версию ПО Build 2.61.B021



Нету параметра all. В доке к 3528 написано, что должен быть...



Если я правильно понимаю, то в этой ветке используется новый LBD который определяет петли между портами? Так ли это? Каковы рекомендации по настройке STP и LBD? STP- аплинки, а LDB - клиенты? А то ошибка крайне не информативна:


В pppoe circuit_id_insertion больше нельзя указать на каких портах включать и что передавать. Это навсегда или предполагается сделать как было во всех остальных коммутаторах серий 3550 3028/52 3200-хх? Не нравится потому что при включении этой фичи клиенты с MacOS испытывают сложности с подключением PPPoE (на 3028 серии как минимум). Нормальной диагностики, к сожалению провести не можем, вроде наша ТП должна была такого одного клиента взять под контроль, но веры им нет. Почти всегда помогало выключение этой штуки на порту клиента. Последний раз не помогло, может там с чем другим проблема... В общем хочется что бы можно было выборочно настраивать на портах.

Помнится, была рекомендация по отключению на 3028 серии, при использовании STP, ingress_checking на аплинк портах. Эта рекомендация актуальна и на этой серии?

Ну и последнее: когда предполагается группировать конфиг? А то тяжело рабоать с таким...

Еще раз напоминаю. Все вопросы актуальны.

Кроме этого столкнулись с проблемой. Установили на узел. Имеется кольцо из 12 коммутаторов. 3052, 3200-28, 3526. STP. Один из коммутаторов заменили с 3200-28 на 3552. В результате возникла проблема. Схема такая: 3552 (Build 2.61.B021) стоит в транзите, принимая общее кольцо в порты через SFP. К медным портам в тупики подключены два коммутатора. Один 3052 и второй 3526. Пропадает управление до 3052 и 3526. В логах, чисто (на всех трех коммутаторах), ошибок на интерфейсах нет, только на одном SFP росли дропы пакетов, но это в сторону кольца, а не проблемного коммутатора. Когда пропадает коммутатор на порту вижу трафик, МАС адреса есть во всех вланах, включая управление. Делаю очистку таблицы МАС адресов - коммутатор появляется по управлению. Длится это недолго, порядка 2-3 минут и опять пропадает по управлению. В транзит поставили 3052, в тупик поставили 3552. Все заработало. дропы на интерфейсах SFP пропали. Все коммутаторы доступны по управлению. Выходные прошли - проблем не было. Собираемся собирать стенд и смотреть что к чему. Может подскажите в чем может быть проблема? Может есть какие особенности настройки. Могу выслать конфиг.

Его убрали. Я запросил ШК почему это было сделано.
Насколько критичен этот параметр?

Нет, не определяет.


Да, именно так.

Да, пока в планах нет расширения этого функционала.
Может стоит попытаться выявить проблему с MacOS клиентами?



В ближайших планах нет.

Пришлите мне на почту топологию с номерами портов и указанием откуда производились попытки доступа, конфиги устройств и по возможности вывод команд

с DES-3528 до возникновения проблемы и во время неё. Да, и еще MAC адреса этих двух недоступных коммутаторов.

Не сильно кретичен, но хочется единообразия во всем зоопарке D-Link'ов

А предполагается сделать новый LBD. Как иначе между портами отлавливать петли?

Как раз ей и занимаемся. По факту после прохождения авторизации от агрегатора прилетает LCP с конфигурацией и после этого макинтош делает терминейт сессии. Ему явно не нравится пакет, который приходит от агрегатора, если включена функция PPPoE insertion. Может до конца вечера доразбираемся... пока еще ковыряемся.



Очень плохо. Конфиг практически нечитаем.

Так же обнаружился новый баг при отправке конфигурации коммутатора на tftp сервер.

Похоже на некорректную работу встроенного tftp-клиента.

1. Так отправляют запрос на запись предыдущие модели коммутаторов:
13:04:09.328465 IP xxx-sw-2.xxx.xxx.net.50001 > xxx-rou.xxx.xxx.xxx.net.tftp: 45 WRQ "xxx4-sw-2.xxx.xxx.net.tftp" octet

После имени файла в скобках идут опции (отделяемые 0), в данном случае только одна опция - octet - значит бинарный файл.

2. Так отправляют запрос на запись новые модели коммутаторов:
12:54:35.982110 IP xxx4-sw-3.xxx.xxx.net.50001 > xxx-rou.xxx.xxx.xxx.net.tftp: 75 WRQ "xxx-sw-3.xxx.xxx.net.tftp" octet tsize 0 t

Опций стало больше, дополнительные через 0 вставляются в соответствии с RFC 2347, опция tsize - сколько будет размер файла RFC 2349 (The size of the file to be transfered) и он почему-то передается равным 0 (нулю), естественно на этом tftp-сервер (на базе FreeBSD) больше ничего не принимает. Кроме этого, передается неведомая опция t (не смог найти её в RFC). tftp сервер под windows Tftpd32 version 3.23, работает, а вот при работе с tftpd под FreeBSD возникает проблема.

Похоже, что разобрались с проблемой не подключения компьютеров под управлением MacOS при включении pppoe insertion.

Вот кусок дампа успешной сессии:



А вот дамп сессии, которая устанавливается при включенной pppoe insertion:


Обратите внимание на следование пакетов. При успешной сессии:
PPPoED Active Discovery Initiation (PADI)
PPPoED Active Discovery Offer (PADO)
PPPoED Active Discovery Request (PADR)
PPPoED Active Discovery Session-confirmation (PADS)
PPP LCP Configuration Request
и при неудачной сессии:
PPPoED Active Discovery Initiation (PADI)
PPPoED Active Discovery Offer (PADO)
PPPoED Active Discovery Request (PADR)
PPP LCP Configuration Request
PPPoED Active Discovery Terminate (PADT)
PPPoED Active Discovery Session-confirmation (PADS)

PADS приходит после LCP. Как я понимаю это происходит потому, что PADS попадает на CPU, и немножко задерживается там, а PPP LCP нет. и успевает прилететь вперед. Клиенты на Windows это проглатывают, а MacOS это не принимает и сразу же закрывает сессию, не дождавшись PADS. Даже если на порту выключен инсершен, а включен глобально, то все равно проблема есть. Помогает только глобальное выключение на коммутаторе. Проблеме подвержены 3526 3550 3052, как минимум. Вполне возможно, что и 3200-хх. Функция очень нужная и мы ей активно пользуемся. Хочется что бы проблема была исправлена. Или как минимум что бы если на потру выключена функция. то что бы пакетики с этого порта не попадали в CPU.

Собрали стенд, проблему пока сами подтвердить не можем. Думаем попробовать уменьшить размер кольца, где живет коммутатор и заодно поставить эксперименты всякие. Вывод команд когда коммутатор находится в тупиковой ветке и работает без проблем (не думаю, что ситуация сильно будет отличаться, при включении в кольцо транзитом):




Остальное сейчас почтой отправлю.

Подтверждаю, написал в ШК.

Не могли бы Вы прислать снифы в формате pcap?

Выслал.

Получил.
А по проблеме с недоступностью коммутаторов ничего не получал. Вы отправляли мне конфиги и схему?

Повторно выслал.

Получил

Оказалось, что это не проблема коммутатора, это проблема tftp сервера на FreeBSD.
проблема решается установкой демона /usr/ports/net/freebsd-tftp

А что за такие недокументированные параметры, которые отправляет коммутатор объясните? Знаю что на некоторых других работает (сам об этом написал), но это проблема тех серверов. Ведь они не должны проглатывать неверные параметры, отправляемые коммутатором. Покажите в RFC эти странные параметры....

Эти параметры описаны в RFC2349
Коммутатор действительно шлёт 0 в качестве размера файла, это ошибка и она будет исправлена, но конфиг не заливается не из-за этого, а из-за того, что tftp сервер на FreeBSD 7.2 вообще не поддерживает RFC2349, хотя это и заявлено в man tftpd