Jump to content
Калькуляторы

1. надо не в [radius], а в [ipoe]

2. выданный ип (172.16.55.89), не попадает в заданную сеть (172.16.37.1/24)

 

Share this post


Link to post
Share on other sites
1. надо не в [radius], а в [ipoe]2. выданный ип (172.16.55.89), не попадает в заданную сеть (172.16.37.1/24)

Каюсь, иду проверять.

Share this post


Link to post
Share on other sites

ВОПРОС РЕШИЛСЯ

 

 

Подскажите, как завернуть траффик на порт 8081 контентного фильтра 10.10.10.4 подсети 172.20.10.0/24

 

iptables

 

-A PREROUTING -s 172.20.10.0/24 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.10.10.4:8081
-A PREROUTING -d ip/32 -p tcp -m set --match-set l4redirect src -j ACCEPT
-A PREROUTING -d ip/32 -p tcp -m set --match-set l4redirect src -j ACCEPT
-A PREROUTING -p tcp -m set --match-set l4redirect src -j REDIRECT --to-ports 8001
-A POSTROUTING -s 172.20.0.0/16 -o eth1 -j SNAT --to-source IP
-A POSTROUTING -s 10.10.0.0/16 -o eth1 -j SNAT --to-source IP
-A POSTROUTING -s 192.168.0.0/16 -o eth1 -j SNAT --to-source IP

 

CFG accel-ppp

 


[ipoe]
nat=1
verbose=1
#username=ifname
#password=username
lease-time=600
max-lease-time=3600
#unit-cache=1000
#l4-redirect-table=4
l4-redirect-ipset=l4redirect
l4-redirect-on-reject=300
shared=1
ifcfg=1
mode=L2
start=up
#relay=10.10.10.10
#attr-dhcp-client-ip=DHCP-Client-IP-Address
#attr-dhcp-router-ip=DHCP-Router-IP-Address
#attr-dhcp-mask=DHCP-Mask
#attr-l4-redirect=L4-Redirect
local-net=10.10.11.0/24
local-net=172.20.0.0/16
#lua-file=/etc/accel-ppp.lua
interface=eth3

 

Сильно не пинайте :)

Edited by doryk

Share this post


Link to post
Share on other sites
1. надо не в [radius], а в [ipoe]2. выданный ип (172.16.55.89), не попадает в заданную сеть (172.16.37.1/24)

Спасибо, все работает!

Скажите, а можно задать несколько gw-ip-address для отдельного интерфейса?

Share this post


Link to post
Share on other sites
Подскажите, как завернуть траффик на порт 8081 контентного фильтра 10.10.10.4 подсети 172.20.10.0/24
ну вроде бы всё так

 

Скажите, а можно задать несколько gw-ip-address для отдельного интерфейса?
можно указывать сколько угодно разных gw-ip-address

Share this post


Link to post
Share on other sites

Уважаемый xeb, скажите будет ли работать, если вместо имени интерфейса типа eth0 указать vlan0010?

Т.е.:

[pppoe]

interface=vlan0010

 

Естественно, в системе интерфейс vlan0010 присутствует.

Share this post


Link to post
Share on other sites

Уважаемый xeb, скажите будет ли работать, если вместо имени интерфейса типа eth0 указать vlan0010?

Т.е.:

[pppoe]

interface=vlan0010

 

Естественно, в системе интерфейс vlan0010 присутствует.

А почему он должен не работать то?

Share this post


Link to post
Share on other sites

Ребят а возможно ли реализовать балансировку при помощи 2,3,4,5 и тд серверов accel ? что бы клиенты динамически подключались рандомно по серверам дабы обеспечить балансировку нагрузку и отказоусточивость ?

 

В качестве "железа" виртуализаия на базе ESXI , accel в режиме ipoe работает под управлением mikbill

Edited by CartMan_1488

Share this post


Link to post
Share on other sites

В режиме L2 - да, можно. Нужно чтобы RADIUS выдавал разные IP gateway-я.

Только сунуть роутер в виртуалку - неразумно.

Share this post


Link to post
Share on other sites
В режиме L2 - да, можно. Нужно чтобы RADIUS выдавал разные IP gateway-я.
либо на каждом сервере свой gw-ip-address

 

для равномерной загрузки можно использовать offer-delay

Share this post


Link to post
Share on other sites

можно услышать аргументы ?

В режиме L2 - да, можно. Нужно чтобы RADIUS выдавал разные IP gateway-я.

 

тоесть этим посути рулит радиус , сколько при этом серверов не имеет значения ?

 

Только сунуть роутер в виртуалку - неразумно.

 

можно услышать аргументы ?

 

либо на каждом сервере свой gw-ip-address

 

но это тогда получиться статика , без отказоустойчивости , тоесть задумка то в том что бы пока есть более 2х серверов абоны пилились по очереди между серверами а если вдруг "случилось говно" что бы вся нагрузка легла на последний оставшийся сервер в строю.

Share this post


Link to post
Share on other sites

либо на каждом сервере свой gw-ip-address

 

но это тогда получиться статика , без отказоустойчивости , тоесть задумка то в том что бы пока есть более 2х серверов абоны пилились по очереди между серверами а если вдруг "случилось говно" что бы вся нагрузка легла на последний оставшийся сервер в строю.

надеюсь ты не думаешь все серверы будут с одинаковыми собственными адресами, так работать не будет

тебе так или иначе придётся выдавать разные адреса серверам

если выдавать радиусом, то его надо настроить так, чтобы он выдавал адрес сервера в зависимости от NAS-Identifier/NAS-IP-Address

если радиус так не умеет, то нужно gw-ip-address указывать статически на каждом сервере

 

отказоустойчивость не будет бесперебойной

если один сервер откажет, то клиенты не смогут продлить лизу и будут искать другие серверы

естественно на какое-то время (пока не получит адрес у другого сервера) интернет работать не будет

Share this post


Link to post
Share on other sites

Каждый сервер в сторону шлюза и сторону биллинга разумеется будет иметь уникальный адрес , а в сторону клиента адрес не требуется , на сервере тупо терминируются абонентские виланы и при создании абонентского тунеля на конец тунеля вешается адрес , по задумке именно этот адрес будет у всех абонентов общий.. ну собвенно сейчас так и есть в рамках одного сервера , при падении сервера , разумеется клиенту отдаляться , и пока не переполучат адрес связи у них не будет ....

 

тут весь вопрос то в том как заставить клиентов обратиться именно на рандомный сервер , и как заставить радиус авторизовывать запросы последовательно на серверах и так , что бы они не перетасовывались при переполнении лизы

Share this post


Link to post
Share on other sites

я только не понял речь идёт о пппое или ипое

Share this post


Link to post
Share on other sites

слово тунель смутило...

ещё раз повторюсь, если несколько серверов в одном влане, то общий адрес сделать не получится, т.к. на арп каждый сервер будет отвечать своим маком, в итоге у клиента ничего работать не будет

насчёт рандомности ... какой в этом великий смысл ?

я так понимаю всё таки интересует равномерная загрузка серверов, я уже писал выше, для этого нужно задействовать offer-delay

смысл в том что задаются задержки на ответ DHCPDISCOVER в зависимости от кол-ва сессий

т.е. на запрос DHCPDISCOVER первым ответит тот сервер, на котором меньше всего сессий, таким образом серверы загружаются примерно равномерно

при продлении лизы клиент продлевает её у того-же сервера, так что никаких скачек по серверам не может быть, если только сервер перестал отвечать по каким-то причинам

Share this post


Link to post
Share on other sites

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

 

если на 2х серверах на концах абонентских туннелей будут разные адреса то это противоречит всей идеи , так как в карточке абонента в биллинга выбирается сегмент , к которому привязан определенный нас , с определенным пулом адресов и так далее.

Share this post


Link to post
Share on other sites

CartMan_1488, ваш друг динамическая маршрутизация. IBGP или OSPF крутите, и будет вам счастье. Речь шла о GW ip адресе.

Edited by Dimka88

Share this post


Link to post
Share on other sites

Денб добрый XEB

[2014-11-10 10:35:53]: msg: accel-ppp version b276238f8721849c364cf718f854c7b07a706254

[2014-11-10 10:35:53]: error: pppoe: ioctl(SIOCGIFHWADDR): No such device

[2014-11-10 10:35:53]: error: pppoe: ioctl(SIOCGIFHWADDR): No such device

 

а можно дли дописать, что No such device - vlan XXX not found( exists ) - ну чуток попонятнее

 

и no such file or directory - а то что именно имелось ввиду - нИпонятно

Share this post


Link to post
Share on other sites

ещё

[ 5319.366378] HTB: quantum of class 10001 is big. Consider r2q change.

[ 5319.366436] HTB: quantum of class 1003D is big. Consider r2q change.

[ 5448.359861] HTB: quantum of class 10001 is big. Consider r2q change.

[ 5467.483470] HTB: quantum of class 10001 is big. Consider r2q change.

[ 5467.483529] HTB: quantum of class 10040 is big. Consider r2q change.

 

[shaper]
attr-down=PPPD-Downstream-Speed-Limit
attr-up=PPPD-Upstream-Speed-Limit
ifb=ifb0
up-limiter=htb
down-limiter=htb
cburst=1375000
r2q=10
quantum=1500
verbose=1   

Share this post


Link to post
Share on other sites

xeb,

Когда-то, помню, была проблема с pppd_compat на ipoe. В git-е работает нормально?

Share this post


Link to post
Share on other sites

два варианта решения:

1. отрегулировать r2q, так чтобы quantum = rate/r2q было более 1000 и менее 200000 на всех возможных тарифных скоростях (rate в байтах в секунду)

2. указать фиксированный quantum

 

п.с. фиксированный quantum вижу в конфиге указан, значит в проге жук...

 

Когда-то, помню, была проблема с pppd_compat на ipoe. В git-е работает нормально?
что именно ? я уже не помню...

Share this post


Link to post
Share on other sites

Когда-то, помню, была проблема с pppd_compat на ipoe. В git-е работает нормально?

Не про зомби ip-up/ip-down речь идёт часом? Если да, то могу посмотреть на стенде, но вроде там все отлично срабатывает.

Share this post


Link to post
Share on other sites

проблема с зомби уже давно решена

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now