No_name Posted October 8, 2015 · Report post Есть два сервера один на freebsd 7.2, другой на 8.4, начну со второго пока. Итак, к серверу подключаются абоненты в режиме pptp. При интенсивном использовании торрента(во время пика загрузки по тарифу), через какое-то время(всегда по-разному) трафик обрывается, хотя линк с сервером держится и сервер пингуется. Это замечается как на вендовых клиентах, так и на тех кто на роутерах, причем, иногда такое случается даже при не интенсивном трафике, например при игре в линейку, но чаще на торрентах. На 7.2-RELEASE FreeBSD mpd4 -v Version 4.4.1 такая же фигня. По совету dadv попробовал(пока тока на 8.4) этот патч, но не помогло. Были или есть у кого подобные проблемы? Конфиги mpd5 -v Version 5.7 uname -a FreeBSD 8.4-RELEASE конфиг mpd 5.7: startup: set user error bsdfbhdfl admin set user userok xjrjgfq set radsrv peer х.х.х.х sdf5sd6g56sgsd set radsrv self х.х.х.х set radsrv open log auth -bund -ccp -chat -console -echo -ecp -frame -fsm -iface -ipcp -ipv6cp -lcp -link -phys -radius -radius2 -rep default: load pptp_server pptp_server: create bundle template B set iface enable tcpmssfix set ipcp dns 77.88.8.8 77.88.8.1 set bundle enable compression set ccp yes mppc set mppc yes e40 set mppc yes e128 set mppc yes stateless set iface up-script /usr/local/etc/mpd5/up set iface down-script /usr/local/etc/mpd5/down create link template L pptp set link action bundle B set link enable multilink set link yes acfcomp protocomp set link yes pap chap set link enable pap chap load radius set link keep-alive 15 45 set link mtu 1400 set pptp self х.х.х.х set link enable incoming peer-as-calling radius: set radius server х.х.х.х ctvmhfpjnvthm 1812 1813 set radius retries 10 set radius timeout 5 set radius me х.х.х.х set auth acct-update 60 set auth enable radius-auth set auth enable radius-acct set radius enable message-authentic sysctl.conf: net.inet.ip.fw.autoinc_step=100 net.inet.icmp.icmplim_output=0 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.drop_redirect=1 net.inet.icmp.maskrepl=0 net.inet.icmp.icmplim=10 net.inet.ip.fw.one_pass=1 dev.igb.0.rx_processing_limit=4096 dev.igb.1.rx_processing_limit=4096 net.route.netisr_maxqlen=4096 kern.ipc.nmbclusters=400000 kern.ipc.maxsockbuf=83886080 net.inet.ip.dummynet.pipe_slot_limit=2000 net.inet.ip.dummynet.io_fast=1 net.inet.ip.fastforwarding=1 net.inet.ip.intr_queue_maxlen=10240 net.graph.mppe.block_on_max_rekey=0 net.graph.mppe.log_max_rekey=1 net.graph.mppe.max_rekey=-1000 Сразу обратился к разрабам mpd, те сказали, что выход тока один это отключение шифрования, но что-то мне этот вариант не нравится. Собсно, вопрос, встречался кто с такой проблемой? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Butch3r Posted October 8, 2015 · Report post L2TP не пробовали? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
No_name Posted October 8, 2015 · Report post Нет. Опять же, это тогда всем объяснять чтобы изменяли настройки подключения. Тоже не оч вариант. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Butch3r Posted October 8, 2015 · Report post Нет. Опять же, это тогда всем объяснять чтобы изменяли настройки подключения. Тоже не оч вариант. я просто к тому, чтоб понять проблема в PPTP или в чём-то другом. Мы как раз в своё время всех перевели с PPTP на L2TP ибо на многих роутерах он показывал скорость выше, чем PPTP. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
No_name Posted October 8, 2015 (edited) · Report post Я понял. Надо подумать, потестить. Просто мы сейчас готовимся к переходу на ipoe и надо просто какое-то время продержаться. Но сам переход может затянуться, по разным причинам. А, ну и со скоростью проблем нет, прокачивается все по тарифу(вплоть до 95мбит) upd2 ну и опять же, запилил тестовый сервак на 8.4 и пробовал на нем прокачать торрентами, правда, в одно лицо, проблемы не возникало. Трафик шуршал и обрывов не было. Что-то мне кажется, что каких-то куртитлок на боевых серваках не хватает. Edited October 8, 2015 by Brainiac Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Ivan_83 Posted October 8, 2015 · Report post vmstat -z может мбуфы кончились. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
No_name Posted October 8, 2015 (edited) · Report post vmstat -z Так вроде ITEM SIZE LIMIT USED FREE REQUESTS FAILURES UMA Kegs: 208, 0, 89, 13, 89, 0 UMA Zones: 320, 0, 89, 7, 89, 0 UMA Slabs: 568, 0, 5301, 411, 152989973, 0 UMA RCntSlabs: 568, 0, 32876, 3, 32876, 0 UMA Hash: 256, 0, 1, 14, 3, 0 16 Bucket: 152, 0, 141, 9, 141, 0 32 Bucket: 280, 0, 153, 1, 157, 0 64 Bucket: 536, 0, 186, 3, 204, 57 128 Bucket: 1048, 0, 3140, 1, 13160, 3487 VM OBJECT: 216, 0, 54378, 1116, 46001573, 0 MAP: 232, 0, 7, 25, 7, 0 KMAP ENTRY: 120, 276737, 272, 906, 453788083, 0 MAP ENTRY: 120, 0, 1832, 1547, 251299577, 0 DP fakepg: 120, 0, 0, 0, 0, 0 SG fakepg: 120, 0, 0, 0, 0, 0 mt_zone: 2056, 0, 228, 75, 228, 0 16: 16, 0, 3028, 1172, 515703270, 0 32: 32, 0, 7227, 2671, 47915350148, 0 64: 64, 0, 6876, 3540, 109429189, 0 128: 128, 0, 34642, 192022, 126411583, 0 256: 256, 0, 18347, 28783, 76083319671, 0 512: 512, 0, 13291, 4678, 1527649395, 0 1024: 1024, 0, 2168, 676, 1219575, 0 2048: 2048, 0, 1374, 680, 63411, 0 4096: 4096, 0, 241, 176, 21000480, 0 Files: 80, 0, 1439, 1036, 53710142, 0 TURNSTILE: 136, 0, 1003, 97, 1003, 0 umtx pi: 96, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0 PROC: 1136, 0, 47, 115, 1335922, 0 THREAD: 1128, 0, 213, 789, 19601733, 0 SLEEPQUEUE: 80, 0, 1003, 128, 1003, 0 VMSPACE: 392, 0, 30, 170, 1335901, 0 cpuset: 72, 0, 64, 186, 81, 0 audit_record: 952, 0, 0, 0, 0, 0 mbuf_packet: 256, 0, 36079, 28945, 76962134245, 0 mbuf: 256, 0, 7, 2439, 121305777375, 0 mbuf_cluster: 2048, 400000, 65024, 598, 269682, 0 mbuf_jumbo_page: 4096, 12800, 0, 65, 547, 0 mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 840, 89847, 0 NetGraph items: 72, 4118, 362, 537, 48509500229, 0 NetGraph data items: 72, 522, 0, 522, 84404621908, 10032 ttyinq: 160, 0, 135, 177, 1230, 0 ttyoutq: 256, 0, 72, 108, 656, 0 ata_request: 320, 0, 0, 3012, 841293, 0 ata_composite: 336, 0, 0, 0, 0, 0 VNODE: 472, 0, 104249, 1279, 2199610, 0 VNODEPOLL: 112, 0, 0, 0, 0, 0 S VFS Cache: 108, 0, 84589, 28832, 2064274, 0 STS VFS Cache: 148, 0, 0, 0, 0, 0 L VFS Cache: 328, 0, 25345, 239, 251647, 0 LTS VFS Cache: 368, 0, 0, 0, 0, 0 NAMEI: 1024, 0, 0, 96, 38278321, 0 DIRHASH: 1024, 0, 1864, 24, 1866, 0 pipe: 728, 0, 5, 100, 977929, 0 ksiginfo: 112, 0, 153, 903, 31683, 0 itimer: 344, 0, 1, 21, 1, 0 KNOTE: 128, 0, 12, 336, 2326872, 0 socket: 680, 25602, 2710, 1406, 24927500, 0 unpcb: 240, 25600, 23, 169, 61561, 0 ipq: 56, 12537, 0, 693, 15244644, 0 udp_inpcb: 336, 25608, 11, 847, 20814243, 0 udpcb: 16, 25704, 11, 1165, 20814243, 0 tcp_inpcb: 336, 25608, 1356, 514, 1127484, 0 tcpcb: 944, 25600, 1339, 529, 1127484, 0 tcptw: 72, 5150, 17, 383, 63056, 0 syncache: 144, 15366, 0, 182, 1151868, 0 hostcache: 136, 15372, 158, 1186, 18228, 0 tcpreass: 40, 25032, 0, 420, 2085, 0 sackhole: 32, 0, 0, 808, 5749, 0 sctp_ep: 1312, 25602, 0, 0, 0, 0 sctp_asoc: 2280, 40000, 0, 0, 0, 0 sctp_laddr: 48, 80064, 0, 792, 65384, 0 sctp_raddr: 688, 80000, 0, 0, 0, 0 sctp_chunk: 136, 400008, 0, 0, 0, 0 sctp_readq: 104, 400032, 0, 0, 0, 0 sctp_stream_msg_out: 104, 400032, 0, 0, 0, 0 sctp_asconf: 40, 400008, 0, 0, 0, 0 sctp_asconf_ack: 48, 400032, 0, 0, 0, 0 ripcb: 336, 25608, 1328, 806, 1011784, 0 rtentry: 200, 0, 2664, 1003, 148285, 0 IPFW dynamic rule: 120, 0, 0, 0, 0, 0 selfd: 56, 0, 2318, 1147, 205513798164, 0 SWAPMETA: 288, 116519, 0, 0, 0, 0 Mountpoints: 752, 0, 5, 10, 5, 0 FFS inode: 168, 0, 104219, 1161, 2199444, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 104219, 1351, 2199444, 0 Edited October 8, 2015 by Brainiac Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Ivan_83 Posted October 8, 2015 · Report post NetGraph data items: 72, 522, 0, 522, 84404621908, 10032 В loader.conf net.graph.maxalloc="65535" # Maximum number of non-data queue items to allocate / limit the damage of a leak net.graph.maxdata="65535" # Maximum number of data queue items to allocate / limit the damage of a DoS только циферки по больше. Хотя это и так больше чем 522. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
No_name Posted October 9, 2015 · Report post Сделал, еще некоторые вещи сделал по совету dadv - бесполезно, та же картина. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Butch3r Posted October 9, 2015 · Report post http://forum.nag.ru/forum/index.php?showforum=4 вот тут продублируйте. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...