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 . Я еще на всякий случай добавлял запреты для кеширования страницы.