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 это не чинит. Я собственно боюсь, как бы там его ОС совсем не заклинило в очередной момент, поэтому на всякий случай в тикет это тоже написал.

Производитель пишет в тикет, куда я всё это продублировал, так что всё нормально. Тикет пока открыт и там идет общение. И вообще надо понимать, что вне зависимости от качества этого свитча, проблема плохо решаемая. У кого-то что-то там повисло - ??? Что тут писать? Писать только свой опыт можно. Публично опыта нет, да и откуда ему взяться, свитчу 3 месяца. Бардак с MAC-ами я так понимаю они попытаются воссоздать у себя. Думаю, получится, т.к. всё оборудование SNR. Пока по этому вопросу информации нет. >>Хмм, один из топовых свичей Ну и это конечно под большим вопросом. Менее топового свитча я пока не видел :) Прелесть этого решения в цена/качество. Причем при такой цене, в принципе, качество имеет право быть сколь угодно низким. Это всё равно остается нормальным решением. По цене одного Nexus-а можно 8 таких свитчей купить. Это должно говорить же о чем-то, это просто крайне эффективное решение, а то, что при этом надо еще пилить и разбираться, объяснимые издержки.

Не ну так с виду нормальная вещь, за 100 тысяч я даже готов прописывать MAC-и вручную :) Лишь бы не висло. Любое самое дебильное поведение можно терпеть, если оно предсказуемо. Хотя я вот тут уже на watchdog электророзетки поглядываю... :) Надо доводить до ума железку, чего уж там, и будет супер. Другой вопрос, откуда она вообще взялась и какие там возможны варианты по доводу до ума. Но вот заодно и посмотрим.

В качестве финального слова (и это последнее моё сообщение до 30 марта 2015 - 18:55, если не вмешается модератор ;) 1) Оба свитча с обоими прошивками, и 2.1.1B build 20219, и 2.1.1B build 25329, периодически генерируют левые MAC адреса на ЛЮБЫХ портах. Чаще всего - на портах свитч-свитч, но в общем-то, как показало пристальное наблюдение, не обязательно. Иногда это случается с обычными портами, где сетевая карта с другой стороны, X520 или X710, причем там может быть как Windows, так и Linux, как хост виртуализации (MAC-и в принципе могут быть левые), так и просто тестовая система без всего вообще (MAC-и точно подменять не может). 2) Кол-во инвалидных MAC-ов на порту примерно пропорционально трафику на порту. 3) Кол-во инвалидных MAC-ов на порту НЕ связано с отображаемыми на портах ошибками (они достоверно есть и на портах, где 0 ошибок). 4) Эту чудо-вещь можно привести в состояние статического обучения с помощью команд, аналогичных switchport port-security mode static accept и mac address-table static 6805.ca30.5c39 vlan 1 interface tg1/2 (пишу на заметку, потому что инструкция на всю голову, простите, описаний команд нет, и IOS-у там ничего дословно не соответствует, догадывайся как хочешь). После этого я прописал все свои 16 хостов везде статически и заполнение таблиц случайными адресами таким образом прекратил. О комфорте работы свитча в таком режиме вы сами догадываетесь. Хотя в моем сценарии это будет терпимо, ну максимум в этом сегменте будет 50-100 хостов, ну что я их, руками не перепишу на все свитчи? ;) да легко. 5) Мне тем не менее НЕ кажется, что это поведение непосредственно привело к зависанию свитча. Таблица там кажется 32k, а я не видел этих MAC-ов больше сотни. Aging у них нормально работает, поэтому они со временем пропадают. UPDATE: тем более, если не помог reset с передней панели, вероятно проблема где-то в другом месте. 6) Тем не менее, мне кажется, что свитч, у которого БАЗОВЫЙ функционал работает таким вот образом, (по крайней мере в сочетании с DA SFP+ от SNR-а же, пир судя по всему не важен, если в 710 я еще могу поверить, то в 520 нет), может виснуть и по любой другой причине. Что очень конечно печалит.

И чтобы два раза не вставать. По итогам изучения обстановки обнаружилось следующее. Свитч, который не перезагружался (рядом с первым), свитч N1, в show mac address-table показывает какую-то ерунду на порте того свитча N2, который зависал. Вот фрагмент вывода. .. 1 6805.ca30.5c39 DYNAMIC tg1/2 1 6805.da30.dc75 DYNAMIC tg1/2 1 6805.ca30.9c74 DYNAMIC tg1/2 1 6805.ca30.5c75 DYNAMIC tg1/2 1 6805.ca30.5c55 DYNAMIC tg1/2 1 3031.13af.b7f1 DYNAMIC tg1/2 1 964e.31f3.5b4d DYNAMIC tg1/2 1 6805.ca30.5e75 DYNAMIC tg1/2 1 d0d5.1704.016b DYNAMIC tg1/2 1 04e2.db70.faf5 DYNAMIC tg1/2 1 d013.c83f.0d81 DYNAMIC tg1/2 1 5e3e.04cd.22dd DYNAMIC tg1/2 1 aa3a.e3a7.1e12 DYNAMIC tg1/2 1 9203.00d5.2301 DYNAMIC tg1/2 1 000a.1201.2528 DYNAMIC tg1/2 1 90e2.ba89.e4f1 DYNAMIC tg1/2 1 7e06.ba49.139a DYNAMIC tg1/2 1 8a14.0100.e61b DYNAMIC tg1/2 1 e25d.43ac.cc02 DYNAMIC tg1/2 1 2a38.9da7.effe DYNAMIC tg1/2 1 0032.0ca5.8001 DYNAMIC tg1/2 1 0000.0070.a9d3 DYNAMIC tg1/2 1 cccc.8b46.0c85 DYNAMIC tg1/2 1 8eec.0597.5f5b DYNAMIC tg1/2 1 7200.106a.01e8 DYNAMIC tg1/2 1 401a.d87f.1a12 DYNAMIC tg1/2 1 0006.062a.1e02 DYNAMIC tg1/2 1 1891.3a97.1e80 DYNAMIC tg1/2 1 6ead.d09b.98c0 DYNAMIC tg1/2 1 2420.0131.003b DYNAMIC tg1/2 1 2ec0.c0a6.c0bf DYNAMIC tg1/2 1 8000.09cb.0000 DYNAMIC tg1/11 1 6885.c530.2075 DYNAMIC tg1/2 1 b847.8789.e565 DYNAMIC tg1/2 .. итого 37 адресов. Вот тут можно разглядеть как нормальные MAC адреса Intel-овых карт, так и какую-то лабуду в стиле 0000.0070.a9d3, cccc.8b46.0c85, 7200.106a.01e8, 0000.0000.0000 и так далее. Таких адресов в сети конечно нет и на этот интерфейс попасть они не могли. На свитче N2, который ребутился, картина следующая: Vlan Mac Address Type Ports ---- ----------- ---- ----- 1 08fa.3360.e16e DYNAMIC tg1/1 1 6805.ca30.5bc9 DYNAMIC tg1/1 1 90e2.ba89.f5d1 DYNAMIC tg1/1 1 90e2.ba89.e93d DYNAMIC tg1/1 1 f8f0.8274.003f DYNAMIC tg1/1 1 c63a.a620.107e DYNAMIC tg1/1 1 6805.ca30.5c39 DYNAMIC tg1/3 1 6805.ca30.5c75 DYNAMIC tg1/5 1 ea18.99b4.9e58 DYNAMIC tg1/1 1 6805.ca30.5fc9 DYNAMIC tg1/1 1 90e2.ba89.e4f1 DYNAMIC tg1/7 1 90e2.ba89.e2a1 DYNAMIC tg1/1 Ну т.е. именно примерно такие адреса должны быть на свитче N1. Пока я пишу этот пост, кол-во ненормалных MAC адресов постоянно плавает. Нормальных адресов в сети скажем примерно 15. 20 минут назад таблица MAC-ов была 37 штук. Потом сократилась до 25. Сейчас вот снова 35 штук. Через минуту - 53 штуки! На свитче N2 с этой таблицей всё в норме, лишних адресов нет. При этом, ненормальные MAC адреса появляются строго на порту, куда воткнут свитч N2. ... 1 1c73.dbcc.2ed6 DYNAMIC tg1/2 1 6805.ca30.5c75 DYNAMIC tg1/2 1 9c3b.c26d.1ebd DYNAMIC tg1/2 1 9611.c6aa.6cfd DYNAMIC tg1/2 1 7246.8630.64ef DYNAMIC tg1/2 1 a676.2123.8539 DYNAMIC tg1/2 1 cad7.cd00.cbd8 DYNAMIC tg1/2 1 2822.008a.6202 DYNAMIC tg1/2 1 6805.caf0.5d75 DYNAMIC tg1/2 1 90e2.ba89.e4f1 DYNAMIC tg1/2 1 1293.405f.14fb DYNAMIC tg1/2 1 8410.2df9.f400 DYNAMIC tg1/2 1 f856.5bfe.d556 DYNAMIC tg1/2 1 d6ef.d04d.8305 DYNAMIC tg1/2 1 0000.0000.a8ff DYNAMIC tg1/2 1 f8d5.7b01.c30d DYNAMIC tg1/2 ... Это вот всё что такое? Какие мысли? UPDATE: Понятно, что такое поведение могло привести к сбою свитча, с которого начался топик. Я сейчас наверное переведу всё на статические адреса на портах и отключу обучение. Но остается вопрос, что это такое и откуда оно берется. И почему именно на портах между свитчами. Если бы адресами "срал" какой-то мой сервер, я бы видел эти адреса на портах сервера. Между тем они только между свитчами и несимметричны. UPDATE 2: На свитче 2, если присмотреться, тоже есть левые MAC адреса, тоже на порту другого свитча (N1), просто их меньше. UPDATE 3: Внимательное изучение таблицы после простановки везде статических MAC-ов дает следующую картину: 1 6805.ca31.5c75 DYNAMIC tg1/2 1 6805.ca30.5c75 STATIC tg1/2 Т.е., грубо говоря, иногда помимо вообще левого MAC-а, прилетает MAC "примерно правильный", с ошибкой на 1 байт например (вообще шиза какая-то ;) Ошибки на портах есть (в общем-то я не видел конкетно на SNR портов с 0 ошибок, 15 портов в работе, везде ошибки так или иначе бывают), но в период, когда прилетал такой MAC, счетчик ошибок не менялся. Да и в любом случае - должны ошибки на портах приводить к такому? Контрольные суммы всякие - не ?

Добрый день. Позарившись на цену :), купили два SNR-S2970-12X и штук 15 DA SFP+ 5 метров, чтобы сделать дешево-сердито 10G. Конфигурация следующая: 1) Свитч 1 - примерно 5 DA SFP+ до серверов (Intel X520 и X710), и DA SFP+ до свитча 2. 2) Свитч 2 - примерно 5 DA SFP+ до серверов (Intel X520 и X710), и DA SFP+ до свитча 1. Прошивки version 2.1.1B build 20219, с завода, т.к. других на момент ввода просто в доступе на NAG нигде не было. ПРЕДЕЛЬНО простая архитектура, поверх всего этого ходило iSCSI с MTU 9000 и собственно всё. Конфиг абсолюно дефолтный, никаких VLAN-ов, никаких вообще ничего, flow control только на всех 10G портах включен. На всякий случай прилагаю конфиг. 1G порты не использовались. Чужого трафика в этой сети не могло оказаться даже специально, всё что туда подключен - хосты виртуализации, этот интерфейс выделен ТОЛЬКО для iSCSI. Свитчи установлены в дата-центре, электрические параметры "по ГОСТ-у" (общая земля, постоянная нормальная температура ~21 градус +-, и прочее). Все сервера стоечные платформы Intel, сетевые карты X520 и X710 тоже Intel, установлены корректно. Всё нормально работало примерно месяц, нарекания были минимальные и в пределах понятных для такого дешевого оборудования. Сегодня днем примерно на 40-м дне аптайма повис один из свитчей. Выглядело это так - все порты якобы были подняты (т.е. линк был и на другом свитче-партнере, и на всех сетевых картах), но какая-либо передача данных не осуществлялась. К сожалению не был настроен какой-либо syslog. Кнопкой RESET спереди свитч в чувство не приводился. После перезагрузки по питанию продолжил нормальную работу. После ребута я прошил его на version 2.1.1B build 25329, которую выложили, думаю, 26 марта (т.е. 3 дня назад). offtopic - клавишу backspace в SSH там так и не починили :) offtopic off. Понимаю, что продукт сырой и цена есть цена, но зависание якобы провайдерского класса свитча через месяц работы несколько всё же разочаровывает. Пока продолжаем работу с новой прошивкой. Вопросы понятны. 1) Что это было? 2) Это было характерно для стоковой прошивки 2.1.1B build 20219 или про это ничего неизвестно? 3) Ваши советы, кроме включить syslog? Заранее спасибо всем. startup-config.txt