BRAS (NAS) 5k+ PPPoE

[lemosh]

12 минут назад, l1ght сказал:

никогда не понимал кому и главное зачем это нужно

Чтобы статические реальники продавать

На самом деле просто вопрос больше теоретический, как оно такое вообще реализуется. Можно даже не менять раз в сутки, сделать например так: абонент поднимает РРРоЕ, получает статический серый ИП от билинга, начинает пользоваться интернетом-получает какой-то белый адрес за НАТом и он к нему привязан пока есть какая-то активность абонента. Например час нет никакой активности и этот же абонент начинает снова серфить, но уже хочется чтобы под другим белым адресом. 

 

И ещё: а какой лучше дистрибутив Linux использовать для NAS? Нужно PPPoE server + NAT + OSPF (Quagga??)

 

[911]

В линуксе дистрибутив не настолько важен, ведь на него можно установить любое ядро.

Если предпочтений нет особых, можете Debian поставить, под него нормально собирается accel-ppp, без ньюансов

[KaYot]

10 часов назад, lemosh сказал:

 

а внешний адрес выдается в зависимости от адреса источника (клиента) или назначения?

Задача менять внешний IP клиенту за НАТом хотя бы раз в сутки

Белый IP есть функция от IP клиента, единственный вариант - менять клиенту серый IP.

[Kiano]

а accel нормально работает с таким количеством ПППоЕ сессий?

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

возможно, это вызвано самим pppoe сервисом и не оптимизированной ОС, но всё же: accel нормально будет работать с таким кол-вом сессий?

[zulu_Radist]

да нормально

[lemosh]

27 минут назад, 911 сказал:

В линуксе дистрибутив не настолько важен, ведь на него можно установить любое ядро.

Если предпочтений нет особых, можете Debian поставить, под него нормально собирается accel-ppp, без ньюансов

 

На разных ресурсах говорят про разные версии ядра под NAS. на НАГе пишут что 3.16 оптимальное. Ubuntu 16.04 LTS сейчас идет с 4.4 из коробки.... 

Ваше мнение какое лучше использовать? Сетевухи классика - 82576 или i340-T4.

А если NAS подымать виртуально? Есть сервер vSphere на котором подняты разные внутренние сервера, для эксперимента поднять виртуалку для NAS - чем это плохо? Как вариант сетевуху в виртуалку через directpacth i/o закинуть....

 

[KaYot]

Главное правило админа - не делать супер-коробку которая потянет все.

Поставьте 2 Линукс-тазика попроще, они отлично сбалансируются и обеспечат резерв. А под 2-3к сессий достаточно весьма простого железа, 1u сервера на e3-1220.

 

[pashaumka]

16 часов назад, KaYot сказал:

Багатство не порок

 

NAT в линуксе делается 1 строчкой в iptables, и сразу работает нормально без какой-либо настройки.

Для больших нагрузок нужен тюнинг sysctl в 5 строчек.

а можно эти 5 строчек? .)))

2 часа назад, Kiano сказал:

а accel нормально работает с таким количеством ПППоЕ сессий?

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

возможно, это вызвано самим pppoe сервисом и не оптимизированной ОС, но всё же: accel нормально будет работать с таким кол-вом сессий?

у аккеля кар в неделю обновление )  Дима старается

[supportod]

В 03.03.2018 в 15:28, pashaumka сказал:

Но перед сносом фряхи были куплены 2 дорогущих коммутатора хуавеи, 8 ядерный проц(16 с ГТ) с мамкой и сетевуха 10Г.

На фряхе 11-й был поднят брас. Без настроек максимум 0,8Г

Естественно. Ты ведь сам настраивал.

 

В 03.03.2018 в 15:28, pashaumka сказал:

Могу дать тазик и 10г сетевуху - приготовь + ospf(ibgp) + mpd5 + ipv6... и чтобы не падало...

И кто бы мне на шару настроит сервак под нагрузку...

 

16 часов назад, KaYot сказал:

net.netfilter.nf_conntrack_max = 524288 net.netfilter.nf_conntrack_buckets = 131072 net.netfilter.nf_conntrack_tcp_timeout_established = 600 net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 60 net.netfilter.nf_conntrack_tcp_timeout_time_wait = 20

Смешно.
А потом будут звонки, а почему у меня в игрушках соединение часто рвется?
Такие настройки, чтоб покупали белые IP?

[KaYot]

3 минуты назад, supportod сказал:

Смешно.
А потом будут звонки, а почему у меня в игрушках соединение часто рвется?
Такие настройки, чтоб покупали белые IP?

Смешно только бородатым bsd-админам.

Остальные понимают что это именно тайм-ауты для сессии, 10 минут достаточно с огромным запасом для любого трафика. Для тяжелонагруженных серверов вообще рекомендуется порядка 30 секунд ставить, и при таких настройках проблем не возникает.

 

[supportod]

Только что, KaYot сказал:

Остальные понимают что это именно тайм-ауты для сессии, 10 минут достаточно с огромным запасом для любого трафика. Для тяжелонагруженных серверов вообще рекомендуется порядка 30 секунд ставить, и при таких настройках проблем не возникает.

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

[KaYot]

3 минуты назад, supportod сказал:

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

Ты не компетентен.

Таймаут 600 секунд вовсе не значит что NAT-трансляция будет убиваться каждые 10 минут. Нет, спустя 10 минут после прекращения трафика по этой трансляции она будет убита.

Відредаговано 5 березня, 2018 KaYot

[ttttt]

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

[l1ght]

Только что, ttttt сказал:

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

пока ссш сессия чето вам возвращает - почему бы нат трансляции умирать?

[ttttt]

В нормальной реализации ната вопроса о таймаутах трансляций вообще не должно быть.

[l1ght]

Только что, ttttt сказал:

В нормальной реализации ната вопроса о таймаутах трансляций вообще не должно быть.

лол что?

предлогаете вечно хранить все трансляции неважно активные\не активные?

это ж бл@#ь стейтфул

[ttttt]

пока ссш сессия чето вам возвращает - почему бы нат трансляции умирать?

Пока ссш молчит пол часа, ни байтика не пересылает, там что-то выполняется на сервере.

[l1ght]

Только что, ttttt сказал:

Пока ссш молчит пол часа, ни байтика не пересылает, там что-то выполняется на сервере.

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

[ttttt]

предлогаете вечно хранить все трансляции

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

[ttttt]

Короче eat your own dog food, а то получается даже для ссш такой нат говно, а вы не знаете.

[KaYot]

Мы все-таки ведем разговор о домашнем интернете для ШПД. Тут сложности с ssh как-то не принципиальны.

Для молчаливой ssh-сессии будет печалька с отвалами. Но для этого достаточно в том же putty поставить галочку keep alive и забыть.

Другого варианта кроме ssh где нужно десятки минут слушать я не могу придумать.

[l1ght]

22 минуты назад, ttttt сказал:

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

потому что алгоритм поиска по трансляциям такой

повторяю что это стейтфул протокол

от кол-ва активных трансляций будут расходоваться ресурсы ЦПУ (представляете что это не только на линухе так нат работает?)

что б не искать в мертвых трансляциях и не тратить зазря такты ЦПУ просто уменьшают время жизни неактивных сессий

[pashaumka]

путти у меня базумно редко отваливается, как в офисе, так и дома....

[sanyadnepr]

27 минут назад, KaYot сказал:

Мы все-таки ведем разговор о домашнем интернете для ШПД. Тут сложности с ssh как-то не принципиальны.

Двойные стандарты, они такие...

Раз домашний, так можно и костылями подпереть. 

[ttttt]

то б не искать в мертвых трансляциях и не тратить зазря такты ЦПУ

Ой боже, не фантазируйте о тактах ЦПУ в линуксовом ядерном сетевом стеке, там вообще 90% проца расходуется впустую.