dmih

У меня все таки специфика - колхозного уровня СХД. Под это дело можно любой свитч приспособить, если он вообще включается. Не показатель. Там у них у всех написано "на агрегацию". Вот пусть это железо ктонить на агрегацию поставит, тогда и посмотрим. Лично у меня проблема 10g потеряла остроту, потому что начинает появляться адекватное Б/У. Я на фоне Нексуса на это дело больше даже смотреть не могу и не хочу и не вижу смысла. Причём он их даже на отказ переработает явно. Но так вообще тысяч за 60 будет хороший вариант, может быть. Или если политика разрешает только новое. ... Но по-моему новый как то меньше на агрегацию похож по спекам.

Если вы сможете гарантировать ТОЛЬКО валидные пакеты на всех портах (например, проверяют трансиверы и вы в этом точно уверены), то как чисто L2 свитч не будет никаких проблем в его работе. Любой функционал кроме самого минимального L2 на уровне LACP/VLAN/и-всё тут под вопросом - там много чего реализовано, но у меня лично при попытке чем-либо воспользоваться сплошные неудачи. Это прошивка которая на 2blabla начинается. В теме мелькает прошивка с номером 3blabla. Может там что лучше. ... и да, есть подозрение что flow control там тоже не пашет - с ним у свитча клинит всю 10G матрицу и это надежно воссоздается.

и как передача данных между серверами и СХД реагировали на такой процент потерь, это же постоянные повторные запросы/передачи Вообще, современный TCP с таким процентом потерь работает достаточно нормально, я бы сказал, что 0.1% не замечается. Есть разные школы так сказать построения сетей, некоторые считают что потерь должно быть 0% и точка, некоторые на это смотрят чисто практически и не запариваются. Если чисто практически, то 0.1% в худшем случае, а скорее даже гораздо меньше, то для TCP протоколов это нормальное состояние канала, которое на качество связи никак не влияет. DAC провода надо короче брать, тогда потерь нет. Если всё самое бюджетное, и свитч, и провода, то 5 метров для DAC это перебор. С более короткими проводами проблем нет, а 5 метров это лотерея, видимо там уже надо ставить дешевую оптику. ВООБЩЕ ДАВАЙТЕ Я ВЫСКАЖУ ВАЖНОЕ РЕЗЮМЕ, т.к. теме два года скоро. Всё написанное тут остается в силе, шаг вправо, шаг влево, фигня какая-то начинается. Практически вообще всё, что я на них пробовал, приходилось выключать, и зачатки QoS которые там есть, и что угодно, всё это просто надо выключить и всё, без вариантов. Но в самой простейшей конфигурации - СВИТЧИ АБСОЛЮТНО РАБОЧИЕ, не виснут, трафик пропускают исправно, каких-либо проблем в их работе нет. VLAN-ы и truncи работают нормально, LACP тоже, и между собой, и с Catalyst-ами. Еще такой отзыв, я только два порта им сжег то ли статикой то ли не знаю, тоже надо иметь в виду, но это тоже особенность DAC. Если порт недорогой, то вставлять не дыша и ни в коем случае не создавать никаких лишних потенциалов на шине данных и так далее (равномерное заземление, отсутствие свободных концов и т.д.). Тем не менее у меня даже в условиях стоечного дата-центра и проводов на 5 метров удалось два порта сжечь. Никакой защиты от обычных КМОП болячек там судя по всему нет, либо она очень слабая.

Я прошил оба свитча на 2.1.1B_28087 и подтверждаю, что с командой sfp-mode copper снижается количество ошибок на портах SFP+ DAC 5 метров, в моих условиях, примерно в 10 раз. К сожалению никак не до нуля. С более ранней прошивкой и без spf-mode copper типично было 1-2% ошибок, а в режиме sfp-mode ошибок в районе 0.1%. Ноль бывает редко. Метод измерения ошибок следующий - ping -i 0.02 -c 1000 -s 9000 -n 10.21.0.75 |grep loss В целом можно сказать, что DAC соединения теперь свитчем поддерживаются значительно лучше, практически совсем норма. Раньше с DAC от 1-2% (типично) до полной неработы (редко, но было) - это была явная фигня, а 28087 и sfp-mode copper - от 0% до 0.1%.

Ну и если уж к слову, я правильно понимаю, что ограничить максимальное кол-во выученных MAC на порту можно через switchport port-security mode dynamic switchport port-security dynamic maximum NNN ? В принципе если там везде поставить разумные значения, то вероятность аварии конечно становится почти нулевой. UPDATE: ну и собственно отчасти правильно вам конечно пишут: убеждать всех, что непроверяемый CRC пакетов не мешает и таких пакетов в сети быть не должно - конечно можно, но не нужно: не поймут (а у некоторых вообще истерика будет в этом месте). Но есть очевидные workaround-ы по разному ограничению обучения, которые проблему действительно переводят в разряд теоретической (с эффективным уменьшением размера таблицы конечно, но тут уж извините). Признать дефект - дефектом, и предложить какие-то идеи на эту тему, хотя бы на форуме, было бы хорошим шагом. Идеалистов тут нет, тут половина посетителей по делу, это какие-то провайдеры, которым дело делать надо, они поймут и простят. Вот меня например это не парит, нужно будет еще 10G, еще таких чудо-вещей у вас куплю. Но должны же быть принципы нормальной поддержки какие-то. Где информация по проблеме, кроме как в частном тикете? Например вот хороший вопрос - какие еще служебные пакеты принимаются в работу без проверки CRC? Там результат может быть значительно хуже, чем левый MAC на порту.

Михаил, в целом понятно, что со свитчем работать можно, и случай, когда CRC ошибки в таком количестве, редкий. Хотя я его на ура у себя имею, до нескольких тысяч невалидных MAC-ов в таблице, пока не выключил обучение. Но всё же это конечно не норма. Отличие всего лишь в том, что в таком случае проводить аварийные работы надо на порту. И это нормально. В нашем же случае есть хороший шанс начать проводить аварийные работы сразу на всём свитче или даже на всем L2 сегменте, если в результате коллизий какой-нибудь управляющий пакет не туда залетит. То, что вероятность этого довольно низкая, правда. Но сама постановка вопроса такого типа затрудняет классификацию этого свитча как нормальное оборудование в общепринятом смысле. Трансивер, или провод, или кто угодно еще, может гнать /dev/random в порт, это бывает, потому что такого оборудования тупо по количеству много, оно оптимизировано на цену, и там что угодно случается, в том числе я лично это видел. И то, что у нас это с гарантией приведет к зависанию всего свитча, это ненормально.

Это же его где-то надо взять для начала. Ну как бы с одной стороны да, с другой стороны нет. Я например выключил обучение и чисто практически меня не парит. В сетях хранения например полтора MAC-а на всю сеть, их руками забить - только надежности больше будет. Но с формальной точки зрения вы конечно правы. Я поэтому и пишу постоянно, что это, строго говоря, в текущем виде - вообще не свитч.

Это откуда вообще такие фантазии? Вы на 10G оборудование цены смотрели? :)

Я что-то не очень понял, почему вы это оборудование называете дорогим. Это свитч с 12-ю 10G SFP+ портами. По такой цене, по которой в этом свитче они есть, их в принципе в природе не бывает. И при том, что это не муляж, а реально работающие порты. Любая нормальная аппаратура с 10G портами стоит в 2-3 раза дороже минимум. По меркам нормальной аппаратуры, это конечно не свитч, а не знаю как назвать. Даже DLink на этом фоне, с их альтернативно-одаренным ПО, как свитч на порядок лучше, потому что тут вся документация состоит из фраз "команда enable mega feature 25 включает mega feature в режиме 25" без каких-то пояснений, с IOS-ом совпадает дай бог половина, а половина команд вообще не работает. Про аппаратные особенности уже молчу. Но по меркам просто некой железки, которая максимально бюджетно соединяет 10G порты, это довольно добротная вещь. Ответы на вопросы, 1) На что ориентировался - см. абзац выше, 2) В одном месте. 3) Гигабитных SFP там нет. 4) 10 гигабитные (SFP+) там 12 штук и опять же см выше, в них и суть, 5) Задействованы не все порты. Штук 6 на каждой железке (из 12-ти). Еще я начал там в отдельном VLAN-е гонять обычные гигабитные порты. Свитч как свитч - пакеты, опять же, ходят. UPDATE: я так немного резко что ли пишу про этот свитч потому, что надо понимать, с чем столкнется его пользователь. Тем не менее телеком должен быть эффективен по деньгам в том числе. В каждый сарай и стойку Cisco не поставишь, а 10G хочется. И из этих соображений - в прямом соответствии с рекламой - этот свитч делает ровно то, для чего его и запланировали - обеспечивает низкую цену 10G портов, которые, в целом, работают. Собственно всё. Если другие какие-то задачи есть, нужен конечно другой свитч, это 100% (IMHO).

Я бы не стал так категорично, дело в том, что 1) через него ходят байты (включая в пакетах по 9k), 2) если его аккуратно настроить, то раз в месяц не виснет, 3) он стоит меньше ста тысяч рублей! То, что свитч при этом долбанутый на всю голову, это конечно плохо, но у него очевидно есть определенная ниша, в которой он довольно близок и идеалу. Скажем если мне потребуется дальше расширять локальную 10G чисто транспортную сеть с средне-низкой ответственностью, почему нет? Я прямо таки уверен, что NAG сделал отличную вещь для своей определенной ниши, и рад, что такой девайс есть. Надо просто правильно понимать его позицию в общей экосистеме.

В тикет написали, что вопрос с непроверяемой CRC на ARP зашит аппаратно "для скорости" и решить его нельзя. Остается вопрос про криво сделанный flow control, но тут рядом тоже есть тема с бесконечно возрастающими pause фреймами на другой какой-то железке, из которого можно сделать предварительный вывод, что это тоже в консерватории у архитекторов и не лечится. Ну что тут можно сказать, будем работать как есть.

Из тикета: --- Добрый день, по MAC learning, выяснили что если пакет более 256 байт, чипсет сначала изучает МАК-адрес из него и только потом проверяет чексумму, сейчас разработчики думают как это обойти. В принципе при штатной работе коммутатора, когда CRC ошибок на линке нет или небольшое количество это никак не проявляется. Проблемы могу возникнуть при большом кол-ве CRC на линке, если случайно в поврежденном пакете будет мак совпадающий с маком с другого порта. Ориентировочный срок решения 1 месяц. ---

После отключения Flow Control и со статическими MAC-ами портов железка поживает нормально, ну по крайней мере вот аптайм 3 месяца состоялся. Согласно информации в тикете, выпустили прошивку, которая лечит проблемы ненадежной работы с DAC кабелями, вероятно там тюнятся электрические параметры портов под это дело. NAG говорит, что на стенде всё ОК с ними стало (а со старой прошивкой у них вообще не работало). Я пока не прошивал. Теоретически, если связь улучшится и битые MAC-и перестанут прилетать в диком количестве, можно будет вернуть динамическое обучение, ну всё равно плохо что CRC на ARP не проверяется, но с нормальными линками количество в качество переходить не будет и можно жить. В целом в любом случае я бы предпочел дождаться прошивки, которая проверяет CRC на ARP, потому что когда у меня CAM таблица состоит из мусора, я несколько очкую в любом случае, вне зависимости от их кол-ва, поэтому и не обновляюсь пока (тем более там продакшен какой-никакой, я теперь уже боюсь эти девайсы трогать). В целом верной дорогой идем товарищи, но пока IMHO не дошли.

Тут немного прояснилось, поэтому я прорезюмирую, чтобы тема не провисала. 1) Свитч плохо работает с SFP+ DAC проводами. У меня в принципе приемлемо (<1% потерь и ошибок) работают 5-метровы провода от SNR, на разных портах с разным успехом. Бывают линки с 0% потерь, бывают линки с 10% потерь (редко), но в целом всё работает. Всегда можно найти такое сочетание порт-провод-порт, чтобы линк работал с достаточным качеством. 2) Тем не менее, на стендах у SNR 5-метровые провода не завелись совсем, а на 3-метровых кол-во ошибок велико. Из этого можно сделать вывод, что, в принципе, этот свитч DAC не тянет и ему желательно только трансиверы. Это рекомендация саппорта SNR и разработчиков. 3) Свитч не смущает битый CRC на ARP пакетах, поэтому если есть ЛЮБОЙ природы CRC ошибки в пакетах, в CAM таблицу попадает любая лабуда: как пакет прошел, такой MAC в таблицу и встал. Это воссоздается у SNR. Сейчас разработчики занимаются вопросом. Но, в принципе, если вы не можете гарантировать 0.0% битых пакетов, свитч опасно использовать в обычном режиме. Я лично решил проблему так - переключил его на статическое обучение. Это не очень удобно, но в моих условиях ОК. 4) Зависание свитчей оказалось особенностью работы flow control. Проблема достоверно сведена к тому, что определенный линк, при включенном на порте flow control, кладет свитч (воткнул – кладет, вынул – дальше работает, и так сколько хочешь раз, эффект стабилен). И если свитч попал в такое состояние, то это длится до тех пор, пока не отключишь flow control на ВСЕХ портах (иначе порт не возвращается к работе). После чего н из такого состояния выходит и можно повторять включение flow control, до следующего раза. Сетевая карта на другом конце в данном случае была Intel X710. Карта предположительно не зависала и вообще не была в курсе, что у свитча такая беда, никаких признаков, что она является источником проблем, я не нашел. В любом случае, «полностью неблокирующая матрица» из рекламы на этом фоне выглядит шуткой юмора – матрица очевидно блокируется целиком при некоторых условиях на одном из портов. Я пока решил проблему так – отключил везде flow control. К сожалению, для свитча, где прямо внутри есть перепад скоростей 10G->1G (там 8 1G портов), это какое-то странное решение, для такого перепада flow control желателен даже самый кривой просто на всякий случай (не говоря уж порт-порт, но это я размечтался ;) 5) Таким образом, свитч своих денег определенно стоит, но надо иметь в виду, что это, по-моему, не канальный свитч общего назначения, а такое нечто непонятно что, с которым надо трепетно и бережно. Возможно, следующие прошивки это исправят, хотя тут есть определенные сомнения. 6) Поддержка SNR работает хорошо, мне понравилось. Как-то так.

Тот же свитч снова завис (неделю примерно проработал). В syslog-е пусто. Обучение MAC-ов было отключено, так что проблема не в них. Начинаю подозревать дефектный экземпляр. Запросил в тикет что может его просто поменять. Второй такой же свитч нормально пока работает, 40 дней уже :) UDATE: да, если уж тема такая зашла, на 40-й день аптайма в веб-интерфейс там вообще войти нельзя. Выглядит это так, открываешь браузер, и Reply from 10.21.0.11: bytes=32 time<1ms TTL=255 Reply from 10.21.0.11: bytes=32 time<1ms TTL=255 Reply from 10.21.0.11: bytes=32 time<1ms TTL=255 Reply from 10.21.0.11: bytes=32 time<1ms TTL=255 Request timed out. Request timed out. Reply from 10.21.0.91: Destination host unreachable. Request timed out. .. и короче примерно на минуту. Потом отвисает. Передаче данных это не мешает. Через telnet тоже ходить можно :), ну, понятно, когда он вообще пингуется. Так, чисто в копилку особенностей железки. Текущая прошивка 2.1.1B build 25329 это не чинит. Я собственно боюсь, как бы там его ОС совсем не заклинило в очередной момент, поэтому на всякий случай в тикет это тоже написал.