Sоrk

мы работаем после некоторого допиливания всё работает недавно даже доделали возможность создавать бандл-тарифы (Интернет+Омега).

мы тоже столкнулись - 40G не все, даже с включенным unsupported-transceiver

возможно мы не умеем продавать OTT/IPTV, но абонентов Кабельного ТВ (аналог+DVB-C) в 10 раз больше чем OTT ... особенно в новостройках да, внутреннее ощущение говорит "это же новая квартира, там должен быть Smart" ... но нет, есть любимая плазма Sony 60" и на ней смотрят аналог (не ставят даже приставку DVB-C) иногда людей сложно понять

добавил 15169:13300 на PNI с Google убрал 59613:100 с Giganet убрал 0:15169 и 0:36040 с DTEL в результате трафик остался на PNI с Google, раньше всегда убегал в одну из IX так что для меня 15169:13300 на стыке с Google - работает. но ... нужно ещё подождать

это включение в DTEL, на котором я в среду запретил анонсировать свои сети в сторону Google и GGC через DTEL.

+ 1 как раз на днях отключал анонсы в сторону Google через DTEL и картина такая:

Техническая поддержка по OLT BDCOM говорит следующее: в всех дальнейших версиях опрос будет происходить только так, как описано в файле "check mac address of onu by mib .docx" ,причем как на епон ,так и на жпон стандарте .. сделано это для оптимизации использования CPU необходимо в 1.3.6.1.4.1.3320.101.9.2.1.0 установить индекс ONU и после этого прочитать с 1.3.6.1.4.1.3320.101.9.2.3 записи FDB # snmpset -v2c -c private 10.1.1.1 1.3.6.1.4.1.3320.101.9.2.1.0 i 98 BDCOM-EPON-LLID::bdEponLlid.2.1.0 = INTEGER: 98 # snmpwalk -v2c -c private 10.1.1.1 1.3.6.1.4.1.3320.101.9.2.3 BDCO

Роутинг абонентов на на 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 получить меньшую нагрузку?