SABRE

Какие ещё правила есть? Conntrack другие ивенты показывает, кроме gre?

Прежде всего спасибо за Вашу работу - модуль действитеьно очень нужет и является хорошим решением между stateless NAT via iproute и stateful conntrack NAT. Проверил на тестовом сервере - действительно NAT для GRE отрабатывает, но в сессиях записи об этом протоколе нет. Дописал часть правил чтобы клиентов, которые используют PPTP натить через conntrack: ipset -N -! ct_fallback hash:ip iptables -t raw -A PREROUTING -s <grey_net> -p tcp --dport 1723 -m set ! --match-set ct_fallback src -j SET --add-set ct_fallback src iptables -t raw -A PREROUTING -s <grey_net> -p gre -m set ! --match-set ct_fallback src -j SET --add-set ct_fallback src iptables -t raw -A PREROUTING -m set --match-set ct_fallback src -j RETURN iptables -t raw -A PREROUTING -s <grey_net> -j CT --notrack iptables -t raw -A PREROUTING -d <nat_pool> -j NAT --dnat iptables -A FORWARD -d <grey_net> -j ACCEPT iptables -A FORWARD -m set --match-set ct_fallback src -j ACCEPT iptables -A FORWARD -s <grey_net> -j NAT --snat iptables -t nat -A POSTROUTING -m set --match-set ct_fallback src -j SNAT --to-source <NAT_IP_for_fallback>

А вообще GRE, можно спокойно запустить через Linux conntrack NAT, и тогда вообще не вижу проблем.

Ну не знаю, Pptp в 19году... У нас сейчас жалоб не было.

@LostSoul я предлагаю перейти в отдельную тему. Что касается GRE, то нашел это: What has changed with the 3.18.x kernel : if neither nf_conntrack_pptp nor nf_conntrack_proto_gre are loaded, any GRE packet is INVALID. Не могут пакеты просто так пропадать в ядре. Посмотрите в момент создания соединения conntrack -E (events)   @all Итак по прошествию ЧНН могу заключить что нагрузка упала вдвое, что вполне ожидаемо изза полного отключения conntrack. Когда-то мы уже подходили к этому вопросу и выключали его доя пользователей с белым IP, что дало пропорциональное снижение нагрузкию Здесь же получилось убрать conntrack полностью.

Итак, я внедрил на одном из серверов (BRAS +BORDER): root@gw1:~# uname -r 3.16.0-7-amd64 root@gw1:~# accel-cmd show stat uptime: 107.08:11:44 cpu: 0% mem(rss/virt): 12172/134184 kB core: mempool_allocated: 4841775 mempool_available: 1413623 thread_count: 1 thread_active: 1 context_count: 3237 context_sleeping: 0 context_pending: 0 md_handler_count: 1722 md_handler_pending: 0 timer_count: 3371 timer_pending: 0 sessions: starting: 0 active: 1672 finishing: 1 ipoe: starting: 0 active: 1673 delayed: 0 radius........... root@gw1:~# cat /etc/debian_version 8.11 root@gw1:~# cat /proc/sys/net/netfilter/nf_conntrack_count 189 root@gw1:~# cat /proc/net/NAT/statistics Active NAT sessions: 49288 Tried NAT sessions: 9028921 Created NAT sessions: 9026387 DNAT dropped pkts: 34247488 Fragmented pkts: 0 Related ICMP pkts: 2254633 Active Users: 1408 Все юзеры переведены с conntrack на ipt_NAT. CPU 2*E5645 @ 2.4GHz; Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) В среднем нагрузка за счет отключения conntrack упала в два раза, посмотрю и сравню в ЧНН. (на модуль преключился около 11:00 19.07 на графике)

@LostSoul вообще интересно) iptables -t raw -nvL iptables -t nat -nvL может оно уже чем-то до этого натится? conntrack | grep gre

Тогда и модули не интересно) Можете создать тестовое правило в raw с селектором такого типа пакетов, попадают ли они вообще туда? Если да, смотрим дальше iptables, нет - tcpdump и ingress фильтры

Можете пожалуйста показать conntrack для такой gre сессии и вывод lsmod?

У нас такая-же беда. Писал по этому поводу - никто не ответил.

Раньше приводило к kernel panic. Не знаю как сейчас:

AlKov accel-ppp.conf [shaper] attr=Filter-Id ifb=ifb0 #DO NOT USE POLICE!!! up-limiter=htb down-limiter=htb leaf-qdisc=sfq perturb 10 Вот в таком формате отдается с радиуса (accel-ppp.log ): [2017-12-12 14:21:39]: info: ipoe216: recv [RADIUS(1) Access-Accept id=1 <Filter-Id "10240/10240"> <L4-Redirect 1> <DHCP-Lease-Time 150> <Session-Timeout 300> <DHCP-Client-IP-Address 10.128.16.107>]

Здравствуйте, используем Accel-ppp c гита. В логах наблюдаются сообщения dhcpv6: unmatched Client-ID option: [2017-12-01 16:12:32]: info: bond0.1952.406: recv [DHCPv6 Request XID=ef7840 <Client-ID 1:000121b3af76d46e0e50d2e5> <Server-ID 3:001b0000000000000001> ... [2017-12-01 16:12:32]: error: bond0.1952.406: dhcpv6: unmatched Client-ID option При этом если Client-ID вида <Client-ID 3:0001d46e0ea945cd> проблем нет, соответственно в дампе видно постоянные DHCPv6 Request и через время опять Solicit->Advertise->Request,Request.... С теми же ошибками в логах. Никто не сталкивался?

А зачем вообще сервера нужны? Разве микротик не умеет metarouter? Почему вы еще не заменили все сервера на микротики?

Лучше поставить микротик перед IPMI - он всегда будет пинговаться.

А в любом стучае нужно указывать match. Т.ч. я думаю, не важно что именно матчить.

Без. Это лишь разные механизмы управления трафиком. А разве этот трафик в дефолтный класс HTB не попадает?

kayotbomberman просто в фильтре, вместо назначения classid сделать action police.

accel-ppp

А RPS в этом случае не помогает?

Есть вопрос по IPv6. сейчас фильтры добавляются с protocol ip, и ipv6 трафик не шейпится, возможно ли изменить протокол на all чтобы в шейпер так-же попадали и в6 пакеты?

Да это то что нужно - теперь стабильно. xeb, большое спасибо. Хотел спросить, кто использует IPoE и IPv6 - я так понял IPv6 адреса не добавляются в сет l4redirect? Кто как выходит из ситуации, когда у клиента необходимо сделать редирект?

Тоже в grub.conf

AlKov добавьте параметры processor.max_cstate=1 intel_idle.max_cstate=0 intel idle всегда рекомендуют выключать. Похоже это ваш случай. А в БИОС поотключайте все EIST/C-State и т.п.

Dimka88 Если оно пытается удалить уже удаленную сессию, думаю, утечки не будет. Нужно понаблюдать. Плюс раньше это было гарантированное падение.