[ShyLion]

Тоже мне секрет нашли...Коммунити должен знать о чём речь.

Прям как в анекдоте с номерами анекдотов...

 

- 67

- хахахахаха

- а вот 134

- ааа, абаржака

[Tau]

P.S. А кто ещё в РФ пишет софт для свитчей кроме Eltex'а?

QTech, например, пишет. Точней, дописывает на основе каких-то старых Broadcom-овских наработок и SDK.

 

Да и какая разница, пишется софт в РФ или Китае/Индии/etc, все равно любая доработка/исправление - это время, время - деньги. Увеличит ли доработка/исправление объем продаж? Нет. Значит и деньги не вернутся, вне зависимости от того где сидят программисты.

Остается только "имиджевый" момент, на который я и расчитываю.

 

Ну т.е. предлагаете нам тоже наступить на грабли вместе с Вами? Когда не только у тебя проблема, то как-то легче, да?

А граблей никаких нет. Было заведомо известно, что экономить на оборудовании нельзя.

 

Тоже мне секрет нашли...Коммунити должен знать о чём речь.

Нету секрета. На любом девайсе любого вендора можно найти какую-то недоработку, которая при определенных обстоятельствах (внешних факторах) даст сбой всей сети. Пример s.lobanov про DHCP тому подтверждение.

[vurd]

Мне известно два псевдо-российских бренда. Это SNR и Eltex. Т.е. "есть два стула".

[Володя]

Мне известно два псевдо-российских бренда. Это SNR и Eltex. Т.е. "есть два стула".

А разве Eltex не производят в Новосибирске? В отличии от SNR

[Tau]

Мне известно два псевдо-российских бренда. Это SNR и Eltex. Т.е. "есть два стула".

А разве Eltex не производят в Новосибирске? В отличии от SNR

Eltex штампуют в Новосибе на базе Марвеловских чипов.

Если будут санкции на технологии NNнм (я хз какая там у них технология), то Eltex будет сосать лапу.

 

SNR - OEM. Про разработку софта - нет информации.

 

QTech - OEM, имеют в РФ R&D (UPD: даже целых два - Москва и Рязань).

Изменено 14 сентября, 2016 пользователем Tau

[SyJet]

Если будут санкции на технологии NNнм (я хз какая там у них технология), то Eltex будет сосать лапу - только если марвел перестанет продавать чипы, элтекс не печет сами чипы.

[Megas]

https://habrahabr.ru/company/cbs/blog/276863/ -- Администрирование → ARP: Нюансы работы оборудования Cisco и интересные случаи. Часть 1

 

https://habrahabr.ru/company/cbs/blog/277251/ --- Администрирование → ARP: Нюансы работы оборудования Cisco и интересные случаи. Часть 2

[Ivan_83]

Нашёл на кого ссылаться, они мануалов то новых не читали, не говоря о понимании прочитанного:

https://habrahabr.ru/company/cbs/blog/309486/

[nickD]

Проблема обработки броадкаста cpu от всех транзитных vlan существует давно и почти у всех вендоров. Проверить просто сдесь на форуме где то валялась программка генератор бродкастов, запускаем и смотрим загрузку cpu, вы будите удивлены.

[Сиськовед]

Мне известно два псевдо-российских бренда. Это SNR и Eltex. Т.е. "есть два стула".

А разве Eltex не производят в Новосибирске? В отличии от SNR

Да-да производят, мне 2 головы поновские "производили" недели 2.

[alibek]

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

[SNR]

Раз появилась такая тема, обрисую ситуацию с ARP в транзитных vlan на коммутаторах SNR:

SNR-S4550, SNR-S300 - для отключения обработки ARP в транзитных vlan необходимо применить команду local-arp enable

SNR-S2990G-24FX - ARP в транзитных vlan не обрабатываются по дефолту.

[buckethead]

Вот буквально на этой неделе столкнулся с сюрпризом от 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 отживший своё утиль, который массово меняется у операторов по стране, где стоял. Кутек неофициально признаёт эту линейку очень неудачной и недальновидной разработкой китайских коллег.

[alibek]

Ну как по мне, 2900 не самый плохой дешевый коммутатор, даже не без достоинств. БП у него проблемные, а сама железка работает не хуже D-Link DES-3200, которые используются куда более массово и считаются неплохими.

Меня удивило, что такой баг отдел тестирования пропустил за несколько лет.

[buckethead]

>> а сама железка работает не хуже D-Link DES-3200

Работает гораздо хуже, у 3200 буфер 1.5 МБ, у 2900 -- 256 КБ. На высоком RTT (100 мс и больше) у абонентов начинаются проблемы со скоростью загрузки. Ростелеком, например, по этой причине их массово поменял в Сибири.

 

>> Меня удивило, что такой баг отдел тестирования пропустил за несколько лет

Свитч EOL, баги R&D правят спустя рукава и только ооочень критические.

[Tosha]

Вы походу не поняли сути. Проблема с пропуском ARP на L2 коммутаторе, которому чужие ARP должны быть до п...ы, и обрабатывать их в соответствии с политикой storm-control для broadcast-трафика.

Все штормы надо резать на порту клиента причем жестко. А далее просто ничего не должно успеть загнуться.

[Tau]

Все штормы надо резать на порту клиента причем жестко. А далее просто ничего не должно успеть загнуться.

 

На доступе минимальная граница ограчения MC/BC 64кбит/с.

ARP-пакет 'who has' имеет размер 480 бит. Один абонент может дать нагрузку в 64к/480 = 136.5 PPS

Стандартное значение пропускаемых ARP-пакетов через проблемый коммутатор 1000 PPS. Вычтем стандартный "фон" сегментов за коммутатором (200).

Итого 800 / 136.5 = 5.8 флудящих абонента кладут ARP на всех сегментах.

Какова вероятность, что одновременно на сети в разных ее сегментах возникнет подобная ситуация? Три года назад возможность проблемы была предсказана, на прошлой неделе она воспроизвелась.

Вы все еще возлагаете надежны на уровень доступа?

[nickD]

они может с арп и фиксят попробуйте для разнообразия другие броадкасты dhcp и прочее.

[Tosha]

Стандартное значение пропускаемых ARP-пакетов через проблемый коммутатор 1000 PPS. Вычтем стандартный "фон" сегментов за коммутатором (200).

У Вас сегмент это что? Дом?

На 200 домов у Вас такой дохлый коммутатор? У нас на 50 подъездов (~10 домов) стоят не такие дохлые - уже уровень агрегации.

А далее что-то типа 7606, у которой ARP протокол, если не путаю, в "железе" - ей хоть сотню тысяч запросов ARP шли в секунду!

 

Поменяйте коммутаторы агрегации, а те что там сейчас спустите на "доступ"

[Tau]

На 200 домов у Вас такой дохлый коммутатор? У нас на 50 подъездов (~10 домов) стоят не такие дохлые - уже уровень агрегации.

Прирожденный сетевик. Терминология соответствует.

[ShyLion]

Ну кому эти PPS интересны :)

[Tosha]

Прирожденный сетевик. Терминология соответствует.

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

 

А это - по рабоче-крестьянски ;)

 

Просто я так понял проблема свелась к тому, что 1) надо резать ARP т.к. если их много то начинаются глюки 2) не надо резать ARP т.к. если это делать начинаются глюки.

 

Этот заколдованный круг можно разрешить только установкой оборудования которое обрабатывает ARP с должной скоростью. Лучше аппаратно.

 

Тут выбирать надо не вендора, а класс оборудования. Надо чтобы оно было сделано для оператора и агрегации/ядра. Это на доступе можно экономить. А на агрегации - вредно.

 

Из коммутаторов что-то вроде Eltex MES3124F можно попробовать. Точно посоветовать не могу - у нас как-то проблема штормов и большого потока ARP вообще в принципе не стоит. Тфу тфу тфу.

 

А маршрутизатор у Вас какой?

[nickD]

С агрегации все равно в доступ спустится если это передача данных.

[Tosha]

С агрегации все равно в доступ спустится если это передача данных.

ARP пакеты нельзя спускать на доступ обратно. И любые броадкасты тоже. Сегментация трафика (например приватные VLAN) + на маршрутизаторе proxy-ARP. Т.е. к клиентам идут ARP и броадкасты только от оборудования оператора и никак не от других абонентов. Очень от многого спасает. Это очень простой и надежный как рельс способ. Надежнее только "VLAN-PER-USER".

 

Я не встречал тех кому надо L2 каналы с прозрачным броадкастом. Но если кому-то надо - это исключение можно реализовать специально. Выделить такому абоненту отдельный VLAN без ограничений и если он сам нарушит работу чем-нибудь - сам и виноват.

 

Броадкасты в недорогих коммутаторах особая тема. Там иногда делали (не знаю как сейчас) единую очередь и когда есть IPTV на мультикасте и один порт переключается в 10 Мбит/с - все остальные нормально посмотреть IPTV не могут - этот медленный порт тормозил всю очередь броадкастов :)

[Ser]

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 Только в влане управления.