>>Пока carp в глубокой бетте, bgp-fullview домашния радоибалалайка не потянет по причине
>>отсутсвия нормального проца и достаточного кол-ва мозгов, с ospf тоже самое
>
>насчёт беты: вы где прочитали? В рассылках, до сих пор существует проблемы которые не позволяют использовать carp и ucarp в решениях выше класса "на поигратцо", следовательно , бетта :)
>
>зачем домашнему роутеру принимать fullview?
>ospf с небольшим числом роутеров и достаточно стабильной сети вполне потянет.
А потому как использование bgp без анализа fullview практически бессмысленно. Насчет ospf примерно тоже - немного легче, но похоже.
>>>ага. а много ли pf знает о чём-то, отличном от ip/tcp/udp/icmp?
>>А оно ему надо ?
>>Зато про то что он знает он знает на очень приличном уровне
>>- уровне комерческих решений, а это совсем не мало !!!
>
>мда, как обычно "это нам не надо".
>Типичный openbsd-way: виртуализация несекурна - это нам не надо. HT несекурно, это
>нам не надо. Многоядерные процессоры несекурны - это нам не надо.
я-же говорил что кесарю кесарево, нужно просто уметь находить оптимальные решения, для каких-то вещей наиболее оптимальные выход это применения проприетарной системы на кучу килобаксов, для другого наоборот. В этом-то все и дело, а зацикливацо на одном варианте - есть путь ущербный и неправильный. ИМХО.
>
>Подключение по ethernet несекурно - могут трафик слушать. может и его
>того, а?
см. выше
>
>>ftp-proxy, pptp-proxy, sip-proxy, про dcc не знаю поэтому ничего сказать не могу,
>>но имхо bi-nat это вполне может решить :)
>
>так и думал что будет юзерспейсовые костыли.
>50-60 человек активно качающих по ftp и ftp-proxy "уложит" роутер.
Нет (с)
>Насчёт pptp-proxy:
>"The proper way of forwarding PPTP is to use native kernel NAT,
>but it isn't always easy, feasible or even implemented properly. pptpproxy
>was written for these situations."
Абсолютно правильно бекоз pptp таже самая отрыжка прошлого как и ipx/spx, appletalk, но сохранять возможность использования пока еще надо. По крайней мере с l2tp таких проблем не возникает :)
