dvb2000

mc-lag это то чего не может быть на коммутаторах уровня доступа, а может и должно быть только на уровне ядра сети. И по этому требуется использовать дополнительный коммутатор, который будет выполнять функции уровня доступа. Он будет подключен к этим двум коммутаторам портами Uplink через mc-lag и к нему уже будут подключаться PC1, PC2 и т.д. через его порты доступа. И вот тогда уже сохраниться отказоустойчивость и агрегация для сервера debian.

Если речь идёт вообще об привилегиях управления, а не о чём то другом, то номер атрибута не 26, а 29, и он вообще integer. Это ведь поиском за секунду находится тут: freeradius-server/share/dictionary/radius/dictionary.huawei at master · FreeRADIUS/freeradius-server · GitHub или даже тут: FAQ-Assign different privilege level for Radius users that login though SSH on device- Huawei

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

Не знаю сколько такое стоит в мск, не был там уже лет 35, но на заподе или у нас на самом ближнем востоке, такое стоит начиная с 1.6K американских рублей. Например тут: https://mitxpc.com/products/sys-e302-9d https://www.thinkmate.com/system/superserver-e302-9d https://www.lambda-tek.com/Supermicro-SYS-E302-9D~sh/B44387213&viewSpec=y Только стоит взять во внимание что это ценна базовой конфигурации. Больший объём оперативной памяти, диска NVME и т.д. добавляет дополнительную цену. Но за эти деньги такое решение не только более гибкое чем любая CISCO, но и долее дешёвая и более производительная. А если взять в сравнение какую не будь ASA близкую по производительности, то она будет стоить как стопка таких серверов.

Проще и приемлемее всего будет pfSense. Устанавливается за пару минут, готовый конфиг это XML файл, ставится на любое вменяемое железо, конфиг переносится за пару секунд на новое или более производительное железо, куча дополнительных бесплатных модулей, начиная от SNORT и до FreeRADIUS. Есть возможность горячего резервирования и т.д. А если нужно железку под него, то можно от того что есть в али экспресс и до такого: https://www.supermicro.com/en/products/system/iot/1u/sys-e302-12d-4c У которого пассивное охлаждение, процессор Ice Lake Xeon D-1718T с аппаратным ускорением для шифрования, два порта до 25G, возможность установить до 256GB: ECC RDIMM, порт IPMI и много чего полезного. И всё это в мини форм факторе. А если достаточно портов на 10G, то можно и такой прибор: https://www.supermicro.com/en/products/system/mini-itx/sys-e302-9d.cfm

Если нужно бюджетные, то тогда любые поддерживающие OpenWRT. Это даёт возможность выбора для любого бюджета. И возможности не только привязки SSID к VLAN, но и динамического присваивания клиента к разным VLAN в одном SSID и только по средствам учётной записи с нужными атрибутами в RADIUS. А это даёт так же и централизованное управление беспроводными клиентами.

Я вот вижу статистику по которой достаточно много гигабитных портов доступа у домашних пользователей постоянно утилизированы на 80%, торрент трафиком в обе стороны. И достаточно чтоб на одном коммутаторе было один, два таких пользователей чтоб положить доступ остальным, если аплинк этого коммутатора, тоже гигабитный, или же LAG из нескольких гигабитных портов, на пару десятков гигабитных юзеров.

Использовать коммутатор доступа в котором на 24 гига трафика, аплинк на 4 порта по 1 гига, это довольно сомнительное удовольствие и для провайдера и для его пользователей. Не говоря уже о фичерсет этого коммутатора. Если уже дилинк, то хатыбы уже как минимум DGS-1510, который может подключаться 10G портами к агрегационному коммутатору сети провайдера.

Приветствую Вас. Одно дело что маршрутизатор 3945 стоит между интернет и asterisk, и именно как маршрутизатор это одна нагрузка на 3945. Другое дело если этот 3945 ещё и держит NAT таблицу, это уже другая нагрузка на него, и совсем не дело требовать от 3945 анализировать SIP траффик приходящий со стороны интернета. И проблема тут скорее всего совершенно не с RTP, а именно с самим SIP и с пробами регистрации на него всех тех ботов что сканируют все белые адреса. И именно по этому Cisco 3945 тут не приемлем, так как на наружном адресе (между интернетом и Asterisk) должны стоять те устройства которые я описал выше, или же подобные им, а не как не Cisco 3945.

Чтоб ставить между Asterisk и интернетом что то вроде такого cisco 3945 нужно быть очень мужественным человеком. То что на Asterisk имеется fail2ban это не мешает загрузить канал и на 1G и даже более широкий запросами спамеров и скамеров приходящими с простор интернета. И чем дольше Asterisk будет светиться в интернет, тем больше таких запросов будет приходить, пока его база не развалится от переполнения логов от этих запросов, даже если они режутся в fail2ban после нескольких неудачных повторов. Чтоб защитить SIP SoftSwitch от угроз приходящих с бескрайних простор интернета требуется несколько простых программных приспособлений. Все они могут быть бесплатными, например модулями на базе pfSense. Первое это обновляющиеся чёрные списки файрволла. В pfSense это зовётся pfBlockerNG. Если поглядеть на статистику этого модуля сразу становится ясно для чего он нужен: Запросы на порт SIP составляют 30% от всех проб ломать чего либо. Второе приспособление это модуль IPS/IDS именуемый SNORT, который в реальном времени мониторит весь трафик и режет вредные подключения. После того как всё настроено, в fail2ban пробираются максимум пару левых запросов за месяц, как можно видеть в следующем скрине:

Логирование настраивают до того как проблема проявляется. Если ждать что будет что то не нормально и только потом вспоминать об настраивании логирования, то не на что будет посмотреть.

В кое каких программах ( включая и BIRD ) есть такое секретное новшество которое зовётся LOG. По словам людей приближённых к компьютерному сообществу если его настроить то оно даёт возможность понять что происходит перед тем как: "Сессия просто переходит в состояние Init". Так можно понять что вообще к этому приводит и чем это вызвано.

Советую использовать TTLS, так как в Windows клиентах mschapv2 и PEAP дефольтно использует не только введённое UserName, а добавляет к нему разные приставки, которые радиус воспринимает как не валидного пользователя. В логах радиуса проще всего проверить что не так. Например скрин релевантных логов, где виден тот же клиент который один раз настроен подключатся PEAP, а другой раз TTLS.

802.1x или если его называть WPA-ENT это не какой-то там монолит, а это целый зоопарк ( набор ) EAP Types опций, которые функционируют независимо одна от другой. И по этому каждый клиент может выбирать подходящую для него в зависимости от возможностей его WPA супликанта. Например какой-то там андероид или Windows 10 выберает скажем TTLS, а вот китайпланшет или Windows 7 ломятся на PEAP. И поэтому для того чтоб разные клиенты могли подключаться тем способом которым они умеют требуется на NPS и на радиусе вменяемо настроить хотя бы самые распространённые из них. Вот например частичный список самых распространённых EAP Types EAP Types - Extensible Authentication Protocol Types (vocal.com) А вот простое объяснение про них: 802.1X Overview and EAP Types (intel.com) По этому стоит хотя бы для начала глянуть каким способом подключаются те клиенты которым да удаётся подключиться и каким те которым не удаётся, м попробовать настроить тот способ с который не функционирует. Также стоит проверить вменяемо вообще настроены сертификаты для радиус сервера и для NPS. Пример минимальных релевантных NPS настроек:

Можно то можно, но вот совсем не нужно, так как мало того что он загнётся уже при минимальной нагрузке, так ещё и возможностей в нём почти ни каких. Ну а если уж про то что можно но не нужно, то можно даже и встроенный в DGS-3120-48TC DHCP сервер использовать и он будет даже попроизводительнее и стабильнее чем тот что в DFL 860E. Но вот это то же не нужно по понятным причинам.