Что: cdd29ba1d7a5fdd299f169e5d213c33258e561df
Когда: 2023-09-22 00:23:12+03:00
Темы: bgp bsd ipv6
BIRD OSPF, default route, 10GbE с hop-ом
Первая задача что стояла (efb7b138ba42bd19945b3ab1f700c340061524f2):
трафик с NUC должен ходить до beta-сервера через gw-сервер, так как они
соединены 10GbE. Но NUC соединён с beta-сервером и напрямую через 1GbE.
Об этом всём они знают через OSPF. cost интерфейса в OSPF по умолчанию
равен 10. Прежде, я просто задавал cost=5 и 10GbE интерфейс становился
более приоритетным. Я подумал что возможно из-за дополнительного hop-а,
5+5≥10 (какой-нибудь там ещё плюсик появляется) и поэтому маршрут до
beta всё равно идёт через 1GbE.
Долго возился, делал огромные cost-ы у 1GbE интерфейса, но он всё равно
упорно не собирался ходить через лишний hop. Понял что что-то у меня не
ладно с пониманием OSPF в BIRD, ибо у меня метрики много где показывают
10000, 10001, 10002, в зависимости от кол-ва hop-ов в этих маршрутах.
Какое-то большое значение. В документации его нашёл только в упоминании
метрик для OSPF от external маршрутов.
Голова уже не очень свежа, но похоже что дело было так: источник
маршрутов на самой машине это protocol direct, в котором я перечисляю
"lo0" как минимум. Адреса с него становятся маршрутами, внешними с точки
зрения OSPF. И имея огромные веса, всякие мои потуги с cost интерфейсов
ни на что не влияют. В общем, сделал так: 10GbE интерфейсы имеют cost по
умолчанию (10); 1GbE cost=100; WG-туннели в Интернет cost=1000. И
добавил строчку с заданием метрики OSPF в фильтр экспорта только
"Интернет" маршрутов, которые у меня copy-paste на всех машинах:
filter only_internet {
if proto = "directed" then ospf_metric1 = 1;
if net ~ [2000::/3+] then accept;
reject;
}
после этого, метрики birdc show route стали вменяемыми, и по сути
показывать и количество hop-ов как-бы и интерфейсы между ними. После
этого всё стало работать как надо, как я ожидаю и хочу. Документация по
protocol direct говорит что надо бы подумать, прежде чем вообще
применять этот протокол, ибо learn в protocol kernel типа должен и так
всё сделать. Понятия не имею что там будет с метриками при этом, почему
я от learn избавился не помню, но надо бы будет выяснить.
------------------------ >8 ------------------------
Вторая задача возникла на пустом месте. На втором сервере у меня если не
подключён 10GbE, то я хотел бы чтобы трафик, очевидно, всё равно шёл по
1GbE имеющемуся. Добавил в /etc/rc.conf:
ipv6_defaultrouter="2a03:e2c0:2663:2::1 -mtu 1480"
ожидая что после поднятия BIRD, он добавит маршрут до ::2:1 и default
route сможет типа работать. И этот сервер перезапускался уйму раз, и...
я считал что всё работало. Я же мог на него SSH-нутся. И за это время я
только по IPv6 или в LAN работал, или BitTorrent по IPv4 использовал,
который вообще статично настроен и демонов маршрутизации не касается. В
netstat -r я видел default маршрут, но не пытался сделать ping на что-то
вне LAN. А на него он говорил бы:
ping: sendmsg: No buffer space available
ping6: wrote ya.ru 16 chars, ret=-1
Обнаружил это уже на своём ПК, в котором появился 10GbE и я аналогичную
конфигурацию проделал.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221445
Увидел что в самом BIRD можно задать статичный маршрут.
route ::/0 via 2a03:e2c0:2663:2::1;
и вижу что в ядре ничего не появляется. И только спустя пару часов я
вновь решил посмотреть получше документацию и увидел, что вместо "via"
можно задавать "recursive", который прям рекурсивно доходит до нужного
next hop адреса. И вот теперь то у меня нормально появляется и
обновляется default route, идущий через link-local адрес актуального на
данный момент сетевого интерфейса.
Сколько траханья, на простейших задачках! Как слабо я во всём это
понимаю. Но в итоге всё же без особых костылей оно работает как я хочу.
Сгенерирован: SGBlog 0.34.0