Victor Tkachenko

Обратите внимание на отступы в тексте, они намекают, что это часть условий для дропов кадров с ошибками в FCS. Режим cut-through не отменяет проверку корректности FCS в общем случае, он лишь ограничен в возможности дропнуть кадр при наличие ошибок, так как они могут быть обнаружены позже начала передачи кадра в исходящий порт. Суть в том, что процедуры match-action для заголовков требуют некоторое время. Грубо говоря, если весь кадр может быть принят коммутатором быстрее, чем заголовки кадра пройдут цепочку match-action юнитов на чипе, то может быть обеспечена сверка FCS до отправки кадра в исходящий порт. Таким образом дропы при некорректной FCS возможны для кадров размером не более X байт, где X зависит от задержек коммутации (то есть модели чипа / модели коммутатора).

@alger действительно, маршрутизация на современных L3-коммутаторах реализована на уровне ASIC, соответственно работает на скорости портов и не вносит существенных задержек (они на уровне десятков-сотен наносекунд). В сегменте коммутаторов с желаемыми портовыми конфигурациями почти все сейчас поддерживают EVPN/VXLAN, их даже больше, чем таких же коммутаторов с поддержкой стекирования. В среднем с финансовой точки зрения не будет существенной разницы какой из вариантов вы выберете. При этом, конечно, следует использовать тот подход, в котором у вашей команды уже есть опыт, вам же это обслуживать. Лично с моей точки зрения, первую схему со стекированием следует использовать исключительно в случаях с L2 каналами. Если планируется внедрение L3 в дальнейшем, не стоит использовать стекирование. В конце концов вы и сами отметили, что обслуживание во втором сценарии будет проще - не нужно мучаться с нюансами реализации стека при обновлении ПО или замене/добавлении коммутатора. Второй вариант перспективнее по ряду причин: 1) без проблем сможете внедрить L3VPN 2) проще добавлять и менять коммутаторы в фабрике даже при снятии с продаж уже используемых моделей 3) диагностика проблем в сети хоть и требует большей экспертизы (добавляется underlay маршрутизация и overlay, например, с сигнализацией EVPN), но доступнее, так как используются "стандартные" технологии

Ни в коем случае не топлю за Fortinet, Juniper SRX тоже отлично справится, лишь предлагаю адекватную альтернативу. 1. Действительно, младшие модели по факту софтроутеры, но тут речь про небольшую корпоративную сеть, а не операторскую, она в любом случае ляжет под DDoS. 2. Уязвимости есть у всех, важно на сколько быстро они выявляются и закрываются. 3. Вопрос похоже субъекитвный, никаких проблем не возникало ни с политиками, ни с NAT для VPN, просто ставится галочка и добавляются нужные разрешающие правила. 4. Можно использовать стандартный IPSec клиент винды и т.п, а SSL-VPN вообще без клиента поднять можно. Может это плохой опыт со старыми версиями? В FortiOS 6 многое изменилось.

ТС поставил задачу подобрать маршрутизатор в зарисованную сеть. Ваша же рекомендация требует замены коммутаторов доступа. Трезвость рекомендации под большим вопросом, вы сами недавно приводили довольно скромные рассчеты по трафику, да и ТС уже привел примерные данные, гигабита тут на текущий момент достаточно, 10G в сжатых бюджетных рамках стоит рассматривать лишь на перспективу роста. Вы категорически отказываетесь усваивать смысл написанного и продолжаете развивать тему. Мной уже сказано, что в данном конкретном случае коммерческая поддержка нецелесообразна. Случаи, когда она целесообразна, к сожалению, не знакомы поставщикам MikroTik, этот вопрос исчерпан. 1) Тут совершается серьезная логическая ошибка, вы приравниваете качество продукции одного разработчика к аналогичным продуктам второго, по всей видимости, не имея представления о первом и основываясь лишь на своих субъективных доводах. Важно заметить, что Linksys - это, действительно, не такая уж большая компания, купленная в последствии Cisco, качество продукции под сомнением. Fortinet же - это уже давно состоявшаяся компания с сильными решениями (не все у них идеально, но мы говорим про конкретные устройства). 2) Маршрутизаторы Dlink, как уже отметили никто не предлагал, а упомянутые в схеме коммутаторы дешевле предложенных вами. Похоже на попытку увести внимание читателя от дельных предложений. Тут вас куда-то уносит. Про сложности в создании трех вланов не говорилось, это как раз нормально. Комментарий был вызван вашим предложением создавать отдельные вланы на каждый порт, что крайне непрактично для корпоративной сети. И вот опять совершается уход в сторону. В корпоративной сети не нужна опция 82, это даже никто не предлагал. Достаточно выделить несколько вланов по типам устройств в сети, в идеале реализовать аутентификацию 802.1x. Категорически не понятно где тут проблема. Мной было рекомендовано устройство, в основные задачи которого как раз входит обеспечение безопасности, политики настраиваются очень гибко, а главное - просто - пользователю не нужно учитывать что в какую цепочку попадает, абстракции существенно выше. Не соглашусь, микротик настраивать проще только тем, кто уже имеет хороший опыт работы с ним. Многие другие разработчики не пытаются максимально расширять функционал, а оттачивают реально востребованный и сосредотачиваются на простоте конфигурации. От измерений длины команды в CLI воздержусь, простота в таких случаях заключается в качественных и понятных абстракциях и грамотном их отображении в GUI. Вот это как раз пример задач, которые отлично переносятся на сторонние устройства при необходимости, а необходимость эта в простой и отлаженной сети крайне редка, если вообще возникает.

Мы же говорим про гигабитные линии, верно? Не важно будет ли у вас медный или оптический линк, скорость та же - 1Gbps.

Также на картинке есть VPN-клиенты, сервер для которых вполне можно организовать на том же устройстве штатными средствами, желательно с шифрованием (да-да, MikroTik это тоже умеет). Например, трафик от камер к регистраторам и от авторизованных устройств к файловому серверу. Отмечу, что с авторизацией прекрасно справляется 802.1x и пользователи могут мирно существовать в одном VLAN, а для изоляции трафика между ними есть другие стандартные механизмы, не требующие создавать множество разных VLAN. То, что вы предлагаете, делают только в операторских сетях и причины там далеко не только в изоляции трафика. Нет, MikroTik, безусловно, хорош, но призван решать сразу множество задач, иногда довольно топорными методами. При наличие грамотного инженера работать, конечно, будет. О "мелких фирмочках" речи не шло, Fortinet - это компания с миллиардной капитализацией, которая специализируется как раз на таких корпоративных решениях, при чем предоставляет и довольно дешевые варианты. Зря затронул этот вопрос, посыл был в другом - наличии коммерческой поддержки с явным SLA, тут такое в общем-то не требуется. Опять же я не говорил, что в данном контексте есть нерашемые проблемы в ПО MikroTik, тут они исключительно в необходимости тюнить систему под задачу, в то время как есть специализированные устройства в ту же цену, где в еще более простой манере настраиваются политики маршрутизации и безопасности. Трафик в данном вопросе роли не играет, важно понимать какую физику вам проще эксплуатировать в данных условиях (оптика или медь). Из плюсов оптики можно отметить дешевизну самого волокна, малые размеры, неприхотливость к длине и наводкам, но минусы в вашем случае могут быть существеннее - требуется специальное оборудование и навыки для сварки при монтаже или восстановлении линии.

Да, но это явно не коммутатор.

1) Ваш вопрос построен на ложном утверждении, я нигде не говорил, что производительности рекомендуемого маршрутизатора не хватит; 2) Смысл в том, что внутресетевой трафик можно разрулить и без участия маршрутизатора, снизив тем самым его стоимость и оставив запас на расширение по производительности/функционалу; 3) Смысл в применении специализированных решений, которые могут качественно решить поставленные задачи без необходимости лезть под капот; 4) Смысл в конце концов в возможности получить профессиональную поддержку, хотя тут она вероятно не потребуется, все легко настраивается, разве что cookbook почитать стоит. Пожалейте человека - не советуйте плохого, такие решения принимают от безысходности, а не потому что работает. 2-ядерный ARM не может качественно обработать достаточный объем трафика с большим набором правил, я уже не говорю про IPSec.

@nic_123 с маршрутизацией в корпоративных сетях хорошо справляются недорогие FortiGate, на них помимо базового роутинга, NAT и Firewall также есть функционал IPSec/SSL-VPN сервера и расширенной защиты (IPS, антивирус, веб-фильтрация). Если использовать точки доступа Fortinet, то он же может выступать в роли контроллера для удобства управления и организации бесшовного роуминга. Конкретную модель следует выбирать, опираясь на вводные по нагрузке (как минимум объем трафика и количество VPN-сессий). В принципе с задачами небольшого офиса справится FG-40F стоимостью около 50к рублей. Для снижения нагрузки на маршрутизатор, конечно, следует добавить L3-коммутатор, который будет агрегировать линки с доступа и, например, гонять трафик до файлового сервера, а на маршрутизатор отдавать только трафик в интернет. SNR-S2995G-24FX или SNR-S2995G-24TX

Для тех, кто не смог принять участие в вебинаре 15 мая, будет проведена повторная сессия 28 мая. Регистрация по ссылке.

Абсолютно неверный вывод из написанного мной предложения, там ни слова об освобождении буфера. Дополню: "Пока 10GE порт выбирает уже записанные в буфер пакеты, порты 1GE успеют полностью или частично записать в буфер новые" В теории и регулярно подтверждается на практике. Теория эта кстати строится на дизайнах конкретных архитектур сетевых ASIC. Пакеты, действительно, чаще всего теряются не просто по случайности, а систематически и по вполне конкретным причинам. Как я уже выше отметил, проблема ТС наверняка связана с особенностями реализации SPAN в ASIC Marvell BobCat, на котором построен упомянутый коммутатор. Чипы Broadcom в большинстве своем таких проблем не имеют, в том числе чипы, на которых построены коммутаторы SNR-S2990G.

@sdy_moscow верно, сначала кадр должен быть полностью записан в буфер, условно это 1500 байт данных. Для приема такого пакета через порт 1GE и его последующей записи в буфер потребуется немногим больше 12мкс, в то же время 10GE порт выберет все данные примерно за 1.2мкс. В итоге 10GE порт за те же 12мкс может поочередно забрать 10 уже записанных в буфер пакетов. Если предположить, что пакеты "непрерывно" и одновременно поступают с десяти 1GE портов, для их хранения потребуется условных 15000 байт и еще 15000 байт свободного места для непрерывной записи следующих пакетов, размер же буфера в таком коммутаторе, как правило, составляет не менее 1.5МБ. То есть даже в более тяжелом случае (10x1GE -> 1x10GE) 10GE порт успевает забрать из буфера достаточное количество пакетов, при этом от буфера потребуется до 2% емкости, а за время выгрузки пакетов как раз запишутся новые.

@sdy_moscow для копирования трафика из нескольких гигабитных портов в десятку не нужен большой буфер, 10GE порт выгребает трафик из буфера быстрее, чем он наполняется. Большой буфер может потребоваться в обратной ситуации. MES3124 давал потери, так как пострен на чипе Marvell BobCat, который архитектурно имеет проблемы с копированием трафика.

Это про отдельных абонентов или трафик вообще? Если сессии одного абонента все же раскидывает по разным DPI, желательно собрать больше информации о конкретных сессиях. Снизу только дефолтные eBGP-маршруты имелись или еще что-то было?

@Avensis все DPI подключены к одному маршрутизатору? Вообще похоже, что балансировка и по порту осуществляется, в итоге разные потоки попадают в разные пулы NAT. Также стоит убедиться, что сам DPI мапит разные сессии одного абонента в один IP.

Наилучшие по цене или функционалу?) Из интересного на перспективу: VXLAN EVPN VXLAN EVPN Multihoming VXLAN EVPN Anycast L3 Gateway Перед этим, конечно: RSTP, ERPS, OSPF, IS-IS, BGP, MP-BGP, MPLS.

https://apps.juniper.net/feature-explorer/feature-info.html?fKey=7255&fn=New load-balancing options using source or destination IP address only   В случае с MX это называется consistent-hash. https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/policy-load-balancing-consistent-ecmp-configuring.html

@Avensis здравствуйте! Для соблюдения симметричности прохождения трафика можно точечно анонсировать префиксы, соответствующие NAT-пулам. Например, как на приложенной картинке, поднимаете по одной eBGP-сессии между агрегацией и бордером на каждый установленный СКАТ DPI. С бордера на агрегацию через все сессии анонсируете дефолт, а в обратном направлении префиксы, соответствующие NAT-пулам. При этом желательно на агрегации балансировать ECMP по source-ip-only, чтобы каждый абонент фиксировался за конкретным NAT. Также стоит применить resilient-hash, чтобы при выходе из строя какой-либо сессии не пересчитывалась вся таблица балансировки.

Необходимо воспользоваться протоколами динамической маршрутизации, чтобы условный сервер мог передавать информацию о своих сетях и вам не приходилось вручную указывать статические маршруты. Например, почитайте про OSPF или BGP. При падении линка соседство OSPF/BGP порвется и маршрут до 172.21.114.65/32 будет удален. В текущей схеме с использованием VRF также потребуется импортировать получаемые маршруты, что лишь усложняет задачу и понимание происходящего. Рекомендую начать со схемы без VRF (все сети в дефолтной таблице), чтобы разобраться с протоколами. BFD проверяет связность двух заранее известных IP-адресов. События разрыва/установки сессии BFD могут быть привязаны к сессиям протоколов маршрутизации или статическим маршрутам для их своевременного удаления/восстановления. Интервал проверки может составлять десятки миллисекунд, что позволяет существенно сократить время перестроения сети, но это может приводить и к ложным сработкам. Конкретно в случае с FRR работа BFD в связке со статическими маршрутами не реализована (Feature Request). Информация по упомянутым выше протоколам и их конфигурации в Cumulus Linux есть в официально документации.

@vasil.german доброго! В данном случае следует проверить время жизни arp cache и работает ли GC, удаляющие просроченные записи. Логика работы с arp cache тут стандартная, как в Debian. По настройке таймеров arp cache и порогов GC в Cumulus Linux посмотрите оригинальную статью: https://support.cumulusnetworks.com/hc/en-us/articles/202012933-Changing-ARP-timers-in-Cumulus-Linux Вообще, если предполагается балансировка нагрузки на некоторый сервис, то следует применять специализированные балансировщики, которые отслеживают состояние сервиса на нодах, например, HAProxy или Nginx. Для корректного резервирования средствами ECMP, при выходе какого-то хоста/линка из строя, соответствующие некстхопы должны удаляться. Если в вашей схеме из строя выйдет только сам сервис, то нагрузка не уйдет на другую ноду.

@alibek Если L3-интерфейс в этом VLAN отсутствует (при наличии, как правило, в FDB добавляется соответствующая запись), то должен расходиться по портам.

@edo, вообще есть, но на этот год в план не ставили.

@dan4ex добрый! На данный момент нет подготовленных нами в открытый доступ модулей Ansible для управления коммутаторами SNR. Возможно кто-то из пользователей форума поделится своими наработками.

@smmozg наш менеджер свяжется с вами и поможет решить все вопросы с Cumulus Linux.

Добрый! Под ваши требования подошел бы бесплатный OpenSwitch, но он, судя по списку совместимых платформ, не поддерживает 5610-52X (Trident+). Бесплатно можно установить ONL, но это скорее среда для разработки. Для реализации L2 функционала, например, можно воспользоваться API Broadcom - OpenNSL. В качестве готового решения можно рассмотреть Cumulus Linux, правда, версия будет не последняя, так как платформа уже успела устареть.