Sоrk

Роутинг абонентов на на 3064 не очень хорошая идея, сети управления ещё куда ни шло. Причины: - при каждом topology change очищается arp и mac-таблица (1-2 секунды пропадают пинги) - дефолтное значение copp-s-arp очень низкие и даже если выкрутить по максимуму - будут моменты дропов ARP даже для влана на 250 хостов (рандомное "пропадание интернета" у абонентов), можно вообще отключить copp, но быть готовым ко всему ...

Есть ещё 3й вариант, если нужно сделать vlan поверх lagg: create_args_lagg1="laggproto lacp laggport em0 laggport em1" ifconfig_lagg1="up" ifconfig_vlan123="vlan 123 vlandev lagg1 192.168.1.1/24" возможно после 8.0 что-то поменялось, но раньше - если делать vlan верх lagg то у интерфейса уменьшался MTU (vlan-интерфейс стартовал раньше чем поднимался LACP). В такой же конфигурации - сначала стартует LACP и только потом поверх него настраивается VLAN.

Есть, но те что дали в TP-link на всю первую страницу пишут что они BETA. так же, они не дали механизма как обновить уже установленные роутеры. и проблема не только в TP-Link, а такие МАК-адреса попадаются на оборудовании UBNT, прошивках OpenWRT, мобильных устройствах с функцией "случайный МАК при каждом подключении", на виртуальных машинах, Dual-WAN роутерах. И достаточно было одного такого "качальщика" на vlan, чтобы были проблемы по вечерам у всего EPON-порта. Конечно plan-per-user спасает, но не у всех он и не везде.

С помощью DEPS показали Китайцам проблему с зеркалированием (по сути происходило "unknown unicast flood") Выпущена тестовая прошивка 10.1.0F Build 71984 Получен новый tiger.blob (размер файла 2114772, строка из файла - iROS Tiger3 4.2.7.67 Apr 16 2019 17:48:38). Из изменений: - OLT больше не отдаёт полную FDB по SNMP (только опрос отдельных ONU) - все "locally administered MAC address" по "show mac address-table" теперь видны в таблице (раньше их не было) и они помечены как STATIC а не DYNAMIC (хотя работают как DYNAMIC) BDCOM(tm) P3616-2TE Software, Version 1

попробуйте тут - http://bdcom.mega.dp.ua/

Nexus 3064 - 48 портов 10g + 4 порта 40G все 48 портов могут работать на скорости 1G

Это блок "приватных" МАК-адресов, по аналогии с приватными блоками IP, которые могут повторяться и разных вендоров. И заблокировали BDCOM их судя по всему неспроста, их OLT некорректно обрабатывает, после включения "epon local-mac forward" весь трафик для данных МАКов отправляется на все ОНУшки ветки.

столкнулся с аналогичной проблемой - в некоторых ветках абоненты получают копию трафика других абонентов. После эксперементов выяснилось следующее: проблема связана с "locally administered MAC address" (пул "приватных МАК-адресов") (те самые x2:xx:xx:xx:xx:xx, x6:xx:xx:xx:xx:xx, xA:xx:xx:xx:xx:xx, xE:xx:xx:xx:xx:xx) и их обработкой на BDCOM после введения команды epon local-mac forward По факту получается такое: - весь трафик к МАК-адресам из этого пула отправляется всем абонентом EPON-порта - такие МАК-адреса не видны на EPON-порту и на самой OLT в таблиц

ipt_ratelimit - практически не влияет на CPU, на скорости 8 гбит/с включение-выключение шейпера показывает около 5% разницы

про опцию есть тут: http://www.major12.net/2014/05/high-cpu-load-with-freebsd-ipfw-nat.html сам столкнулся, при нагрузке в 2-3 gbit, если появлялся абонент, который начинал очень активно сканировать сеть (регистратор с вирусом) - нагрузка резко выростала до 100% Актуально было для freebsd 11, менялось ли что-то в 12й версии не знаю. Отключение опции решало проблему и не вызывало жалоб у абонентов. без same_ports при 128 внешних IP сервер с 4 Гб оперативной памяти легко держит 1 млн сессий.

Общался на одном из мероприятий с представителями Cloudflare - они не против того чтобы провайдеры выдавали 1.1.1.1 своим абонентам. Говорят что не устанавливают лимиты на количество запросов и нормально воспринимают NAT-адреса, за которыми сидят много абонентов.

на старой прошивке проявлялась аналогичная проблема, после обновления до 54184 больше не замечал (или небыло массовых пропаданий ...)

https://uablacklist.net/ такой?

уточнение, данный конфиг и графики с сервера на E5-1620 v2 (4 ядра), для Xeon E5-1650 v4 (6 ядер) производительность выше ровно пропорционально ядрам. сложно сказать благодаря этому или нет, но 1 млн NAT сессий на сервере живёт так вот же у меня отключен ipv6 и 4-5 гбит без проблем. Или имеется в виду для одной TCP-сессии? но ради эксперимента как-то попробую включить назад. Идея ровно в противоположном - помочь пользователям на нестабильном домашнем WiFi развивать большую скорость в один TCP-поток. Ради этого даже syncookies отк

и да, сервер занимается исключительно задачей NAT - никаких dummynet, dns, webserver, netflow/ipcad, dhcp rc.conf ifconfig_ix0="-tso4 -tso6 -lro -vlanhwtso" ifconfig_ix1="-tso4 -tso6 -lro -vlanhwtso" powerd_enable="YES" powerd_flags="-a maximum" tcp_restrict_rst="YES" tcp_drop_synfin="YES" icmp_drop_redirect="YES" icmp_log_redirect="YES" icmp_bmcastecho="NO" tcp_extensions="YES" все сети для статик-нат отправлены в blackhole (если такого не сделать и этот IP почему-то не попал в трансляцию/не занят весь входящих трафик на него будет попадать в L3 петлю BORDER<->NAT S

Настройки ядра: /usr/src/sys/amd64/conf/GENERIC - ничего особенного #options INET6 #disable IPv6 options IPFIREWALL options IPFIREWALL_NAT options IPFIREWALL_DEFAULT_TO_ACCEPT options HZ=1000 options NETGRAPH options NETGRAPH_IPFW options NETGRAPH_NAT options NETGRAPH_NETFLOW options NETGRAPH_SPLIT options NETGRAPH_ETHER options NETGRAPH_KSOCKET options NETGRAPH_SOCKET options NETGRAPH_BPF options NETGRAPH_IFACE options NETGRAPH_PPTPGRE options NETGRAPH_TCP

если кому-то интересно, то есть результаты попытки запустить NAT на VPP 18.10. пробовал режим nat44 - неудачно: - из-за невозможности привязать пул к внешнему IP пользователи постоянно получают разный IP (по мере использования портов). - PPTP VPN, FTP так и не работает через nat44 - и самое главное - постоянно падает под нагрузкой ~ 5-6 Gbit/s

ipfw kernel nat на Xeon E5-1650 v4 + Intel X520 + FreeBSD 12.0-RELEASE-p1 результат такой. Реально ли на PF NAT получить меньшую нагрузку?

вот Azure и AWS тоже наверное нетехнологичные компании и почему-то никак не дают публичные IP на сервера без NAT https://social.msdn.microsoft.com/Forums/azure/en-US/2b95cab8-f6b8-49fc-885f-8749a0d1213d/public-ip-without-nat?forum=WAVirtualMachinesVirtualNetwork https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-public-addresses

наблюдается аналогичная проблема на P3616-2TE с прошивкой 48290 (новая залита, но ребут еще не делали). при массовом пропадании электричества у абонентов минут на 20-40 пропадает из доступа (хотя сама не перегружается - UPS), трафик через себя форвардит (подключенные абоненты работают, абоненты в ethernet-портах работают), новых абонентов подключает очень медленно. конфиг перед инцидентами сохранялся (максимум 5-10 новых ONU подлючается) в шаблоне команды write нет если 3616 перегрузить не дожидаясь 20-40 минут, то все включаются сразу и без проблем.

в Украине фактически декрет - 70 дней до родов и 56 дней после родов (эти дни оплачиваются как больничный) + 10 тыс грн единоразово. Все остальные 3 года это пособие 800 грн, на которые можешь жить как хочешь в своё удовольствие. Так что мы можем гордиться заботой о матерях - 3 года бедности гарантировано и рекомендовано государством. На фоне реальности - 3-4-6-12 месяцев оплачиваемого декрета в других странах выглядят повеселее.

я имел в виду что результатом является только увеличение значения free памяти, никаких других улучшений это не даёт. что и логично, если inact память "отдалась" этому простому приложению, то она так же будет отдаваться любому другому.

#include <stdlib.h> #include <string.h> #include <unistd.h> int main(int argc, char** argv) { size_t s = 1024*1024*1024; /* 1 GB */ void* p = malloc(s); memset(p, 0, s); sleep(5); free(p); return 0; } вот такой код работает, превращает inact во free, но разница только в графиках в системе мониторинга. проверено на живом сервере, ничего не падает.

так же стоит убрать same_ports Детали тут: http://www.major12.net/2014/05/high-cpu-load-with-freebsd-ipfw-nat.html еще одно слабое место ipfw nat это redirect_address - если есть хотя-бы сотня таких трансляций и кто-то запустит интенсивное сканирование на этот диапазон, то 100% CPU гарантирован

мы тоже так вначале думали - давайте ставить IPTV-приставки ... не пошло, люди включаются к конкурентам у кого есть кабельное ТВ. Тогда мы решили - давайте сделаем цифровое ТВ, ведь у всех уже современные телевизоры и в них должно быть DVB-C ... Люди пошли, но оказалось что у них есть один нормальный телевизор и 3 старых, на который они не хотят покупать кабельную приставку ... В результате оказалось что аналоговое кабельное ТВ всё ещё пользуется спросом, что бы там не говорили что цифровое приёмник есть везде.