Перейти к содержимому
Калькуляторы

FreeBSD softBorder (ищу спеца)

Добрый день!

Нахожусь в поиске дистрибутива для softroutera но ничего годного не нахожу.

Хочу попробовать на FreeBSD 13.1 развернуть бордер на базе FRR (но он из портов не ставится, а в пакетах его нет)

FRR потому что есть с ним опыт большой, он стоит у нас на СКАТАх

из особенностей:

надо вынести форвард трафика в отдельный врф что бы оно не контактировало с management интерфейсом

NAT не нужен

VLANs - да

NETFLOW - нет

VRRP - да

PPPoE и прочего PPPoX нет

Нужен тупо роутинг и бгп фулвью на десяток сессий в врф

 

Железо:

HP DL380-G10

1хIntel Xeon Gold 6142 2.60GHz

32GB RAM 

Intel X520-DA2

 

Трафика будет 10 гигабит

 

Есть тут ктонить кто может помочь развернуть на последней фряхе FRR+vrf за денежку?

Важным моментом - хочу посмотреть как будут делать, что бы понять что я делал не так.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Был вроде и в портах и в пакетах:

 

/usr/ports/net/frr7/

/usr/ports/net/frr8/

 

# pkg search frr
frr7-7.5.1_4                   IP routing protocol suite including BGP, IS-IS, OSPF and RIP
frr7-pythontools-7.5.1_4       Provide configuration reload functionality for FRR
frr8-8.3.1_1                   IP routing protocol suite including BGP, IS-IS, OSPF and RIP
frr8-pythontools-8.3.1_1       Provide configuration reload functionality for FRR

 

Или как вариант попробуйте OpenBGPd

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да он есть в портах, просто не ставится

там зависимости FRR не собираются какая то нинзя и jlbson-c

 

по пакетам посмотрю искал по слову фрр не находил что то, перепроверю

PS: в пакетах не последняя версия, в портах версия 8.4 а в пакетах 8.3 (

Я уже несколько дней бьюсь и нихера

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 Ставьте из пакетов, точно заработает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 16.11.2022 в 16:31, jffulcrum сказал:

Оно то оно тока у них нормального инсталятора нет, мы не осилили его

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 16.11.2022 в 16:33, catalist сказал:

Оно то оно тока у них нормального инсталятора нет, мы не осилили его

 Осилить нормальную работу из портов у меня закончилось с версии 11. Далее, я устарел и устал бороться с зависимостями, поэтому перешел на установку из пакагджей. Депенденсы утомляют даже при свежей установке из обновленных портов :(, если ставишь многое чего необходимое. В пакаджах точно не беспокоишься, чего у тебя не той версии-сборки....

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 16.11.2022 в 10:35, catalist сказал:

там зависимости FRR не собираются какая то нинзя и jlbson-c

Какие ошибки то?

Порты точно свежие? Как обновляли дерево портов?

 

 

В 16.11.2022 в 11:42, YuryD сказал:

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

Осилить работу под сервер - обычно вообще ничего не требуется.

Вот с дексктопом периодически что то вылезает, потому что портов 700+ требуется.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

порты через портснап обновлял

 

вот одна из ошибок:

ninja: error: manifest 'build.ninja' still dirty after 100 tries, perhaps system time is not set

ЗЫ: время нормальное на сервере было

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 17.11.2022 в 12:00, catalist сказал:

ninja: error: manifest 'build.ninja' still dirty after 100 tries, perhaps system time is not set

https://github.com/ninja-build/ninja/issues/1599

Не специфично для фри.

 

В 17.11.2022 в 12:00, catalist сказал:

ЗЫ: время нормальное на сервере было

Было или показалось что было?

 

Смотрим сюда:

sysctl kern.eventtimer.choice

потом выставляем в kern.eventtimer.timer=HPET, если его нет - ищем в биосе и включаем.

 

Потом смотрим: sysctl kern.timecounter.choice

Выставляем kern.timecounter.hardware TSC-low или HPET или ACPI-fast

 

Ещё можно попробовать остановить сервис синхронизации времени, скорее всего ntpd у вас.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Втыкаем x710 под рост. FreeBSD заменяем на Debian, FRR на BIRD.

Берем второй сервер, повторяем.

Готово, забываем навсегда.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 18.11.2022 в 00:44, Ivan_83 сказал:

https://github.com/ninja-build/ninja/issues/1599

Не специфично для фри.

 

Было или показалось что было?

 

Смотрим сюда:

sysctl kern.eventtimer.choice

потом выставляем в kern.eventtimer.timer=HPET, если его нет - ищем в биосе и включаем.

 

Потом смотрим: sysctl kern.timecounter.choice

Выставляем kern.timecounter.hardware TSC-low или HPET или ACPI-fast

 

Ещё можно попробовать остановить сервис синхронизации времени, скорее всего ntpd у вас.

я видел эту ссылку

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

 

В 18.11.2022 в 11:13, vurd сказал:

Втыкаем x710 под рост. FreeBSD заменяем на Debian, FRR на BIRD.

Берем второй сервер, повторяем.

Готово, забываем навсегда.

 

чем бирд лучше фрр?

с фрр просто есть опыт, с бирдом нет

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 18.11.2022 в 09:53, catalist сказал:

чем бирд лучше фрр?

с фрр просто есть опыт, с бирдом нет

 

Видел график, где на одном и том же железе после замены фрр на бирд загрузка цпу падала ну если не в два, то в полтора раза так точно. Но будет больно, с бирдом надо разбираться.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 21.11.2022 в 09:27, vurd сказал:

Видел график, где на одном и том же железе после замены фрр на бирд загрузка цпу падала ну если не в два, то в полтора раза так точно. Но будет больно, с бирдом надо разбираться.

я не понимаю, чему там падать, если оно вообще проц не кушает ) ну в смысле - неужели другой софт написан более жруче?

вот стоит бордер с тремя фулл-вью (честными, по 900к маршрутов), скушанное бёрдом процессорное время - 1 час 40 минут за 80 суток аптайма. процесс snmpd и то больше отъел.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 21.11.2022 в 10:45, catalist сказал:

А есть тут спецы по бирду?

полно, это же ресурс сетевиков

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 21.11.2022 в 11:33, nixx сказал:

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

Подозреваю

hw.intr_storm_threshold=0        # Number of consecutive interrupts before storm protection is enabled

надо было сделать.

Дефолтное значение скорее всего для того чтобы хотя бы локально можно было работать в случае чего.

Плюс современные адаптеры умеют тюнится чтобы снижать рейт прерываний.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 22.11.2022 в 04:00, Ivan_83 сказал:

Подозреваю

hw.intr_storm_threshold=0        # Number of consecutive interrupts before storm protection is enabled

надо было сделать.

Дефолтное значение скорее всего для того чтобы хотя бы локально можно было работать в случае чего.

Плюс современные адаптеры умеют тюнится чтобы снижать рейт прерываний.

не пробовал. но именно локально оно и уходило в себя. top на экране зависал, на клавиатуру никакой реакции, все ядра в полке, пока не снимал трафик с сетевухи.

ну и гугл говорит, что при превышении этого значения должны быть сообщения типа "interrupt storm detected on..." - ничего подобного не было.

сетевухи были 82599 и connectx-4, сама фря - 10я, как чистая, так и с патчами от разработчика упомянутого здесь "BSD Router Project".

я тогда дошел до 7,5 Mpps без дропов, дальше дропы, дальше ну где-то на 10 Mpps - висяк. линукс же, даже при вливании в него по максимуму 14 Mpps, оставался вполне пинабельным с консоли, хоть и хреново роутящим )

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 21.11.2022 в 14:33, nixx сказал:

я не понимаю, чему там падать, если оно вообще проц не кушает ) ну в смысле - неужели другой софт написан более жруче?

вот стоит бордер с тремя фулл-вью (честными, по 900к маршрутов), скушанное бёрдом процессорное время - 1 час 40 минут за 80 суток аптайма. процесс snmpd и то больше отъел.

 

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

 

Я проверил. Перевел свои "брасы" на bird сегодня.

Да. Как и ожидалось, CPU без изменений :)

 

@catalist Ну значит специалист по бирду не нужен, можно остановиться на frr, это будет проще и быстрей.

 

Блин, дописали еще и VRRP что-ли. Работают там походу. Раньше keepalived решал вопросик.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 22.11.2022 в 17:50, nixx сказал:

ничего подобного не было.

сетевухи были 82599 и connectx-4, сама фря - 10я, как чистая, так и с патчами от разработчика упомянутого здесь "BSD Router Project".

Зависит от кучи других настроек и железа тоже.

После 10 было много всего запилено.

Фаеры могли много жрать.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 16.11.2022 в 13:19, catalist сказал:

NETFLOW - нет

а как без netflow отчитываться в РКН?

Изменено пользователем ne-vlezay80

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 23.11.2022 в 00:09, ne-vlezay80 сказал:

а как без netflow отчитываться в РКН?

 

а что ркн просит нетфлоу?

у нас есть скат, он же сорм.

 

Кстати вопрос в догонку, скажите где лучше фильтр поднять простенький (фильтровать кое какие порты и серые сети) на этом софт бордере (и какой выбрать?) или на коммутаторе к которому подключен бордер (у нас нексус)?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 23.11.2022 в 14:13, catalist сказал:

а что ркн просит нетфлоу?

у нас есть скат, он же сорм.

 

Кстати вопрос в догонку, скажите где лучше фильтр поднять простенький (фильтровать кое какие порты и серые сети) на этом софт бордере (и какой выбрать?) или на коммутаторе к которому подключен бордер (у нас нексус)?

На linux через nftables.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 18.11.2022 в 08:13, vurd сказал:

Втыкаем x710 под рост. FreeBSD заменяем на Debian, FRR на BIRD.

Берем второй сервер, повторяем.

Готово, забываем навсегда.

 

Почему bird? Frr хорош конфигами удобными 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.