[mousus]

есть n PPPoE брасов построенных на FreeBSD и mpd пользователи получают серые IP адреса и прямо на этих же брасах через нат получают интернет, есть возможность выделить пул белых адресов на каждый брас например сетку из 32 адресов, возникает вопрос каким из встроеных фаерволов и фильтров разумнее реализовать нат на пул адресов --- сейчас используется ipfw + natd которая может натить только на 1 адрес и фактом того что natd выполняется в user space создаёт лишнюю нагрузку. есть возможность вынести нат на отдельный сервер и поднять ospf между кластером брасов и этим сервером, хотелось бы узнать насколько такое оправдано? ведь тогда появляется единая точка отказа, либо поставить кваггу на каждый брас и подружить её с бордером на циске

Edited November 26, 2009 by mousus

[[GP]Villi]

никто не мешает NAT зарезервировать. pf или ipfw на выбор. предпочтительно наверное второе, с точки зрения того что первое не параллелится.

[jab]

 

natd может натить на сколько угодно адресов, изучайте матчасть... на каждый адрес запускаете по natd на разных номерах портов.

 

никто не мешает NAT зарезервировать. pf или ipfw на выбор. предпочтительно наверное второе, с точки зрения того что первое не параллелится.

Первый не параллелится, а во втором утечки... :-) Нет в жизни счастья.

[[GP]Villi]

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

[photon]

А почему бы тогда заинтересованному кругу лиц не скинуться и не оплатить доработку ipfw kernel nat, чтобы всем было счастье? Про pf не говорю, там у разработчиков твердые убеждения, что SMP "не нужен". Кроме того, в связи с появлением во FreeBSD 8.0 виртуализации сетевого стека, проблему масштабирования pf теоретически можно решить, запуская pf в нескольких jail, прибитых к отдельным процессорам/ядрам, и настроив CARP в режиме балансировки нагрузки. Сам так делать еще не пробовал, поэтому за работоспособность этой схемы не ручаюсь.

 

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

Edited November 27, 2009 by photon

[mousus]

вылез кстати очень интересный глюк при использовании pf в качестве штуковины делающей nat на пул адресов: в сети сразу появилось куча широковещательного arp трафика от брасов в котором снифером были увидены постоянные попытки брасов найти несуществующие адреса из пулов. Кто как кстати выкручивается в такой ситуации? можно все эти адреса приколотить к какому нибудь интерфейсу -- по идее можно к внешнему интерфейсу браса, но тут сразу взрастёт нагрузка на постоянно дёргаемый драйвер сетевухи, есть идея привернуть эти адреса к lo0 по типу :

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3<RXCSUM,TXCSUM>
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
        inet6 ::1 prefixlen 128
        inet 127.0.0.1 netmask 0xff000000
        inet xxx.xxx.xxx.1 netmask 0xffffff00
        inet xxx.xxx.xxx.2 netmask 0xffffff00
        inet xxx.xxx.xxx.3 netmask 0xffffff00

тогда возникает вопрос насколько это будет корректно ?

[jab]

 

маску только /32 поставьте, а не /24

 

собственно так в рекомендациях и написано делать...

 

 

PS: разницы по нагрузке с внешним интерфейсом нет...

[littlesavage]

А почему бы тогда заинтересованному кругу лиц не скинуться и не оплатить доработку ipfw kernel nat, чтобы всем было счастье?

А что там дорабатывать? Вроде не течет он уже. А если и течет, то не так существенно.

По крайней мере, его уже не надо перезапускать раз в месяц.

[XeonVs]

вылез кстати очень интересный глюк при использовании pf в качестве штуковины делающей nat на пул адресов: в сети сразу появилось куча широковещательного arp трафика от брасов в котором снифером были увидены постоянные попытки брасов найти несуществующие адреса из пулов. Кто как кстати выкручивается в такой ситуации? можно все эти адреса приколотить к какому нибудь интерфейсу -- по идее можно к внешнему интерфейсу браса, но тут сразу взрастёт нагрузка на постоянно дёргаемый драйвер сетевухи, есть идея привернуть эти адреса к lo0 по типу :

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3<RXCSUM,TXCSUM>
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
        inet6 ::1 prefixlen 128
        inet 127.0.0.1 netmask 0xff000000
        inet xxx.xxx.xxx.1 netmask 0xffffff00
        inet xxx.xxx.xxx.2 netmask 0xffffff00
        inet xxx.xxx.xxx.3 netmask 0xffffff00

тогда возникает вопрос насколько это будет корректно ?

у меня тоже на lo0, но с маской /32, а также эти адреса проанонсированы во внутрь AS, торентщики довольны.

На какой интерфейс вешать не суть важно.

[mousus]

есть кстати 2 варианта как с помощью pf раскидывать юзерей по пулу:

 

nat on em0 inet from 172.16.0.0/16 to any -> x3.x4.x5.x6/27 round-robin sticky-address

 

и

 

nat on em0 inet from 172.16.0.0/16 to any -> x3.x4.x5.x6/27 source-hash

 

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

[XeonVs]

Хеш вычисляется один раз при создании правила трансляции.

                break;
        case PF_POOL_SRCHASH:
                pf_hash(saddr, (struct pf_addr *)&hash, &rpool->key, af);
                PF_POOLMASK(naddr, raddr, rmask, (struct pf_addr *)&hash, af);
                break;
        case PF_POOL_ROUNDROBIN:
                if (rpool->cur->addr.type == PF_ADDR_TABLE) {
                        if (!pfr_pool_get(rpool->cur->addr.p.tbl,
                            &rpool->tblidx, &rpool->counter,
                            &raddr, &rmask, af))
                                goto get_addr;
                } else if (rpool->cur->addr.type == PF_ADDR_DYNIFTL) {
                        if (!pfr_pool_get(rpool->cur->addr.p.dyn->pfid_kt,
                            &rpool->tblidx, &rpool->counter,
                            &raddr, &rmask, af))
                                goto get_addr;
                } else if (pf_match_addr(0, raddr, rmask, &rpool->counter, af))
                        goto get_addr;

 

было бы интересно потестировать разные варианты.

[kapa]

есть кстати 2 варианта как с помощью pf раскидывать юзерей по пулу:

 

nat on em0 inet from 172.16.0.0/16 to any -> x3.x4.x5.x6/27 round-robin sticky-address

 

и

 

nat on em0 inet from 172.16.0.0/16 to any -> x3.x4.x5.x6/27 source-hash

 

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

Давно перешел с round-robin на source-hash с тем, чтоб проще было отчитываться кто куда с какого IP лазил, да и банило чтоб спамеров и прочих хулиганов на внешних ресурсах за дело и на одном адресе, а не кого попало и пока всю маску не испортят.

В момент перехода увеличения задержек и загрузки системы не заметил.

Начу маской /24.

[Dyr]

А я наоборот, с source-hash на round-robin sticky-address залез. %) С той же целью, причём. :)

[kapa]

А я наоборот, с source-hash на round-robin sticky-address залез. %) С той же целью, причём. :)

с той же целью не получится - он же только на время стейта прилепляется.

[mousus]

неа, round-robin sticky-address работает с темже ипешником даже после реконнекта PPPoE сессии под темже логином и паролем, и это присвоение держится всё время что запущен pf при перезапуске сервака в следующий раз получаются другие адреса, которые тоже живут до перезапуска, и естественно это справедливо только когда из биллинга прилетает абоненту статический ипешник. замечены кстати небольшие задержки при вэбсёрфинге связанные с однопоточностью pf с ipfw и natd странцы грузятся влёт по клику а тут происхдит задержка на полсекунды гдето

[kapa]

неа, round-robin sticky-address работает с темже ипешником даже после реконнекта PPPoE сессии под темже логином и паролем, и это присвоение держится всё время что запущен pf при перезапуске сервака в следующий раз получаются другие адреса, которые тоже живут до перезапуска, и естественно это справедливо только когда из биллинга прилетает абоненту статический ипешник. замечены кстати небольшие задержки при вэбсёрфинге связанные с однопоточностью pf с ipfw и natd странцы грузятся влёт по клику а тут происхдит задержка на полсекунды гдето

Вы с source-hash без указания хэша не путаете?

[mousus]

а там та же история, только с тем приколом что ипешники на которые pf натит по другому распределяются, проверено экспериментально

 

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

Edited November 30, 2009 by mousus

[kapa]

а там та же история, только с тем приколом что ипешники на которые pf натит по другому распределяются, проверено экспериментально

man pf.conf

source-hash

The source-hash option uses a hash of the source address to deter-

mine the redirection address, ensuring that the redirection address

is always the same for a given source. An optional key can be

specified after this keyword either in hex or as a string; by de-

fault pfctl(8) randomly generates a key for source-hash every time

the ruleset is reloaded.

round-robin

The round-robin option loops through the redirection address(es).

.....

Additionally, the sticky-address option can be specified to help ensure

that multiple connections from the same source are mapped to the same

redirection address. This option can be used with the random and round-

robin pool options. Note that by default these associations are de-

stroyed as soon as there are no longer states which refer to them; in or-

der to make the mappings last beyond the lifetime of the states, increase

the global options with set timeout src.track. See STATEFUL TRACKING

OPTIONS for more ways to control the source tracking.

[Elisium]

маску только /32 поставьте, а не /24

 

собственно так в рекомендациях и написано делать...

 

 

PS: разницы по нагрузке с внешним интерфейсом нет...

Уважаемые гуру .. можно ссылку на рекомендации ?

 

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

Все работает, но вариант с привинчиванием 512 адресов на интерфейс выглядит красиво (настройки только на нате, а в моем варианте нужно еще и на бгп делать), но както стремновато ...

[XeonVs]

на бгп ничего лишнего привинчивать не надо кроме маршрута на более крупную сеть(/23) в сторону твоего ната.

Edited November 30, 2009 by XeonVs

[Elisium]

Да эт я знаю )))

Хотелось бы просто увидеть ИМЕННО "рекомендации", так как рытье инета кроме ссылок в наг по подобному вопросу ничего полезного не дает (((

 

Да и собсно почитать, чем вариант с фейкомой подсеткой хуже/лучше/пофих, чем с прописываением кучи адресов на ло0.

Как бы, вопрос то даже один - не будет ли плохо серваку от такого счастья в виде полкило адресов ?

[XeonVs]

Да эт я знаю )))

Хотелось бы просто увидеть ИМЕННО "рекомендации", так как рытье инета кроме ссылок в наг по подобному вопросу ничего полезного не дает (((

 

Да и собсно почитать, чем вариант с фейкомой подсеткой хуже/лучше/пофих, чем с прописываением кучи адресов на ло0.

Как бы, вопрос то даже один - не будет ли плохо серваку от такого счастья в виде полкило адресов ?

хз, у меня 64 адреса только. на производительности особо не сказалось, если не считать нагрузку от торентщиков которые смогли в такой позе через нат у друг друга качать. Но с запуском внутренних ретрекеров, эта проблема не актуальна стала особо, популярный трафик замыкается внутри локалки.

[Elisium]

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

Оо! Уже интереснЕе ..пожалуй попробую для теста таким макаром тоже сделать ..

[mousus]

у меня пока на 2 брасах по 32 адреса сетки на ло0 прописаны, в сумме брасы пока 100 мегабит трафа молотят.

 

l0-bras2# pfctl -ss | wc -l

14540

 

l0-bras2# netstat -I em0 -w 1

input (em0) output

packets errs bytes packets errs bytes colls

3150 0 3154183 2484 0 704660 0

3138 0 3108128 2535 0 680815 0

3110 0 3128752 2417 0 682385 0

3344 0 3157524 2603 0 765774 0

3168 0 3127617 2526 0 755536 0

3544 0 3317742 2606 0 745831 0

 

это днём, вечером естественно в 2 -3 раза больше циферки, и усё ходит)) асечники счастливы

[jab]

 

Почему-то 16000 интерфейсов на сервере и миллион раутов никого не удивляют, а какие-то пол-тыщи алиасов пугают до дрожи.

Ну а религия не позволяет повесить на тестовой машине и посмотреть.