a_andry

не думаю что с этим будут какие-то проблемы, клиент выберет любойно и не думаю что таким образом удастся решить проблему балансировки надо всё-таки как-то через bond решать я так понимаю основной трафик - это трафик по направлению к клиенту, значит, наверно, надо bond на сервере крутить На всякий случай отпишу, вдруг кому пригодится. Странно, но изменение xmit_hash_policy на l2 для bond не помогло, остановились на варианте с дублированием вланов на двух сетевых, в pppoe-discovery видно два PADO c разными маками и одинаковыми AC-Name , багов за 3 дня не замечено, трафик с клиентами делится примерно поровну между обоими сетевыми. Спасибо.

Добрый день, используем у себя пару десятков пппое серверов, accel слушает кучу вланов на bond интерфейсах. Каждый bond собран их 2-х сетевых. Проблема в том, что со стороны свича идет перегрузка 1-го интерфейса входящим трафиком. К примеру на одном может быть под 1Гб/с, на втором 200-300Мбит/с. Со стороны свича проблему решить не удалось (используем brocade RX + SX), различные hash algorithm на aggregation при тестах на длинке тоже не помогли. Решили попробовать избавиться от bond-ов. К примеру, раньше было: [pppoe] interface=bond0.6 станет [pppoe] interface=eth0.6 interface=eth1.6 но есть сомнения, насколько я понимаю, при этом клиенту будут прилетать два PADO с одинаковым AC-Name. Согласно rfc AC-Name должен быть уникальным, поэтому не уверен в работоспособности. Как вариант, можно запустить несколько accel на одном сервере с разными AC-Name на разных сетевых, но как при этом будет вести себя ядро с именованием интерфейсов (ведь оба будут использовать ppp*), не будет ли конфликтов? Как поступить? Буду раз любым советам, заранее спасибо.

На 2-x win и 2-х linux разные версии vlc не захотели подключаться, ругается [0xb4400fb0] access_http access error: malformed header line: msd_lite/1.01 HTTP stream hub by Rozhuk Ivan после исправления src/stream_sys.c /* Base HTTP headers. */ if (0 != core_info_get_os_ver("/", 1, osver, (sizeof(osver) - 1), NULL)) memcpy(osver, "Generic OS/1.0", 15); shbskt->base_http_hdrs_size = snprintf((char*)shbskt->base_http_hdrs, sizeof(shbskt->base_http_hdrs), "HTTP/1.1 200 OK\r\n" "Server: %s\r\n" "Connection: close", app_ver); заработало

ospf, 20k маршрутов, за пару лет несколько серверов переставали принимать изменения, вылечилось рестартом quagga. В остальном порядок.

запустите радиус в дебаге с выводом в файл (что-то вроде raduisd -X > /tmp/test.log), с лога сможете взять пары, которые используют ваши насы. Сохраните нужные в файл, получится что-то вроде такого - ... Acct-Session-Id = "4863045-vlan1017-59" NAS-Port = 59 NAS-Port-Type = Ethernet Service-Type = Framed-User Framed-Protocol = PPP Calling-Station-Id = "001e8c9c199c" NAS-Port-Id = "vlan1017" ... дальше с консоли - radclient -f pairs_acc_update.txt -S shared_secret.txt -x 192.168.0.1 acct

cpu-flooding unknown-unicast вроде помогло. Будем дальше смотреть. пс. nashvill, спасибо за ответ. Смысл - показать что на порту есть лишний трафик. Для примера (но это уже после включения) 11:27:37.971128 00:1b:21:aa:e0:81 > 00:1f:16:43:e5:4a, ethertype 802.1Q (0x8100), length 66: vlan 183, p 0, ethertype PPPoE S, PPPoE [ses 0xac4] IP (0x0021), length 42: 131.216.192.152.443 > 172.16.183.121.51851: [|tcp] SSH@coreRX(config)#show mac-address 001f.1643.e54a Total active entries from all ports = 13908 Type Code-CCL:Cluster Client Local CCR:Cluster Client Remote CL:Local CR:Remote MAC Address Port Age VLAN Type 001f.1643.e54a 10/3 0 183 SSH@coreRX(config)#show mac-address eth 10/3 Total active entries from slot/port 10/3 = 605 Type Code-CCL:Cluster Client Local CCR:Cluster Client Remote CL:Local CR:Remote MAC Address Port Age VLAN Type 0003.0f15.af88 10/3 0 22 0018.e792.f189 10/3 155 22 3408.0436.4196 10/3 0 183 001d.600f.d76a 10/3 0 184 84c9.b257.277c 10/3 0 1211 001a.4d98.3ae1 10/3 0 183 0011.5b4e.5dd5 10/3 0 1211 14da.e979.c7f8 10/3 0 183 c8be.19b7.6c4a 10/3 0 183 6cf0.49b7.3cbd 10/3 0 170 001f.1fa1.e6c1 10/3 0 175 000f.ea64.22dc 10/3 0 170 b048.7aeb.b3eb 10/3 0 45 .... 10/3 - абонентский порт с кучей вланов

Добрый день! Есть очень простая схема сети - все разбито на ~200 вланов, все эти вланы доброшены до 14 пппое серверов. Долгое время использовали младшую модель в линейке - brocade SX в качестве свича. Все было ок, но начали подходить в лимиту в 16К мак адресов, свич превращался в хаб, получали перегрузку по портам. Пытались на нем включить flow based mac leaning + увеличение таблицы маков до 32К, но он почему-то так и не заработал нормально. В итоге решили заменить на brocade RX, у него заявлена поддержка таблицы в 65К маков. Заменили. Сразу же получили аналогичную картину. К примеру, включен один из пппое серверов, реально трафика на нем под 500Мбит/с, при снятии статистики с RX видим полку в гигабит. Вот один из вланов на пппое- pppoe4 ~ # ip addr ls dev eth0.44 496253: eth0.44@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 00:1b:21:45:d9:b8 brd ff:ff:ff:ff:ff:ff слушаем трафик, кот. не предназначен этому интерфейсу - pppoe4 ~ # tcpdump -c 10 -e -ni eth0 not ether host 00:1b:21:45:d9:b8 tcpdump: WARNING: eth0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 68 bytes 11:27:37.971128 00:1b:21:aa:e0:81 > 00:1f:16:43:e5:4a, ethertype 802.1Q (0x8100), length 66: vlan 183, p 0, ethertype PPPoE S, PPPoE [ses 0xac4] IP (0x0021), length 42: 131.216.192.152.443 > 172.16.183.121.51851: [|tcp] 11:27:37.971129 00:15:17:36:c5:d0 > f0:7d:68:48:fa:71, ethertype 802.1Q (0x8100), length 74: vlan 5, p 0, ethertype PPPoE S, PPPoE [ses 0x1578] IP (0x0021), length 50: 31.163.95.217.57944 > 46.149.83.2.1566: UDP, length 20 11:27:37.971479 00:15:17:8a:f3:68 > 00:0b:6a:a1:6a:1f, ethertype 802.1Q (0x8100), length 1479: vlan 40, p 0, ethertype PPPoE S, PPPoE [ses 0x848d] IP (0x0021), length 1455: 81.198.244.182.60057 > 172.16.80.90.36046: UDP, length 1425 11:27:37.971777 00:1b:21:9d:da:e8 > e8:03:9a:ae:6a:4b, ethertype 802.1Q (0x8100), length 74: vlan 8, p 0, ethertype PPPoE S, PPPoE [ses 0xc70] IP (0x0021), length 50: 94.153.241.114.50562 > 172.16.166.240.58007: UDP, length 20 11:27:37.971779 00:1b:21:aa:e0:81 > 00:1a:4d:dd:fd:cb, ethertype 802.1Q (0x8100), length 1506: vlan 34, p 0, ethertype PPPoE S, PPPoE [ses 0xb02b] IP (0x0021), length 1482: 87.240.172.213.80 > 172.16.78.205.1080: [|tcp] 11:27:37.971780 00:1b:21:ae:78:c0 > 00:1e:58:c5:58:92, ethertype 802.1Q (0x8100), length 161: vlan 47, p 0, ethertype PPPoE S, PPPoE [ses 0xce22] IP (0x0021), length 137: 84.15.178.112.37784 > 172.16.142.117.43541: UDP, length 107 11:27:37.971783 00:15:17:8a:f3:68 > 00:0b:6a:a1:6a:1f, ethertype 802.1Q (0x8100), length 1479: vlan 40, p 0, ethertype PPPoE S, PPPoE [ses 0x848d] IP (0x0021), length 1455: 176.8.202.114.57854 > 172.16.80.90.36046: UDP, length 1425 11:27:37.971785 00:15:17:36:c5:d0 > 64:70:02:56:60:97, ethertype 802.1Q (0x8100), length 1476: vlan 98, p 0, ethertype PPPoE S, PPPoE [ses 0x10f] IP (0x0021), length 1452: 94.100.190.95.443 > 172.16.141.105.52080: [|tcp] 11:27:37.971786 00:15:17:36:c5:d0 > 64:70:02:56:60:97, ethertype 802.1Q (0x8100), length 221: vlan 98, p 0, ethertype PPPoE S, PPPoE [ses 0x10f] IP (0x0021), length 197: 94.100.190.95.443 > 172.16.141.105.52080: [|tcp] 11:27:37.971787 00:1b:21:4d:11:08 > 00:24:8c:59:5b:07, ethertype 802.1Q (0x8100), length 134: vlan 15, p 0, ethertype PPPoE S, PPPoE [ses 0xde3] IP (0x0021), length 110: 172.16.125.128.41378 > 172.16.64.231.13751: UDP, length 80 10 packets captured 128 packets received by filter 0 packets dropped by kernel этот трафик реально предназначается другим серверам в соседних портах. Т.е. опять же, очень похоже что свич становится хабом, есть какие-то проблемы с изучением новых мак адресов или еще что-то ... это все начинается уже при 14к изученных маках. в это время на этом же порту RX: SSH@coreRX#show mac-address ethernet 2/4 Total active entries from slot/port 2/4 = 98 Type Code-CCL:Cluster Client Local CCR:Cluster Client Remote CL:Local CR:Remote MAC Address Port Age VLAN Type 001b.2145.d9b8 2/4 0 34 001b.2145.d9b8 2/4 0 193 001b.2145.d9b8 2/4 270 1016 001b.2145.d9b8 2/4 0 181 001b.2145.d9b8 2/4 0 197 001b.2145.d9b8 2/4 0 106 001b.2145.d9b8 2/4 0 227 001b.2145.d9b8 2/4 0 30 001b.2145.d9b8 2/4 0 104 ... присутствует только 1 правильный мак. Может кто-то сталкивался с аналогичной ситуацией, может есть какие-то идеи? Заранее спасибо! пс. запрос на brocade через продавцов отправили, но ответ от них идет очень долго (

при mschap1-2 выдавайте с радиуса MS-CHAP-Error = "E=50 R=0 V=3" , accel передаст это на винду и она отобразит это как стандартную виндовую ошибку, самое приятное, что можно указывать любой код ошибки, а не только относящиеся с тунелям. xeb просто немного забыл :)

К примеру качаем 1Гб файл, SNMP - счетчик, будет крутить постоянно, а по netflow отправится информация только после полной закачки (примерно, еще таймауты можно накрутить, но общий смысл останется). В итоге в один период просмотра у вас то там, то там будет то больше то меньше. Выберете статистику за больший период, проценты должны быть поменьше.

vinnipux, спасибо, радует что я не один, и есть шанс что Xeb обратит внимание ;) Есть еще интересная особенность по libcrypto.so, у меня 5 "обновленных" сервера до 3.2.1-gentoo-r2, я ОС на них не ставил, вернее, ставил только на 1 тестовом, а потом через dd копировал его на рабочие сервера, изменения минимальные - ip адрес, имя сервера и т.п.. В итоге на 4-ех все работает отлично, без падений уже с пол месяца. А на одном постоянные падения на всех версиях accel-ppp. Сервера почти одинаковые - Core Duo c E7400 и выше, тот что падает - самый слабый E7400. Железо - БП, память - меняли, не помогло. Раньше на этом сервере стояла freebsd+mpd - работало стабильно, т.е. с железками вроде как должно быть все в порядке. Нагрузка - 50% idle, по 1200 тунелей, больше не пускаем, трафика 800-900Мбит/с. Но падает рандомно, вне зависимости от нагрузки.

accel-ppp version ccfc36744c585a4ea4fb5d5c4e183e9bbd293852 сегфолтится примерно через пол дня работы. pppoe8 ~ # uname -r 3.2.1-gentoo-r2 Ставил с дебагом (USE="debug" emerge -av1 accel-ppp), работают pppoe+pptp [2012-02-22 14:42:58]: info: ppp9: send [LCP ConfReq id=1 <auth MSCHAP-v2> <magic 6ef9a131> <mru 1492>] [2012-02-22 14:42:58]: info: recv [PPPoE PADI fc:75:16:42:7f:bf => ff:ff:ff:ff:ff:ff sid=0000 <Service-Name > <Host-Uniq 19030000>] [2012-02-22 14:42:58]: info: send [PPPoE PADO 00:15:17:67:47:76 => fc:75:16:42:7f:bf sid=0000 <AC-Name pppoe8> <Service-Name > <AC-Cookie e99112396478df4ee27b82cef635df2227f2de5b6786a572> <Host-Uniq 19030000>] [2012-02-22 14:42:58]: info: ppp225: send [RADIUS(1) Accounting-Request id=21 <User-Name "home25213"> <NAS-Identifier "193.XXX.ZZZ.249"> <NAS-IP-Address 193.XXX.ZZZ.249> <NAS-Port 225> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "00:16:17:dd:21:d7"> <Called-Station-Id "00:15:17:67:47:76"> <Acct-Status-Type Alive> <Acct-Authentic RADIUS> <Acct-Session-Id "0040de0f53556704"> <Acct-Session-Time 9600> <Acct-Input-Octets 61638871> <Acct-Output-Octets 118108473> <Acct-Input-Packets 736834> <Acct-Output-Packets 838809> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Framed-IP-Address 172.16.21.246>] [2012-02-22 14:42:58]: info: ppp225: recv [RADIUS(1) Accounting-Response id=21] [2012-02-22 14:42:58]: info: recv [PPPoE PADI 00:24:01:02:8a:d8 => ff:ff:ff:ff:ff:ff sid=0000 <Service-Name > <Host-Uniq 0100000001000000>] [2012-02-22 14:42:58]: info: send [PPPoE PADO 00:15:17:67:47:76 => 00:24:01:02:8a:d8 sid=0000 <AC-Name pppoe8> <Service-Name > <AC-Cookie e22d8e284f7147561d035987177dd14812a12f43ce1b5560> <Host-Uniq 0100000001000000>] [Thread 0x7ffff0ad6700 (LWP 4210) exited] [Thread 0x7ffff7ff6700 (LWP 4289) exited] [New Thread 0x7ffff7ff6700 (LWP 4294)] [Thread 0x7ffff7ff6700 (LWP 4294) exited] [New Thread 0x7ffff7ff6700 (LWP 4295)] [Thread 0x7ffff7ff6700 (LWP 4295) exited] [New Thread 0x7ffff7ff6700 (LWP 4315)] [New Thread 0x7ffff0ad6700 (LWP 4317)] [Thread 0x7ffff7e46700 (LWP 4287) exited] [New Thread 0x7ffff7e46700 (LWP 4318)] [Thread 0x7ffff0ad6700 (LWP 4317) exited] [New Thread 0x7ffff1b5c700 (LWP 4321)] [Thread 0x7ffff7e25700 (LWP 4291) exited] RTNETLINK answers: No such file or directory [New Thread 0x7ffff7e25700 (LWP 4348)] [Thread 0x7ffff7e25700 (LWP 4348) exited] [New Thread 0x7ffff7e25700 (LWP 4351)] [Thread 0x7ffff1b5c700 (LWP 4321) exited] [Thread 0x7ffff7ff6700 (LWP 4315) exited] [New Thread 0x7ffff7ff6700 (LWP 4352)] [Thread 0x7ffff7ff6700 (LWP 4352) exited] [New Thread 0x7ffff7ff6700 (LWP 4354)] Program received signal SIGSEGV, Segmentation fault. [switching to Thread 0x7ffff0a73700 (LWP 4199)] 0x00007ffff6691afb in sha1_block_data_order () from /usr/lib64/libcrypto.so.1.0.0 (gdb) bt #0 0x00007ffff6691afb in sha1_block_data_order () from /usr/lib64/libcrypto.so.1.0.0 #1 0x0000000000000000 in ?? ()

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

отправил

Гммм, не дочитал. А зачем вообще "назад"? На сервере с редиректом через rewrite заворачиваем все на свой index.чего-то-там . В индексе запоминаем оригинальный запрос пользователя в hidden форму. На нажатие кнопки "продолжить" ставим что-то вроде <script type=\"text/javascript\"> setTimeout( document.location = '$fulluri' , 500); </script> - сразу редирект по ранее запрашиваемому адресу с нужными параметрами запроса. Для GET работает на ура со всеми броузерами. Для POST не делал, просто лениво, но тоже должно работать. Отдельный демон считает таймауты показа для каждого должника страницы и добавляет адреса в ipset - нагрузка "размазана" по времени, нету редиректа одновременно сотен абонентов (можно и через таймауты в самом ipset + cron). Один раз эта радость поломалась, народ некоторый даже жаловаться по телефону начал - не предупредили мы их, понимаешь, о задолженности :)

Помнит броузер пользователя. На странице с редиректом добавьте в заголовки connection: close . Я еще на всякий случай добавлял запреты для кеширования страницы.

+1 NiTr0 И в добавок огромная гибкость настройки.

LLIPort=80 уберите. Толку особо нет, но по прерываниям может просесть есть флуд какой пойдет.

Есть два нат сервера и бордер, между ними ospf. Маршрут на блок адресов /20 прописан статиком на бордере через один из натов - # show ip route X.149.80.0/20 Routing entry for X.149.80.0/20 Known via "static", distance 1, metric 0, best * Y.151.104.2, via bond1.52 С натов через ospf анонсируются more specific роуты на бордер - # show ip route X.149.83.73 Routing entry for X.149.83.73/32 Known via "ospf", distance 110, metric 20, best Last update 00:28:40 ago Y.151.104.2, via bond1.52 Y.151.105.2, via bond1.52 проблема в том что /32 не попадает в fib, по идее он должен быть предпочтительней всех остальных. Не подскажете в какую сторону смотреть? Если выключить ospfd на одном из натов, картина становится нормальной - # show ip route X.149.83.73 Routing entry for X.149.83.73/32 Known via "ospf", distance 110, metric 20, best Last update 00:00:03 ago * Y.151.104.2, via bond1.52 роут попал в fib и это вводит еще в большее замешательство ...

Посмотрите за работой радиса в дебаге(radiusd -ХХХ), с такой задержкой, наверно, даже на глаз будет видно в чем затык. Повыключайте все лишние/неиспользуемые модули.

У меня rlm_perl. Давайте, я открою свой радиус наружу, дам Вам несколько логинов/паролей для проверок. Будете получать что-то в этом роде -- [root@pppoe1 ~/radius]# ./test_auth.sh Sending Access-Request of id 14 to 172.16.1.22 port 1812 ... rad_recv: Access-Reject packet from host 172.16.1.22 port 1812, id=14, length=120 MS-CHAP-Error = "E=1315 R=0 V=3" Reply-Message = "invalid login: [sfdsdf] ip=[unknown] CLIENT_ENDPOINT=[00:90:05:87:02:03]" После передачи MS-CHAP-Error винде (Reply-Message просто для удобства отладки радиуса) через бсдшный mpd, высвечивает стандартную виндовую ошибку 1315 ERROR_INVALID_ACCOUNT_NAME (The name provided is not a properly formed account name) Пойдет? Только с Вас нужен ip с которого стучаться на радиус будете, или в лс или на почту (отправил Вам свою в личку) ...

e63e5ac245edcbf43902dd1d248e15231c6c9191 и 05ad71a30740f1cca95e9f47a8a56c65b03402ed не реагируют (все равно создают соединение) на ненулевой возврат из ip-pre-up. ок

Можно напомнить? ок

Cache-control и Expires это не все. Обязательно нужно Connection: close. Полностью у меня заголовки выглядят так -- print "Content-Type: text/html; charset=koi8-r\nExpires: Wed, 1 Oct 2000 00:00:00 GMT\nLast-modified: @{[scalar gmtime() . \" GMT\"]} Cache-Control: no-cache, must-revalidate\nCache-Control: post-check=0, pre-check=0\nCache-Control: max-age=0\nPragma: no-cache\nConnection: close\r\n\r\n"; пс. каждые пол часа должникам выдается редирект на страницу "не забудь заплатить", на странице после нажатия кнопки "не забуду" редирект на нужный урл. Обычно, после 2-3 дней редиректов мало кто уже повторно хочет залазить в долг :)

Спасибо. Имхо, все же это это лишнее. Сильно усложняется конфигурация. Когда 2-3 сервера, еще терпимо, а когда их с десяток, то будет совсем тяжко. Расписывать резервирование придется так, что-бы нагрузка более и менее равномерно размазалась по оставшимся живым серверам. Если к этому добавить глюки с ПО (у меня linux с vrrp, там свои приколы, периодически два instance на нескольких серверах мастерами поднимаются одновременно), то ну его ... Сервера и так подать не должны, но если раз в пятилетку упадет - два дисконекта не сильно большая проблема.

Если использовать реальные адреса, то с pfsync ну или линуксовым conntrackd соединения рваться не будут, это понятно. Но почему соединения не порвет если использовать еще и нат? Ведь сервера будут натить на разные блоки адресов и при падении одного из них, клиент автоматически попадет на другой и, соответственно, получит на нате другой адрес, так? Или есть способ заставить все сервера использовать для ната общий блок адресов, не поясните?