Перейти к содержимому
Калькуляторы

Victor Tkachenko

Активный участник
  • Публикации

    440
  • Зарегистрирован

  • Посещение

О Victor Tkachenko

  • Звание
    SNR Team
    Студент

Информация

  • Пол
    Array

Посетители профиля

Блок посетителей профиля отключен и не будет отображаться другим пользователям

  1. Обратите внимание на отступы в тексте, они намекают, что это часть условий для дропов кадров с ошибками в FCS. Режим cut-through не отменяет проверку корректности FCS в общем случае, он лишь ограничен в возможности дропнуть кадр при наличие ошибок, так как они могут быть обнаружены позже начала передачи кадра в исходящий порт. Суть в том, что процедуры match-action для заголовков требуют некоторое время. Грубо говоря, если весь кадр может быть принят коммутатором быстрее, чем заголовки кадра пройдут цепочку match-action юнитов на чипе, то может быть обеспечена сверка FCS до отправки кадра в исходящий порт. Таким образом дропы при некорректной FCS возможны для кадров размером не более X байт, где X зависит от задержек коммутации (то есть модели чипа / модели коммутатора).
  2. @alger действительно, маршрутизация на современных L3-коммутаторах реализована на уровне ASIC, соответственно работает на скорости портов и не вносит существенных задержек (они на уровне десятков-сотен наносекунд). В сегменте коммутаторов с желаемыми портовыми конфигурациями почти все сейчас поддерживают EVPN/VXLAN, их даже больше, чем таких же коммутаторов с поддержкой стекирования. В среднем с финансовой точки зрения не будет существенной разницы какой из вариантов вы выберете. При этом, конечно, следует использовать тот подход, в котором у вашей команды уже есть опыт, вам же это обслуживать. Лично с моей точки зрения, первую схему со стекированием следует использовать исключительно в случаях с L2 каналами. Если планируется внедрение L3 в дальнейшем, не стоит использовать стекирование. В конце концов вы и сами отметили, что обслуживание во втором сценарии будет проще - не нужно мучаться с нюансами реализации стека при обновлении ПО или замене/добавлении коммутатора. Второй вариант перспективнее по ряду причин: 1) без проблем сможете внедрить L3VPN 2) проще добавлять и менять коммутаторы в фабрике даже при снятии с продаж уже используемых моделей 3) диагностика проблем в сети хоть и требует большей экспертизы (добавляется underlay маршрутизация и overlay, например, с сигнализацией EVPN), но доступнее, так как используются "стандартные" технологии
  3. Ни в коем случае не топлю за Fortinet, Juniper SRX тоже отлично справится, лишь предлагаю адекватную альтернативу. 1. Действительно, младшие модели по факту софтроутеры, но тут речь про небольшую корпоративную сеть, а не операторскую, она в любом случае ляжет под DDoS. 2. Уязвимости есть у всех, важно на сколько быстро они выявляются и закрываются. 3. Вопрос похоже субъекитвный, никаких проблем не возникало ни с политиками, ни с NAT для VPN, просто ставится галочка и добавляются нужные разрешающие правила. 4. Можно использовать стандартный IPSec клиент винды и т.п, а SSL-VPN вообще без клиента поднять можно. Может это плохой опыт со старыми версиями? В FortiOS 6 многое изменилось.
  4. ТС поставил задачу подобрать маршрутизатор в зарисованную сеть. Ваша же рекомендация требует замены коммутаторов доступа. Трезвость рекомендации под большим вопросом, вы сами недавно приводили довольно скромные рассчеты по трафику, да и ТС уже привел примерные данные, гигабита тут на текущий момент достаточно, 10G в сжатых бюджетных рамках стоит рассматривать лишь на перспективу роста. Вы категорически отказываетесь усваивать смысл написанного и продолжаете развивать тему. Мной уже сказано, что в данном конкретном случае коммерческая поддержка нецелесообразна. Случаи, когда она целесообразна, к сожалению, не знакомы поставщикам MikroTik, этот вопрос исчерпан. 1) Тут совершается серьезная логическая ошибка, вы приравниваете качество продукции одного разработчика к аналогичным продуктам второго, по всей видимости, не имея представления о первом и основываясь лишь на своих субъективных доводах. Важно заметить, что Linksys - это, действительно, не такая уж большая компания, купленная в последствии Cisco, качество продукции под сомнением. Fortinet же - это уже давно состоявшаяся компания с сильными решениями (не все у них идеально, но мы говорим про конкретные устройства). 2) Маршрутизаторы Dlink, как уже отметили никто не предлагал, а упомянутые в схеме коммутаторы дешевле предложенных вами. Похоже на попытку увести внимание читателя от дельных предложений. Тут вас куда-то уносит. Про сложности в создании трех вланов не говорилось, это как раз нормально. Комментарий был вызван вашим предложением создавать отдельные вланы на каждый порт, что крайне непрактично для корпоративной сети. И вот опять совершается уход в сторону. В корпоративной сети не нужна опция 82, это даже никто не предлагал. Достаточно выделить несколько вланов по типам устройств в сети, в идеале реализовать аутентификацию 802.1x. Категорически не понятно где тут проблема. Мной было рекомендовано устройство, в основные задачи которого как раз входит обеспечение безопасности, политики настраиваются очень гибко, а главное - просто - пользователю не нужно учитывать что в какую цепочку попадает, абстракции существенно выше. Не соглашусь, микротик настраивать проще только тем, кто уже имеет хороший опыт работы с ним. Многие другие разработчики не пытаются максимально расширять функционал, а оттачивают реально востребованный и сосредотачиваются на простоте конфигурации. От измерений длины команды в CLI воздержусь, простота в таких случаях заключается в качественных и понятных абстракциях и грамотном их отображении в GUI. Вот это как раз пример задач, которые отлично переносятся на сторонние устройства при необходимости, а необходимость эта в простой и отлаженной сети крайне редка, если вообще возникает.
  5. Мы же говорим про гигабитные линии, верно? Не важно будет ли у вас медный или оптический линк, скорость та же - 1Gbps.
  6. Также на картинке есть VPN-клиенты, сервер для которых вполне можно организовать на том же устройстве штатными средствами, желательно с шифрованием (да-да, MikroTik это тоже умеет). Например, трафик от камер к регистраторам и от авторизованных устройств к файловому серверу. Отмечу, что с авторизацией прекрасно справляется 802.1x и пользователи могут мирно существовать в одном VLAN, а для изоляции трафика между ними есть другие стандартные механизмы, не требующие создавать множество разных VLAN. То, что вы предлагаете, делают только в операторских сетях и причины там далеко не только в изоляции трафика. Нет, MikroTik, безусловно, хорош, но призван решать сразу множество задач, иногда довольно топорными методами. При наличие грамотного инженера работать, конечно, будет. О "мелких фирмочках" речи не шло, Fortinet - это компания с миллиардной капитализацией, которая специализируется как раз на таких корпоративных решениях, при чем предоставляет и довольно дешевые варианты. Зря затронул этот вопрос, посыл был в другом - наличии коммерческой поддержки с явным SLA, тут такое в общем-то не требуется. Опять же я не говорил, что в данном контексте есть нерашемые проблемы в ПО MikroTik, тут они исключительно в необходимости тюнить систему под задачу, в то время как есть специализированные устройства в ту же цену, где в еще более простой манере настраиваются политики маршрутизации и безопасности. Трафик в данном вопросе роли не играет, важно понимать какую физику вам проще эксплуатировать в данных условиях (оптика или медь). Из плюсов оптики можно отметить дешевизну самого волокна, малые размеры, неприхотливость к длине и наводкам, но минусы в вашем случае могут быть существеннее - требуется специальное оборудование и навыки для сварки при монтаже или восстановлении линии.
  7. 1) Ваш вопрос построен на ложном утверждении, я нигде не говорил, что производительности рекомендуемого маршрутизатора не хватит; 2) Смысл в том, что внутресетевой трафик можно разрулить и без участия маршрутизатора, снизив тем самым его стоимость и оставив запас на расширение по производительности/функционалу; 3) Смысл в применении специализированных решений, которые могут качественно решить поставленные задачи без необходимости лезть под капот; 4) Смысл в конце концов в возможности получить профессиональную поддержку, хотя тут она вероятно не потребуется, все легко настраивается, разве что cookbook почитать стоит. Пожалейте человека - не советуйте плохого, такие решения принимают от безысходности, а не потому что работает. 2-ядерный ARM не может качественно обработать достаточный объем трафика с большим набором правил, я уже не говорю про IPSec.
  8. @nic_123 с маршрутизацией в корпоративных сетях хорошо справляются недорогие FortiGate, на них помимо базового роутинга, NAT и Firewall также есть функционал IPSec/SSL-VPN сервера и расширенной защиты (IPS, антивирус, веб-фильтрация). Если использовать точки доступа Fortinet, то он же может выступать в роли контроллера для удобства управления и организации бесшовного роуминга. Конкретную модель следует выбирать, опираясь на вводные по нагрузке (как минимум объем трафика и количество VPN-сессий). В принципе с задачами небольшого офиса справится FG-40F стоимостью около 50к рублей. Для снижения нагрузки на маршрутизатор, конечно, следует добавить L3-коммутатор, который будет агрегировать линки с доступа и, например, гонять трафик до файлового сервера, а на маршрутизатор отдавать только трафик в интернет. SNR-S2995G-24FX или SNR-S2995G-24TX
  9. Для тех, кто не смог принять участие в вебинаре 15 мая, будет проведена повторная сессия 28 мая. Регистрация по ссылке.
  10. Абсолютно неверный вывод из написанного мной предложения, там ни слова об освобождении буфера. Дополню: "Пока 10GE порт выбирает уже записанные в буфер пакеты, порты 1GE успеют полностью или частично записать в буфер новые" В теории и регулярно подтверждается на практике. Теория эта кстати строится на дизайнах конкретных архитектур сетевых ASIC. Пакеты, действительно, чаще всего теряются не просто по случайности, а систематически и по вполне конкретным причинам. Как я уже выше отметил, проблема ТС наверняка связана с особенностями реализации SPAN в ASIC Marvell BobCat, на котором построен упомянутый коммутатор. Чипы Broadcom в большинстве своем таких проблем не имеют, в том числе чипы, на которых построены коммутаторы SNR-S2990G.
  11. @sdy_moscow верно, сначала кадр должен быть полностью записан в буфер, условно это 1500 байт данных. Для приема такого пакета через порт 1GE и его последующей записи в буфер потребуется немногим больше 12мкс, в то же время 10GE порт выберет все данные примерно за 1.2мкс. В итоге 10GE порт за те же 12мкс может поочередно забрать 10 уже записанных в буфер пакетов. Если предположить, что пакеты "непрерывно" и одновременно поступают с десяти 1GE портов, для их хранения потребуется условных 15000 байт и еще 15000 байт свободного места для непрерывной записи следующих пакетов, размер же буфера в таком коммутаторе, как правило, составляет не менее 1.5МБ. То есть даже в более тяжелом случае (10x1GE -> 1x10GE) 10GE порт успевает забрать из буфера достаточное количество пакетов, при этом от буфера потребуется до 2% емкости, а за время выгрузки пакетов как раз запишутся новые.
  12. @sdy_moscow для копирования трафика из нескольких гигабитных портов в десятку не нужен большой буфер, 10GE порт выгребает трафик из буфера быстрее, чем он наполняется. Большой буфер может потребоваться в обратной ситуации. MES3124 давал потери, так как пострен на чипе Marvell BobCat, который архитектурно имеет проблемы с копированием трафика.
  13. Это про отдельных абонентов или трафик вообще? Если сессии одного абонента все же раскидывает по разным DPI, желательно собрать больше информации о конкретных сессиях. Снизу только дефолтные eBGP-маршруты имелись или еще что-то было?
  14. @Avensis все DPI подключены к одному маршрутизатору? Вообще похоже, что балансировка и по порту осуществляется, в итоге разные потоки попадают в разные пулы NAT. Также стоит убедиться, что сам DPI мапит разные сессии одного абонента в один IP.