Я виже в следующем:

1. Бекапы системных файлов.
2. Общее хранилище для скачаных портов. 

1. Устанавливаем FreeBSD сервер с bootp, даем расшарку корневых директорий через nfsd, т.е. /usr/, /var/ и т.д.
2. Бездисковую станцию загружаем через pxe, маунтим корневые шары.
3. Работаем.

Из плюсов - моментальный апгрейд ПО и большие возможности по управлению комплектацией рабочих станций, новые драйверы и т.п. 

У меня на серверах FreeBSD установлено следующее ПО по функциям:

VPN:
* PPTP: mpd
* IPSEC: ipsec(tunnel), racoon

Routing and BGP:
* zerba
  читать далее >>

В моем примере использовалась FreeBSD версии 5.3, Putty 0.58.

Заходим на FreeBSD шелл под пользовательским аккаунтом, т.е. не делаем ни SU ни SUDO.
Запускаем:
ssh-keygen -t dsa
после чего нас спросят пароль (тот же что и для входа), и место сохранения ключей, по умолчанию все будет в ~/.ssh/id_dsa и ~/.ssh/id_dsa.pub.
Первый ключ id_dsa приватный, его нам следует забрать и тут же удалить с сервера, второй ключ id_dsa.pub публичный, он будет использоваться на сервере для аутентификации пользователя.

cat id_dsa.pub>authorized_keys # копируем ключ в ключи для авторизации
rm id_dsa.pub # удаляем ненужный public

id_dsa копируем к себе на рабочую станцию (в моем случае Windows XP), запускаем puttygen.exe из состава Putty, загружаем этот ключ и сохраняем в формате putty (тот что ppk).

Запускаем pageant.exe который повиснет в трей и будет держать все наши ключи для авторизации, добавляем туда наш ключ (у меня это в винде в автозагрузке, передается параметром имя файла с ключем).

В самом Putty в конфигурации хоста указываем юзернейм и putty key -> наш ключ, не забываем сохранить.

И у вас должно все работать. 

Источник: FreeBSD роутер, снимаем статистику при помощи netgraph, отправляем на другой хост используя протокол netflow.

Анализ структуры трафика и графическое отображение делаем при помощи ManagEngine Netflow Analyzer 4.

Очень красиво так получается :)


ngctl connect fxp0: fxp0:lower upper right
ngctl mkpeer fxp0:lower netflow left2right iface0
ngctl name fxp0:lower.left2right netflow
ngctl msg netflow: setifindex { iface=0 index=4 }
ngctl mkpeer netflow: ksocket export inet/dgram/udp
ngctl msg netflow:export connect inet/192.168.0.12:9996

Где на 192.168.0.12 слушает Netflow Analyzer. 

http://www.unixfaq.ru/index.pl?req=qs&id=247 

Состояния счетчиков каждую секунду:



netstat -w 1 iostat -w 1 vmstat -w 1 

 

Соответственно zebra, с ее OSPF и BGP до одного места
Это факт, который заставляет меня обратиться к использованию Linux.

  читать далее >>

На самом деле этот вопрос можно разделить на две задачи. Первая, использование второго канала в качестве резервного, т.е. такого что бы поднимался в случае падения основного. Вторая задача - разгрузить первый канал, запустить часть некритичного трафика через второй канал. По схеме 2 уменя работает http трафик, т.е. на второй канал направляется весь http трафик, который и является, в общем, основным "грузилом", которое отражается на терминальных пользователях работающих на том же канале. Разруливается это путем принудительного кеширования и перенаправления squidом на тот канал, на который нужно. Из нюансов: POST запросы через кеш не рулят через резервный канал, подменяем в сквиде исходящий IP.

Ну это я отвлекся, хотел рассказать о способе организации failover резервного канала.
Т.к. во FreeBSD почему-то до сих пор отсутствует реализация multiroute и мы не можем задать два default гейтвея, то о "стандарном" способе речь не идет.
Наиболее оптимальным видится выход: стоит второй маршрутизатор рядом в той же сети, натроенный на второй канал, возможно с поднятым VPN, при падении первого канала на основном маршрутизаторе просто заменяем default route на адрес второго маршрутизатора, и алга.

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

Ну это все мысли, попробую на практике и отпишу тут же.