ViacheslavR

подскажите каким образом можно исключить закольцовывание пакетов, при отсутствии целевого ppp интерфейса, между бордером и насом?

Подскажите есть ли в accel-ppp опция ограничения общего числа активных соединений, т.е. аналог set link max-children[nnnn]?

Возможно. Я для общего развития спросил, можете объяснить?

по своей проблеме: откатился на 1.7.4 все работает. Объясните пожалуйста взаимосвязь правильной работы шейпера и отключения оффлоадов на интерфейсах. Т.е. когда они включены скорость режется неправильно, а с отключением ethtool -K eth0 tso off ufo off gso off gro off lro off все работает как надо?

Корку собрал, отправил xeb'у

Добрый день! Система Debian Wheezy 7.7 root@nas7:/var/log/accel-ppp# uname -r 3.2.0-4-amd64 Конфиг [modules] log_file pppoe auth_mschap_v2 auth_mschap_v1 auth_chap_md5 radius sigchld shaper connlimit [core] log-error=/var/log/accel-ppp/core.log thread-count=12 [common] single-session=replace sid-case=lower #sid-source=seq [ppp] verbose=1 min-mtu=1280 mtu=1400 mru=1400 accomp=allow pcomp=allow ccp=1 check-ip=1 mppe=require ipv4=require ipv6=deny ipv6-intf-id=0:0:0:1 ipv6-peer-intf-id=0:0:0:2 ipv6-accept-peer-intf-id=1 lcp-echo-interval=20 lcp-echo-failure=3 lcp-echo-timeout=120 unit-cache=100 [client-ip-range] 10.0.0.0/8 [auth] #any-login=0 #noauth=0 [pppoe] verbose=1 interface=vlan3 ac-name=nas7-accel service-name=* called-sid=mac [dns] dns1=8.8.8.8 dns2=8.8.4.4 [radius] dictionary=/usr/local/share/accel-ppp/radius/dictionary nas-identifier=nas7-accel nas-ip-address=10.11.12.23 gw-ip-address=10.0.0.1 server=10.11.12.14,password,auth-port=1812,acct-port=1813,req-limit=50,fail-timeout=0,max-fail=10,weight=1 dae-server=10.11.12.23:3799,password verbose=1 timeout=10 max-try=3 acct-timeout=120 [log] log-file=/var/log/accel-ppp/accel-ppp.log log-emerg=/var/log/accel-ppp/emerg.log log-fail-file=/var/log/accel-ppp/auth-fail.log copy=1 level=5 [shaper] attr-down=PPPD-Downstream-Speed-Limit attr-up=PPPD-Upstream-Speed-Limit up-limiter=police down-limiter=tbf verbose=1 [cli] verbose=1 telnet=127.0.0.1:2000 tcp=127.0.0.1:2001 [connlimit] limit=10/min burst=3 timeout=60 При попытке установить соединение, либо ввести команду show sessions accel крашиться [2014-12-12 12:32:18]: msg: accel-ppp version 904bc0f9eefffff153282277ea21729f46c1489d [2014-12-12 12:32:39]: debug: connlimit: check entry 35800397930696 [2014-12-12 12:32:39]: debug: connlimit: add entry 35800397930696 [2014-12-12 12:32:39]: debug: connlimit: accept 35800397930696 [2014-12-12 12:32:39]: info: recv [PPPoE PADI c8:60:00:6e:8f:20 => ff:ff:ff:ff:ff:ff sid=0000 <Service-Name > <Host-Uniq 74520000>] [2014-12-12 12:32:39]: info: send [PPPoE PADO 00:25:90:ec:42:85 => c8:60:00:6e:8f:20 sid=0000 <AC-Name nas7-accel> <Service-Name *> <Service-Name > <AC-Cookie 61449d4c15dfbb2baca782f227baaa82e2b1eb9b3a27bb92> <Host-Uniq 74520000>] [2014-12-12 12:32:44]: info: recv [PPPoE PADR c8:60:00:6e:8f:20 => 00:25:90:ec:42:85 sid=0000 <Service-Name > <Host-Uniq 74520000> <AC-Cookie 61449d4c15dfbb2baca782f227baaa82e2b1eb9b3a27bb92>] [2014-12-12 12:32:44]: info: send [PPPoE PADS 00:25:90:ec:42:85 => c8:60:00:6e:8f:20 sid=0001 <AC-Name nas7-accel> <Service-Name > <Host-Uniq 74520000>] [2014-12-12 12:32:44]: info: ppp0: connect: ppp0 <--> pppoe(c8:60:00:6e:8f:20) [2014-12-12 12:32:44]: debug: ppp0: lcp_layer_init [2014-12-12 12:32:44]: debug: ppp0: auth_layer_init [2014-12-12 12:32:44]: debug: ppp0: ccp_layer_init [2014-12-12 12:32:44]: debug: ppp0: ipcp_layer_init [2014-12-12 12:32:44]: debug: ppp0: ipv6cp_layer_init [2014-12-12 12:32:44]: debug: ppp0: ppp established [2014-12-12 12:32:44]: debug: ppp0: lcp_layer_start [2014-12-12 12:32:44]: info: ppp0: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1400> <magic 6b8b4567> <pcomp> <accomp>] [2014-12-12 12:32:44]: info: ppp0: recv [LCP ConfReq id=1 <mru 1492> <magic 915c5245>] [2014-12-12 12:32:44]: info: ppp0: send [LCP ConfAck id=1 ] [2014-12-12 12:32:44]: info: ppp0: recv [LCP ConfRej id=1 <pcomp>] [2014-12-12 12:32:44]: info: ppp0: send [LCP ConfReq id=2 <auth MSCHAP-v2> <mru 1400> <magic 6b8b4567> <accomp>] [2014-12-12 12:32:44]: info: ppp0: recv [LCP ConfRej id=2 <accomp>] [2014-12-12 12:32:44]: info: ppp0: send [LCP ConfReq id=3 <auth MSCHAP-v2> <mru 1400> <magic 6b8b4567>] [2014-12-12 12:32:44]: info: ppp0: recv [LCP ConfAck id=3 <auth MSCHAP-v2> <mru 1400> <magic 6b8b4567>] [2014-12-12 12:32:44]: debug: ppp0: lcp_layer_started [2014-12-12 12:32:44]: debug: ppp0: auth_layer_start [2014-12-12 12:32:44]: info: ppp0: send [MSCHAP-v2 Challenge id=1 <b7ec65435d6cb55bd6f5bfe6a6271f5>] [2014-12-12 12:32:44]: debug: ppp0: recv [LCP EchoReq id=0 <magic 915c5245>] [2014-12-12 12:32:44]: debug: ppp0: send [LCP EchoRep id=0 <magic 6b8b4567>] [2014-12-12 12:32:44]: info: ppp0: recv [MSCHAP-v2 Response id=1 <caf45f3a21f2ac5ecda3992c5183a173>, <13ad284f96daa66d2a618e881eb9868c9959e66aa18f9>, F=0, name="first"]

pptp-драйвер... он в ведь должен загружаться как модуль или нет? в lsmod его не наблюдаю.

Добрый день! Система Centos 7 x64 при попытке собрать accel-ppp вылетает ошибка: В чем может быть дело?

kern.ipc.somaxconn=32768 - защита от synflood. "Large listen queues do a better job of avoiding Denial of Service (DoS) attacks".(FreeBSD Handbook) net.inet.tcp.syncookies=1 Включение механизма syncookie когда syncache переполнен, тоже защита от ddos net.inet.tcp.drop_synfin=1 - T/TCP не нужен net.inet.tcp.msl=7500 -60 сек в состоянии TIME_WAIT долго(default 30000) 15 сек хватит net.inet.tcp.sack.enable=1 TCP Selective Acknowledgements RFC2018 http://tools.ietf.org/html/rfc2018 net.inet.tcp.fast_finwait2_recycle=1 -быстрое закрытие соединений в состоянии fin_wait2

А что там лишнего? на мой взгляд вполне себе обычные настройки для таких задач. UPD 1) убрал с интерфейсов igb lrob tso, добавил vlanhwfilter, txcsum, rxcsum 2) Заметил что ошибки mbuf, mbuf+cluster начинают расти только при отключении/включении интерфейсов igb немного снизился load average, вторые сутки полет нормальный. ------------------- Т.к. ната нет, то планирую убрать нетфлоу с каждой ноды, а снимать только с внешнего интерфейса, кроме того наверное отключу HT

mpd.conf #netflow export set netflow peer aa.bb.cc.dd 2009 set netflow timeouts 60 120 ............................... set iface enable netflow-in netflow-out ................................... честно говоря не уверен насчет нетфлоу, т.к. есть еще сервера с абсолютно теми же настройками правда под 8.1, 8.2 Собственно до 10-ки этот же сервак крутился на 9.2, глюки те же.

x64, да использую, количество всегда разное может даже и при минимальной нагрузке рухнуть. Минимум на нем 150 сессий максимум до 1000.

Добрый день. Имеется сервер который раз в 2-3 дня ядро фряхи на котором паникует, в результате чего сервер перезагружается. Нагрузка судя по cacti с ребутами никак не коррелирует. FreeBSD 10.0-RELEASE-p5 Ядро кастомное добавлен только NetGraph На что подозрения: netstat -m [quote]65555/6955/72510 mbufs in use (current/cache/total) 65542/3682/69224/512000 mbuf clusters in use (current/cache/total/max) 65542/3664 mbuf+clusters out of packet secondary zone in use (current/cache) 0/18/18/256000 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/301750 9k jumbo clusters in use (current/cache/total/max) 0/0/0/169734 16k jumbo clusters in use (current/cache/total/max) 147472K/9174K/156647K bytes allocated to network (current/cache/total) [b]1427/39763/65831 requests for mbufs denied (mbufs/clusters/mbuf+clusters)[/b] 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 18/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile [/quote] vmstat -z [quote]ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 384, 0, 101, 9, 101, 0, 0 UMA Zones: 3712, 0, 101, 0, 101, 0, 0 UMA Slabs: 80, 0, 3154, 46, 24692, 0, 0 UMA RCntSlabs: 88, 0, 34634, 16, 34634, 0, 0 UMA Hash: 256, 0, 1, 14, 8, 0, 0 4 Bucket: 32, 0, 34, 2966, 1331, 0, 0 8 Bucket: 64, 0, 157, 2881, 7424, 0, 0 [b]16 Bucket: 128, 0, 288, 2719, 551, 36, 0 32 Bucket: 256, 0, 262, 1463, 862, 159, 0 64 Bucket: 512, 0, 408, 360, 1109, 119, 0 128 Bucket: 1024, 0, 914, 898, 18165, 26, 0 vmem btag: 56, 0, 19223, 1864, 19223, 298, 0 VM OBJECT: 256, 0, 1567, 1913, 155768, 0, 0 RADIX NODE: 144, 0, 5755, 1886, 301975, 59, 0[/b] MAP: 240, 0, 3, 61, 3, 0, 0 KMAP ENTRY: 128, 0, 6, 273, 6, 0, 0 MAP ENTRY: 128, 0, 823, 4695, 471875, 0, 0 VMSPACE: 448, 0, 25, 794, 11021, 0, 0 fakepg: 104, 0, 0, 0, 0, 0, 0 mt_zone: 4112, 0, 364, 0, 364, 0, 0 16: 16, 0, 9394, 1901, 640000, 0, 0 32: 32, 0, 24170, 3205, 772980, 0, 0 64: 64, 0, 54924, 2178, 320171, 0, 0 128: 128, 0, 133083, 3348, 543027, 0, 0 256: 256, 0, 3258, 1332, 259155, 0, 0 512: 512, 0, 1294, 450, 32583, 0, 0 1024: 1024, 0, 108, 752, 73759, 0, 0 2048: 2048, 0, 246, 162, 16089, 0, 0 4096: 4096, 0, 602, 351, 19095, 0, 0 uint64 pcpu: 8, 0, 6300, 1508, 6732, 0, 0 SLEEPQUEUE: 80, 0, 526, 2357, 526, 0, 0 Files: 80, 0, 135, 3015, 99306, 0, 0 TURNSTILE: 136, 0, 526, 1014, 526, 0, 0 rl_entry: 40, 0, 314, 2686, 314, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1208, 0, 44, 166, 11039, 0, 0 THREAD: 1168, 0, 397, 128, 2158, 0, 0 cpuset: 72, 0, 206, 1554, 274, 0, 0 audit_record: 1248, 0, 0, 0, 0, 0, 0 [b]mbuf_packet: 256, 13035630, 65527, 3679, 1191484,65831, 0 mbuf: 256, 13035630, 25, 3354, 1054682,1491, 0 mbuf_cluster: 2048, 512000, 69206, 18, 69206,39763, 0 mbuf_jumbo_page: 4096, 256000, 0, 22, 196, 22, 0[/b] mbuf_jumbo_9k: 9216, 301750, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 169734, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 NetGraph items: 72, 65565, 1, 3378, 111256, 0, 0 NetGraph data items: 72, 65565, 1, 3874, 997677, 0, 0 g_bio: 248, 0, 0, 1648, 14061, 0, 0 ttyinq: 160, 0, 180, 920, 765, 0, 0 ttyoutq: 256, 0, 95, 1015, 407, 0, 0 ata_request: 336, 0, 0, 0, 0, 0, 0 vtnet_tx_hdr: 24, 0, 0, 0, 0, 0, 0 FPU_save_area: 832, 0, 0, 0, 0, 0, 0 VNODE: 472, 0, 777, 383, 818, 0, 0 VNODEPOLL: 112, 0, 0, 0, 0, 0, 0 BUF TRIE: 144, 0, 101, 105847, 1045, 0, 0 NAMEI: 1024, 0, 0, 340, 161661, 0, 0 S VFS Cache: 108, 0, 763, 2387, 7058, 0, 0 STS VFS Cache: 148, 0, 0, 0, 0, 0, 0 L VFS Cache: 328, 0, 0, 0, 0, 0, 0 LTS VFS Cache: 368, 0, 0, 0, 0, 0, 0 DIRHASH: 1024, 0, 54, 78, 54, 0, 0 NCLNODE: 528, 0, 0, 0, 0, 0, 0 Mountpoints: 816, 0, 4, 36, 4, 0, 0 pipe: 744, 0, 13, 342, 8399, 0, 0 procdesc: 128, 0, 0, 0, 0, 0, 0 ksiginfo: 112, 0, 201, 2564, 238, 0, 0 itimer: 352, 0, 1, 32, 1, 0, 0 KNOTE: 128, 0, 3, 152, 3, 0, 0 socket: 696, 1046775, 57, 363, 41130, 0, 0 unpcb: 240, 1046784, 12, 1460, 8546, 0, 0 ipq: 56, 16046, 0, 0, 0, 0, 0 udp_inpcb: 392, 1046780, 19, 801, 32328, 0, 0 udpcb: 16, 1046921, 19, 2993, 32328, 0, 0 tcp_inpcb: 392, 1046780, 7, 603, 139, 0, 0 tcpcb: 1024, 1046776, 7, 269, 139, 0, 0 tcptw: 88, 27810, 0, 0, 0, 0, 0 syncache: 160, 15375, 0, 450, 28, 0, 0 hostcache: 136, 15370, 1, 86, 1, 0, 0 tcpreass: 40, 32000, 0, 0, 0, 0, 0 sackhole: 32, 0, 0, 0, 0, 0, 0 sctp_ep: 1408, 1046776, 0, 0, 0, 0, 0 sctp_asoc: 2352, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80012, 0, 2324, 114, 0, 0 sctp_raddr: 728, 80000, 0, 0, 0, 0, 0 sctp_chunk: 136, 400026, 0, 0, 0, 0, 0 sctp_readq: 104, 400026, 0, 0, 0, 0, 0 sctp_stream_msg_out: 104, 400026, 0, 0, 0, 0, 0 sctp_asconf: 40, 400000, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400060, 0, 0, 0, 0, 0 ripcb: 392, 1046780, 0, 670, 89, 0, 0 rtentry: 200, 0, 466, 894, 506, 0, 0 IPFW dynamic rule: 120, 4125, 0, 0, 0, 0, 0 divcb: 392, 1046780, 0, 0, 0, 0, 0 selfd: 56, 0, 279, 2774, 978745, 0, 0 SWAPMETA: 288, 4073641, 0, 0, 0, 0, 0 FFS inode: 168, 0, 726, 1045, 765, 0, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 726, 1044, 765, 0, 0 NetFlow IPv4 cache: 88, 1048606, 3471, 3783, 32086, 0, 0 NetFlow IPv6 cache: 128, 1048606, 0, 0, 0, 0, 0 [/quote] Тюнинг loader.conf [quote]hw.igb.rxd=4096 hw.igb.txd=4096 hw.ix.rxd=4096 hw.ix.txd=4096 net.graph.maxdata=65536 net.graph.maxalloc=65536 hw.igb.max_interrupt_rate=32000 hw.ix.max_interrupt_rate=32000 net.isr.defaultqlimit=4096 net.link.ifqmaxlen=10240 kern.ipc.semmnu=256 kern.ipc.semmns=32000 kern.ipc.shmmni=4096 net.isr.maxthreads=18 kern.ipc.nmbufs=0 kern.ipc.nmbclusters=512000 kern.ipc.nmbjumbop=256000 [/quote] sysctl.conf net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 kern.ipc.somaxconn=32768 net.inet.tcp.syncookies=1 net.inet.icmp.bmcastecho=0 net.inet.tcp.drop_synfin=1 net.inet.icmp.drop_redirect=1 net.inet.icmp.log_redirect=0 net.inet.ip.redirect=0 net.inet6.ip6.redirect=0 net.inet.ip.sourceroute=0 net.inet.ip.sourceroute=0 net.inet.icmp.maskrepl=0 net.inet.icmp.icmplim=10000 net.inet.tcp.msl=7500 net.inet.ip.portrange.first=1024 net.inet.ip.portrange.last=65535 net.inet.ip.intr_queue_maxlen=10240 net.route.netisr_maxqlen=10240 #kern.ipc.maxsockets=512000 net.inet.tcp.sack.enable=1 hw.intr_storm_threshold=9000 net.graph.maxdgram=8388608 net.graph.recvspace=8388608 kern.ipc.maxsockbuf=83886080 kern.maxfiles=512000 kern.maxfilesperproc=131072 #kern.ipc.nmbufs=0 kern.ipc.nmbclusters=512000 kern.ipc.nmbjumbop=256000 kern.ipc.nmbjumbo9=128000 kern.ipc.nmbjumbo16=64000 kern.random.sys.harvest.ethernet=0 kern.random.sys.harvest.point_to_point=0 kern.random.sys.harvest.interrupt=0 net.inet.raw.maxdgram=16384 net.inet.raw.recvspace=16384 kern.threads.max_threads_per_proc=16384 net.inet.ip.fastforwarding=1 net.inet.tcp.fast_finwait2_recycle=1 ########################### dev.igb.0.rx_processing_limit=4096 dev.igb.1.rx_processing_limit=4096 dev.ix.0.rx_processing_limit=4096 dev.ix.1.rx_processing_limit=4096 Сетевые карты igb Intel I350

вот решил отписаться как была решена эта проблема: 1) Скачиваем исходники pppoe-relay с сайта http://www.roaringpenguin.com/products/pppoe 2) Внимательно изучив исходники обнаруживаем интересные вещи такие как хеш таблицы вида (клиент-RelaySessionID- SessionId -acPPPoE) /* Session state for relay */ struct SessionHashStruct; typedef struct SessionStruct { struct SessionStruct *next; /* Free list link */ struct SessionStruct *prev; /* Free list link */ struct SessionHashStruct *acHash; /* Hash bucket for AC MAC/Session */ struct SessionHashStruct *clientHash; /* Hash bucket for client MAC/Session */ unsigned int epoch; /* Epoch when last activity was seen */ UINT16_t sesNum; /* Session number assigned by relay */ } PPPoESession; /* Hash table entry to find sessions */ typedef struct SessionHashStruct { struct SessionHashStruct *next; /* Link in hash chain */ struct SessionHashStruct *prev; /* Link in hash chain */ struct SessionHashStruct *peer; /* Peer for this session */ PPPoEInterface const *interface; /* Interface */ unsigned char peerMac[ETH_ALEN]; /* Peer's MAC address */ UINT16_t sesNum; /* Session number */ PppoeSessionFunctionTable *ses; /* Session data */ } SessionHash; /* Function prototypes */ Итак значит при каждом запуске экземпляра pppoe-relay создается такой вот связный список в котором релей "помнит" об интерфейсе которому предназначен трафик маркированный SessionID. В моем случае трафик предназначенный для абонента одного вилана дублировался в другие, так как в списке создаваемом другим процессом мака для которого предназначен этот трафик не было и естественно в arp-таблице коммутатора этой записи тоже нет и поэтому он и отсылался на другие порты (аплинки в том числе). Решением может послужить указание всех пользовательских интерфейсов с которых нужен релей в одном процессе, чтобы в системе присутствовал один хеш-список. 3) В исходниках релея находим запись #define MAX_INTERFACES 8 и изменяем её на нужное вам количество прослушиваемых интерфейсов (указываемых в параметрах запуска pppoe-relay) 4) Собираем 5) Используем

а почему вы думаете что у нас не правильно? сделано было так вполне из рациональных соображений отграничения броадкаста с пользовательских вланов от сервака, который не должен тратить свою производительность на обработку этих пакетов. Ну и по мелочи всякое. В конце концов нам так удобней. Тем не менее проблема явно не из-за архитектурных недостатков.