ShyLion Опубликовано 14 сентября, 2016 · Жалоба Тоже мне секрет нашли...Коммунити должен знать о чём речь. Прям как в анекдоте с номерами анекдотов... - 67 - хахахахаха - а вот 134 - ааа, абаржака Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tau Опубликовано 14 сентября, 2016 · Жалоба P.S. А кто ещё в РФ пишет софт для свитчей кроме Eltex'а? QTech, например, пишет. Точней, дописывает на основе каких-то старых Broadcom-овских наработок и SDK. Да и какая разница, пишется софт в РФ или Китае/Индии/etc, все равно любая доработка/исправление - это время, время - деньги. Увеличит ли доработка/исправление объем продаж? Нет. Значит и деньги не вернутся, вне зависимости от того где сидят программисты. Остается только "имиджевый" момент, на который я и расчитываю. Ну т.е. предлагаете нам тоже наступить на грабли вместе с Вами? Когда не только у тебя проблема, то как-то легче, да? А граблей никаких нет. Было заведомо известно, что экономить на оборудовании нельзя. Тоже мне секрет нашли...Коммунити должен знать о чём речь. Нету секрета. На любом девайсе любого вендора можно найти какую-то недоработку, которая при определенных обстоятельствах (внешних факторах) даст сбой всей сети. Пример s.lobanov про DHCP тому подтверждение. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 14 сентября, 2016 · Жалоба Мне известно два псевдо-российских бренда. Это SNR и Eltex. Т.е. "есть два стула". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Володя Опубликовано 14 сентября, 2016 · Жалоба Мне известно два псевдо-российских бренда. Это SNR и Eltex. Т.е. "есть два стула". А разве Eltex не производят в Новосибирске? В отличии от SNR Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tau Опубликовано 14 сентября, 2016 (изменено) · Жалоба Мне известно два псевдо-российских бренда. Это SNR и Eltex. Т.е. "есть два стула". А разве Eltex не производят в Новосибирске? В отличии от SNR Eltex штампуют в Новосибе на базе Марвеловских чипов. Если будут санкции на технологии NNнм (я хз какая там у них технология), то Eltex будет сосать лапу. SNR - OEM. Про разработку софта - нет информации. QTech - OEM, имеют в РФ R&D (UPD: даже целых два - Москва и Рязань). Изменено 14 сентября, 2016 пользователем Tau Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SyJet Опубликовано 14 сентября, 2016 · Жалоба Если будут санкции на технологии NNнм (я хз какая там у них технология), то Eltex будет сосать лапу - только если марвел перестанет продавать чипы, элтекс не печет сами чипы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Megas Опубликовано 14 сентября, 2016 · Жалоба https://habrahabr.ru/company/cbs/blog/276863/ -- Администрирование → ARP: Нюансы работы оборудования Cisco и интересные случаи. Часть 1 https://habrahabr.ru/company/cbs/blog/277251/ --- Администрирование → ARP: Нюансы работы оборудования Cisco и интересные случаи. Часть 2 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 15 сентября, 2016 · Жалоба Нашёл на кого ссылаться, они мануалов то новых не читали, не говоря о понимании прочитанного: https://habrahabr.ru/company/cbs/blog/309486/ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nickD Опубликовано 15 сентября, 2016 · Жалоба Проблема обработки броадкаста cpu от всех транзитных vlan существует давно и почти у всех вендоров. Проверить просто сдесь на форуме где то валялась программка генератор бродкастов, запускаем и смотрим загрузку cpu, вы будите удивлены. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Сиськовед Опубликовано 15 сентября, 2016 · Жалоба Мне известно два псевдо-российских бренда. Это SNR и Eltex. Т.е. "есть два стула". А разве Eltex не производят в Новосибирске? В отличии от SNR Да-да производят, мне 2 головы поновские "производили" недели 2. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 15 сентября, 2016 · Жалоба Вот буквально на этой неделе столкнулся с сюрпризом от QTECH 2900. Есть такой ACL: access-list 201 permit 34915 ingress int eth 0/1 access-list 201 permit 34916 ingress int eth 0/1 access-list 201 deny ingress int eth 0/1 В теории должен резать все, кроме PPPoE. На практике режет просто все. Потому что deny-правило без уточнений применяется без учета порядка правила в ACL. Пришлось заменить на несколько deny для протоколов ip|arp|rarp. Из других сюрпризов — ACL применяется после программной обработки. Т.е. неважно, какой ACL на интерфейсе, но на CPU пакет все равно попадет. Правда польза от ACL есть, т.к. за CPU такой трафик не выйдет, но все равно неприятно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SNR Опубликовано 15 сентября, 2016 · Жалоба Раз появилась такая тема, обрисую ситуацию с ARP в транзитных vlan на коммутаторах SNR: SNR-S4550, SNR-S300 - для отключения обработки ARP в транзитных vlan необходимо применить команду local-arp enable SNR-S2990G-24FX - ARP в транзитных vlan не обрабатываются по дефолту. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
buckethead Опубликовано 15 сентября, 2016 · Жалоба Вот буквально на этой неделе столкнулся с сюрпризом от QTECH 2900. Есть такой ACL: access-list 201 permit 34915 ingress int eth 0/1 access-list 201 permit 34916 ingress int eth 0/1 access-list 201 deny ingress int eth 0/1 В теории должен резать все, кроме PPPoE. На практике режет просто все. Потому что deny-правило без уточнений применяется без учета порядка правила в ACL. Пришлось заменить на несколько deny для протоколов ip|arp|rarp. Из других сюрпризов — ACL применяется после программной обработки. Т.е. неважно, какой ACL на интерфейсе, но на CPU пакет все равно попадет. Правда польза от ACL есть, т.к. за CPU такой трафик не выйдет, но все равно неприятно. 2900 отживший своё утиль, который массово меняется у операторов по стране, где стоял. Кутек неофициально признаёт эту линейку очень неудачной и недальновидной разработкой китайских коллег. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 15 сентября, 2016 · Жалоба Ну как по мне, 2900 не самый плохой дешевый коммутатор, даже не без достоинств. БП у него проблемные, а сама железка работает не хуже D-Link DES-3200, которые используются куда более массово и считаются неплохими. Меня удивило, что такой баг отдел тестирования пропустил за несколько лет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
buckethead Опубликовано 16 сентября, 2016 · Жалоба >> а сама железка работает не хуже D-Link DES-3200 Работает гораздо хуже, у 3200 буфер 1.5 МБ, у 2900 -- 256 КБ. На высоком RTT (100 мс и больше) у абонентов начинаются проблемы со скоростью загрузки. Ростелеком, например, по этой причине их массово поменял в Сибири. >> Меня удивило, что такой баг отдел тестирования пропустил за несколько лет Свитч EOL, баги R&D правят спустя рукава и только ооочень критические. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 16 сентября, 2016 · Жалоба Вы походу не поняли сути. Проблема с пропуском ARP на L2 коммутаторе, которому чужие ARP должны быть до п...ы, и обрабатывать их в соответствии с политикой storm-control для broadcast-трафика. Все штормы надо резать на порту клиента причем жестко. А далее просто ничего не должно успеть загнуться. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tau Опубликовано 17 сентября, 2016 · Жалоба Все штормы надо резать на порту клиента причем жестко. А далее просто ничего не должно успеть загнуться. На доступе минимальная граница ограчения MC/BC 64кбит/с. ARP-пакет 'who has' имеет размер 480 бит. Один абонент может дать нагрузку в 64к/480 = 136.5 PPS Стандартное значение пропускаемых ARP-пакетов через проблемый коммутатор 1000 PPS. Вычтем стандартный "фон" сегментов за коммутатором (200). Итого 800 / 136.5 = 5.8 флудящих абонента кладут ARP на всех сегментах. Какова вероятность, что одновременно на сети в разных ее сегментах возникнет подобная ситуация? Три года назад возможность проблемы была предсказана, на прошлой неделе она воспроизвелась. Вы все еще возлагаете надежны на уровень доступа? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nickD Опубликовано 18 сентября, 2016 · Жалоба они может с арп и фиксят попробуйте для разнообразия другие броадкасты dhcp и прочее. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 20 сентября, 2016 · Жалоба Стандартное значение пропускаемых ARP-пакетов через проблемый коммутатор 1000 PPS. Вычтем стандартный "фон" сегментов за коммутатором (200). У Вас сегмент это что? Дом? На 200 домов у Вас такой дохлый коммутатор? У нас на 50 подъездов (~10 домов) стоят не такие дохлые - уже уровень агрегации. А далее что-то типа 7606, у которой ARP протокол, если не путаю, в "железе" - ей хоть сотню тысяч запросов ARP шли в секунду! Поменяйте коммутаторы агрегации, а те что там сейчас спустите на "доступ" Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tau Опубликовано 20 сентября, 2016 · Жалоба На 200 домов у Вас такой дохлый коммутатор? У нас на 50 подъездов (~10 домов) стоят не такие дохлые - уже уровень агрегации. Прирожденный сетевик. Терминология соответствует. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShyLion Опубликовано 20 сентября, 2016 · Жалоба Ну кому эти PPS интересны :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 20 сентября, 2016 · Жалоба Прирожденный сетевик. Терминология соответствует. Не, прирожденный бы выразился в терминах недостаточной производительности, ошибочного применения коммутатора уровня доступа в агрегации или даже ядре немаленькой сети. :) А это - по рабоче-крестьянски ;) Просто я так понял проблема свелась к тому, что 1) надо резать ARP т.к. если их много то начинаются глюки 2) не надо резать ARP т.к. если это делать начинаются глюки. Этот заколдованный круг можно разрешить только установкой оборудования которое обрабатывает ARP с должной скоростью. Лучше аппаратно. Тут выбирать надо не вендора, а класс оборудования. Надо чтобы оно было сделано для оператора и агрегации/ядра. Это на доступе можно экономить. А на агрегации - вредно. Из коммутаторов что-то вроде Eltex MES3124F можно попробовать. Точно посоветовать не могу - у нас как-то проблема штормов и большого потока ARP вообще в принципе не стоит. Тфу тфу тфу. А маршрутизатор у Вас какой? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nickD Опубликовано 20 сентября, 2016 · Жалоба С агрегации все равно в доступ спустится если это передача данных. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 22 сентября, 2016 · Жалоба С агрегации все равно в доступ спустится если это передача данных. ARP пакеты нельзя спускать на доступ обратно. И любые броадкасты тоже. Сегментация трафика (например приватные VLAN) + на маршрутизаторе proxy-ARP. Т.е. к клиентам идут ARP и броадкасты только от оборудования оператора и никак не от других абонентов. Очень от многого спасает. Это очень простой и надежный как рельс способ. Надежнее только "VLAN-PER-USER". Я не встречал тех кому надо L2 каналы с прозрачным броадкастом. Но если кому-то надо - это исключение можно реализовать специально. Выделить такому абоненту отдельный VLAN без ограничений и если он сам нарушит работу чем-нибудь - сам и виноват. Броадкасты в недорогих коммутаторах особая тема. Там иногда делали (не знаю как сейчас) единую очередь и когда есть IPTV на мультикасте и один порт переключается в 10 Мбит/с - все остальные нормально посмотреть IPTV не могут - этот медленный порт тормозил всю очередь броадкастов :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ser Опубликовано 14 октября, 2019 · Жалоба On 9/15/2016 at 3:51 PM, SNR said: Раз появилась такая тема, обрисую ситуацию с ARP в транзитных vlan на коммутаторах SNR: SNR-S4550, SNR-S300 - для отключения обработки ARP в транзитных vlan необходимо применить команду local-arp enable SNR-S2990G-24FX - ARP в транзитных vlan не обрабатываются по дефолту. Недавно тоже встретился с данной проблемой на свичах SNR. Возникли вопросы. Зачем на свичах нужно прослушивать все транзитные vlan-ы, кроме управляющего. Для чего существует команда local-arp enable ? Логично было бы включить обработку arp только в управляющем влане свича. И вопрос для NAGa. Какую дать команду, чтобы BDCOM 3608 тоже обрабатывала arp Только в влане управления. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...