Настройка frr ospf debian
Обновлено: 07.07.2024
OpenVPN достаточно хорошо документирован и на хабре есть статьи по установке, к примеру:
вот эта.
Но так, чтобы сразу несколько тоннелей, между двумя серверами и автоматической отказоустойчивостью не нашел. В моем случае, серверы на которых будет располагаться OpenVPN и OSPF оба находятся за NATом. Это несколько усложняет решение, но в основном тем, что потребуется управлять трафиком, уходящим с интерфейсов пограничного маршрутизатора.
Два пограничных маршрутизатора Centos 7:
r01:
ens0 1.1.1.1 – провайдер 1
ens1 2.2.2.2 – провайдер 2
ens2 10.0.0.1 – виртуальная сеть между шлюзом и OpenVPN сервером.
r02:
ens0 3.3.3.3 – провайдер 3
ens1 4.4.4.4 – провайдер 4
ens2 10.1.1.1 – виртуальная сеть между шлюзом и OpenVPN сервером.
Два OpenVPN/OSPF сервера Centos 7:
host01:
ens0 10.0.0.2 – SNAT через сеть провайдер 1.
ens0 10.0.0.3 – SNAT через сеть провайдер 2.
ens1 192.168.0.0/23 – локальная сеть.
host02:
ens0 10.1.1.2 – SNAT через сеть провайдер 3.
ens0 10.1.1.3 – SNAT через сеть провайдер 4.
ens1 192.168.4.0/23 – локальная сеть.
Все провайдеры в данной схеме разные, имеют разную скорость, стоимость.
Задача:
Создать 4 тоннеля между host01 и host02 так, чтобы они были всегда активны и в случае падения любого из провайдеров, маршрут должен переключаться на более медленный или дорогой канал. Даже если выйдут из строя оба провайдера (по одному на каждом сервере), канал также должен функционировать. В то же время, если более предпочтительный канал заработает – серверу придется перейти на него.
В этой статье я не буду подробно описывать процесс генерации ключей, установки OpenVPN, Quagga. Скажу лишь, что генерировать ключи для сервера и клиента достаточно один раз, так как можно использовать DH и все прочие ключи и сертификаты для всех инстансов одновременно. Но, конечно, если вы очень озабочены безопасностью – можно сгенерировать по два сертификата под каждый тоннель. В моем случае, был один сертификат на серверные службы и один на клиентские.
Установка:
Система CentOS Linux release 7.4.1708 (Core) / 3.10.0-693.5.2.el7.x86_64.
yum install openvpn easy-rsa quagga
версии ПО, которые были использованы:
Настройка:
Для тоннелей выбраны следующие порты:
udp 1150 – 1.1.1.1-3.3.3.3
udp 1151 – 2.2.2.2-4.4.4.4
udp 1152 – 1.1.1.1-4.4.4.4
udp 1153 – 2.2.2.2-3.3.3.3
Следует обратить внимание, что OpenVPN требует чтобы порт, с которого сервер и клиент отправляют пакеты был таким же как и порт приема пакетов, при использовании NAT порт исходящего пакета может отличаться и тоннель не поднимется с такой ошибкой:
TCP/UDP: Incoming packet rejected from [AF_INET]1.1.1.1:1194[2], expected peer address: [AF_INET]1.1.1.1:2364 (allow this incoming source address/port by removing --remote or adding --float)
Чтобы порт точно был всегда верным надо настроить пограничный маршрутизатор и OpenVPN сервер:
В свою очередь на пограничном маршрутизаторе будет так (r01):
Далее настроим туннели, приведу конфиг одной пары клиент/сервер, остальные настраиваются также, просто меняется порт, адреса и номер tun интерфейса.
Важный параметр в конфигурации тоннеля topology subnet, он позволяет сделать адресацию тоннеля так, чтобы он выглядел как подсеть и не интерфейс точка-точка. Параметр не является параметром по умолчанию и рекомендуется для современных серверов. Без него нет возможности обмениваться широковещательными пакетами внутри тоннеля, тем самым не будет возможности настроить OSPF.
При поднятии тоннеля ifconfig на сервере и клиенте будет выглядеть так:
После того, как все 4 тоннеля подняты, получается такая картина.
udp 1150 – 1.1.1.1-3.3.3.3 – tun1 – 10.10.11.1-10.10.11.2
udp 1151 – 2.2.2.2-4.4.4.4 – tun2 – 10.10.12.1-10.10.12.2
udp 1152 – 1.1.1.1-4.4.4.4 – tun3 – 10.10.15.1-10.10.15.2
udp 1153 – 2.2.2.2-3.3.3.3 – tun4 – 10.10.16.1-10.10.16.2
Никаких дополнительных статических маршрутов добавлять не требуется, кроме добавления правил сетевого экрана:
Отказоустойчивость.
Можно добиться переключения маршрутов и с помощью скриптов, но получилось бы громоздкое и совсем не элегантное решение. Ранее мне не доводилось использовать динамическую маршрутизацию на практике. Протоколов довольно много, остановился я на OSPF, по большому счету, потому, что информации и способов применения нашел больше. Протокол linkstate типа, учитывает состояние каналов, интерфейсов и обменивается ею. Думаю, что вполне можно реализовать подобное на BGP или RIP. С радостью бы посмотрел на BGP версию решения.
Чтобы OSPF мог получать и отправлять служебные пакеты LSA – Link State Advertisement потребуется открыть порты на сетевом экране:
Перейдем к настройке Quagga.
Для начала надо убедиться что папки и файлы, фигурирующие в работе служб Quagga принадлежали пользователю под которым служба запускается:
После этого можно начать конфигурировать OSPF.
В консоль можно попасть двумя способами, telnet или vtysh, я выбрал второе.
Лучше сразу же попробовать сделать write, чтобы проверить права на файлы конфигурации, иначе все команды, которые вы введете не сохранятся, должно получиться так:
Проверьте, все ли ваши интерфейсы доступны для zebra.
Если маршрутизируемые через OSPF сети и все tun интерфейсы на месте, можно продолжать.
Прежде всего, необходимо настроить стоимость туннелей, чем меньше стоимость, тем приоритетнее туннель. Сделать это можно так:
И далее для других tun2 30, tun3 15, tun4 20 в моем случае.
После чего можно запускать маршрутизатор:
В данной конфигурации используется параметр redistribute connected для того, чтобы анонсировать не все маршруты на другой сервер, а только нужные, а параметр route-map LAN позволяет фильтровать сети.
Точно такая же конфигурация должна быть и с другой стороны тоннеля. После активации службы ospfd примерно через 10 секунд на обоих серверах появятся маршруты соседей и тоннель будет выбран согласно стоимости. В случае, если предпочитаемый тоннель перестанет работать, автоматически произойдет переключение на другой тоннель и так далее, пока тоннелей не останется. И также, если более удачный интерфейс снова будет активирован – маршрутизация пойдет по нему.
Примерное время обновления маршрутов 10 секунд, можно варьировать параметры ip ospf hello-interval и ip ospf dead-interval для сокращения этого времени.
Не забудьте добавить все службы в автозагрузку, к примеру мои файлы конфигурации OpenVPN называются srv-1050.conf и cli-1050.conf, в этом случае команды будут выглядеть так:
This section covers the basics of building, installing and setting up FRR.
From Packages¶
The project publishes packages for Red Hat, Centos, Debian and Ubuntu on the GitHub releases. page. External contributors offer packages for many other platforms including *BSD, Alpine, Gentoo, Docker, and others. There is currently no documentation on how to use those but we hope to add it soon.
From Snapcraft¶
From Source¶
Building FRR from source is the best way to ensure you have the latest features and bug fixes. Details for each supported platform, including dependency package listings, permissions, and other gotchas, are in the developer’s documentation. This section provides a brief overview on the process.
Getting the Source¶
FRR’s source is available on the project GitHub page.
When building from Git there are several branches to choose from. The master branch is the primary development branch. It should be considered unstable. Each release has its own branch named stable/X.X , where X.X is the release version.
In addition, release tarballs are published on the GitHub releases page here.
Build Configuration¶
FRR has an excellent configure script which automatically detects most host configurations. There are several additional configure options to customize the build to include or exclude specific features and dependencies.
First, update the build system. Change into your FRR source directory and issue:
This will install any missing build scripts and update the Autotools configuration. Once this is done you can move on to choosing your configuration options from the list below.
Enable the alternate malloc library. In some cases this is faster and more efficient, in some cases it is not.
Do not build any documentation, including this one.
From the documentation build html docs as well in addition to the normal output.
Do not build zebra daemon. This generally only be useful in a scenario where you are building bgp as a standalone server.
Do not build ripd.
Do not build ripngd.
Do not build ospfd.
Do not build ospf6d.
Do not build bgpd.
Do not build ldpd.
Do not build nhrpd.
Do not build eigrpd.
Do not build babeld.
Do not build watchfrr. Watchfrr is used to integrate daemons into startup/shutdown software available on your machine. This is needed for systemd integration, if you disable watchfrr you cannot have any systemd integration.
Build with all warnings converted to errors as a compile option. This is recommended for developers only.
Turn off building of pimd. On some BSD platforms pimd will not build properly due to lack of kernel support.
Turn off building of vrrpd. Linux is required for vrrpd support; other platforms are not supported.
Turn off building of pbrd. This daemon currently requires linux in order to function properly.
Turn on building of sharpd. This daemon facilitates testing of FRR and can also be used as a quick and easy route generator.
Do not build staticd. This daemon is necessary if you want static routes.
Do not build bfdd.
Make bgpd which does not make bgp announcements at all. This feature is good for using bgpd as a BGP announcement listener.
Turn off bgpd’s ability to use VNC.
Turn off BGP BMP support
This option is deprecated as it is superseded by the -F (profile) command line option which allows adjusting the setting at startup rather than compile time.
Enable system defaults to work as if in a Data Center. See defaults.h for what is changed by this configure option.
Enable SNMP support. By default, SNMP support is disabled.
Disable support for OSPF-API, an API to interface directly with ospfd. OSPF-API is enabled if –enable-opaque-lsa is set.
Disable building of the example OSPF-API client.
Do not build isisd.
Do not build fabricd.
Enable IS-IS topology generator.
Enable the support of Linux Realms. Convert tag values from 1-255 into a realm value when inserting into the Linux kernel. Then routing policy can be assigned to the realm. See the tc man page.
Disable IRDP server support. This is enabled by default if we have both struct in_pktinfo and struct icmphdr available to us.
Disable support IPV6 router advertisement in zebra.
Pass the -rdynamic option to the linker driver. This is in most cases necessary for getting usable backtraces. This option defaults to on if the compiler is detected as gcc, but giving an explicit enable/disable is suggested.
Controls backtrace support for the crash handlers. This is autodetected by default. Using the switch will enforce the requested behaviour, failing with an error if support is requested but not available. On BSD systems, this needs libexecinfo, while on glibc support for this is part of libc itself.
Turn on some options for compiling FRR within a development environment in mind. Specifically turn on -g3 -O0 for compiling options and add inclusion of grammar sandbox.
Build without SNMP support.
Build without VTYSH.
Build with FPM module support.
Alpine Linux does not allow non-numeric characters in the version string. With this option, we provide a way to strip out these characters for APK dev package builds.
Remove the “configuerd with” field that has all of the build configuration arguments when reporting the version string in show version command.
--with-pkg-extra-version =VER ¶ Add extra version field , for packagers/distributions ¶ --with-pkg-git-version ¶
Add git information to MOTD and build version string
Compile FRR with up to X way ECMP supported. This number can be from 0-999. For backwards compatibility with older configure options when setting X = 0, we will build FRR with 64 way ECMP. This is needed because there are hardcoded arrays that FRR builds towards, so we need to know how big to make these arrays at build time. Additionally if this parameter is not passed in FRR will default to 16 ECMP.
Turn on the ability of FRR to access some shell options( telnet/ssh/bash/etc. ) from vtysh itself. This option is considered extremely unsecure and should only be considered for usage if you really really know what you are doing.
Code coverage reports from gcov require adjustments to the C and LD flags. With this option, gcov instrumentation is added to the build and coverage reports are created during execution. The check-coverage make target is also created to ease report uploading to codecov.io. The upload requires the COMMIT (git hash) and TOKEN (codecov upload token) environment variables be set.
Build with configuration rollback support. Requires SQLite3.
Build the ConfD northbound plugin. Look for the libconfd libs and headers in dir .
Build the Sysrepo northbound plugin.
Enable the gRPC northbound plugin.
Enable the ZeroMQ handler.
Use libpam for PAM support in vtysh.
This option is deprecated as it was replaced by the service cputime-stats CLI command, which may be adjusted at runtime rather than being a compile-time setting. See there for further detail.
This option is deprecated as it was replaced by the service cputime-warning NNN CLI command, which may be adjusted at runtime rather than being a compile-time setting. See there for further detail.
Turn on the usage of PCRE Posix libs for regex functionality.
Set hardcoded rpaths in the executable [default=yes].
Enable Lua scripting [default=no].
You may specify any combination of the above options to the configure script. By default, the executables are placed in /usr/local/sbin and the configuration files in /usr/local/etc . The /usr/local/ installation prefix and other directories may be changed using the following options to the configuration script.
Install architecture-independent files in prefix [/usr/local].
Look for configuration files in dir [ prefix /etc]. Note that sample configuration files will be installed here.
Configure zebra to use dir for local state files, such as pid files and unix sockets.
Look for Lua scripts in dir [ prefix /etc/frr/scripts].
Look for YANG modules in dir [ prefix /share/yang]. Note that the FRR YANG modules will be installed here.
Set StrongSWAN vici interface socket path [/var/run/charon.vici].
The former --enable-systemd option does not exist anymore. Support for systemd is now always available through built-in functions, without depending on libsystemd.
Python dependency, documentation and tests¶
FRR’s documentation and basic unit tests heavily use code written in Python. Additionally, FRR ships Python extensions written in C which are used during its build process.
To this extent, FRR needs the following:
an installation of CPython, preferably version 3.2 or newer (2.7 works but is end of life and will stop working at some point.)
development files (mostly headers) for that version of CPython
an installation of sphinx for that version of CPython, to build the documentation
an installation of pytest for that version of CPython, to run the unit tests
The sphinx and pytest dependencies can be avoided by not building documentation / not running make check , but the CPython dependency is a hard dependency of the FRR build process (for the clippy tool.)
Least-Privilege Support¶
Additionally, you may configure zebra to drop its elevated privileges shortly after startup and switch to another user. The configure script will automatically try to configure this support. There are three configure options to control the behaviour of FRR daemons.
Switch to user user shortly after startup, and run as user `user in normal operation.
Switch real and effective group to group shortly after startup.
Create Unix Vty sockets (for use with vtysh) with group ownership set to group . This allows one to create a separate group which is restricted to accessing only the vty sockets, hence allowing one to delegate this group to individual users, or to run vtysh setgid to this group.
The default user and group which will be configured is ‘frr’ if no user or group is specified. Note that this user or group requires write access to the local state directory (see --localstatedir ) and requires at least read access, and write access if you wish to allow daemons to write out their configuration, to the configuration directory (see --sysconfdir ).
On systems which have the ‘libcap’ capabilities manipulation library (currently only Linux), FRR will retain only minimal capabilities required and will only raise these capabilities for brief periods. On systems without libcap, FRR will run as the user specified and only raise its UID to 0 for brief periods.
Linux Notes¶
There are several options available only to GNU/Linux systems. If you use GNU/Linux, make sure that the current kernel configuration is what you want. FRR will run with any kernel configuration but some recommendations do exist.
CONFIG_NETLINK
Kernel/User Netlink socket. This enables an advanced interface between the Linux kernel and zebra ( Kernel Interface ).
CONFIG_RTNETLINK
This makes it possible to receive Netlink routing messages. If you specify this option, zebra can detect routing information updates directly from the kernel ( Kernel Interface ).
CONFIG_IP_MULTICAST
This option enables IP multicast and should be specified when you use ripd ( RIP ) or ospfd ( OSPFv2 ) because these protocols use multicast.
Linux sysctl settings and kernel modules¶
There are several kernel parameters that impact overall operation of FRR when using Linux as a router. Generally these parameters should be set in a sysctl related configuration file, e.g., /etc/sysctl.conf on Ubuntu based systems and a new file /etc/sysctl.d/90-routing-sysctl.conf on Centos based systems. Additional kernel modules are also needed to support MPLS forwarding.
IPv4 and IPv6 forwarding
The following are set to enable IP forwarding in the kernel:
The following is an example to enable MPLS forwarding in the kernel, typically by editing /etc/sysctl.conf :
Make sure to add a line equal to net.mpls.conf.<if>.input for each interface ‘<if>’ used with MPLS and to set labels to an appropriate value.
VRF forwarding
Kernel support for VRFs was introduced in 4.3, but there are known issues in versions up to 4.15 (for IPv4) and 5.0 (for IPv6). The FRR CI system doesn’t perform VRF tests on older kernel versions, and VRFs may not work on them. If you experience issues with VRF support, you should upgrade your kernel version.
Building¶
Once you have chosen your configure options, run the configure script and pass the options you chose:
After configuring the software, you are ready to build and install it in your system.
If everything finishes successfully, FRR should be installed. You should now skip to the section on Basic Setup .
Поскольку сеть является одним из ключевых элементов Ceph, а она в нашей компании немного специфична — расскажем сначала немного о ней.
Тут будет сильно меньше описаний самого Ceph, в основном сетевая инфраструктура. Описываться будут только сервера Ceph-а и некоторые особенности серверов виртуализации Proxmox.
Итак: Сама сетевая топология построена как Leaf-Spine. Классическая трехуровневая архитектура представляет из себя сеть, где есть Core (маршрутизаторы ядра), Aggregation (маршрутизаторы агрегации) и связанные напрямую с клиентами Access (маршрутизаторы доступа):
Трехуровневая схема
Топология Leaf-Spine состоит из двух уровней: Spine (грубо говоря основной маршрутизатор) и Leaf (ветви).
Двухуровневая схема
Вся внутренняя и внешняя маршрутизация построена на BGP. Основная система, которая занимается управлением доступами, анонсами и прочее — это XCloud.
Сервера, для резервирования канала (а так-же для его расширения) подключаются к двум L3 коммутаторам (большинство серверов включаются в Leaf коммутаторы, но часть серверов с повышенной сетевой нагрузкой включаются напрямую в Spine коммутатора), и через протокол BGP анонсируют свой unicast адрес, а так же anycast адрес для сервиса, если несколько серверов обслуживают трафик сервиса и им достаточно ECMP балансировки. Отдельной особенностью этой схемы, которая позволила нам сэкономить на адресах, но так же потребовала от инженеров познакомиться с миром IPv6, стало использование BGP unnumbered standard на основе RFC 5549. Какое-то время для обеспечения работы BGP в этой схеме для серверов применяли Quagga и периодически возникали проблемы с потерей пиров и связностью. Но после перехода на FRRouting (активными контрибьюторами которого являются наши поставщики ПО для сетевого оборудования: Cumulus и XCloudNetworks), больше таких проблем мы не наблюдали.
Всю эту общую схему для удобства называем "фабрика".
Поиск пути
Варианты настройки cluster network:
1) Вторая сеть на BGP
2) Вторая сеть на двух отдельных стекированных коммутаторах с LACP
3) Вторая сеть на двух отдельных изолированных коммутаторах с OSPF
Тесты
Тесты проводились двух типов:
а) сетевые, с помощью утилит iperf, qperf, nuttcp
b) внутренние тесты Ceph ceph-gobench, rados bench, создавали rbd и тестировали на них с помощью dd в один и несколько потоков, с помощью fio
Все тесты проводились на тестовых машинах с SAS дисками. На сами цифры в производительности rbd не сильно смотрели, использовали только для сравнения. Интересовали изменения в зависимости от типа подключения.
Первый вариант
Сетевые карты подключены к фабрике, настроены BGP.
Использовать эту схему для внутренней сети посчитали не самым лучшим выбором:
Во первых лишнее количество промежуточных элементов в виде коммутаторов, дающих дополнительные latency (это было основной причиной).
Во вторых первоначально для отдачи статики через s3 использовали anycast адрес, поднятый на нескольких машинах с radosgateway. Это выливалось в то, что трафик с фронтендовых машин до RGW распределялся не равномерно, а проходил по кратчайшему маршруту — то есть фронтовый Nginx всегда обращался к той ноде с RGW, которая была подключена к общему с ней leaf-у (это, конечно, был не основной аргумент — мы просто отказались в последствии от anycast адреса для отдачи статики). Но для чистоты эксперимента решили провести тесты и на такой схеме, чтоб иметь данные для сравнения.
Запускать тесты на всю полосу пропускания побоялись, поскольку фабрика используется prod серверами, и если бы мы завалили линки между leaf и spine — то это бы задело часть прода.
Собственно, это было еще одной из причин отказа от такой схемы.
Тесты iperf с ограничением BW в 3Gbps в 1, 10 и 100 потоков использовались для сравнения с другими схемами.
Тесты показали следующие результаты:
в 1 поток примерно 9.30 — 9.43 Gbits/sec (при этом сильно вырастает количество ретрансмитов, до 39148). Цифра оказалась приближенная к максимуму одного интерфейса говорит о том, что используется один интерфейс из двух. Количество ретрансмитов при этом примерно 500-600.
в 10 потоков 9.63 Gbits/sec на интерфейс, при этом количество ретрансмитов вырастало до среднего 17045.
в 100 потоков результат оказался хуже чем в 10, при этом количество ретрансмитов меньше: среднее значение 3354
Второй вариант
LACP
Нашлось два коммутатора Juniper EX4500. Собрали их в стек, подключили сервера первыми линками в один коммутатор, вторыми во второй.
Первоначальная настройка бондинга была такой:
Тесты iperf и qperf показали Bw до 16Gbits/sec. Решили сравнить разные типа мода:
rr, balance-xor и 802.3ad. Так-же сравнивали разные типы хэширования layer2+3 и layer3+4 ( рассчитывая выгадать преимущество на вычислениях хэшей).
Ещё сравнили результаты при различных значениях sysctl переменной net.ipv4.fib_multipath_hash_policy, (ну и поиграли немного с net.ipv4.tcp_congestion_control, хотя она к бондингу отношения не имеет. По этой переменной есть хорошая статья ValdikSS)).
Но на всех тестах так и не получилось преодолеть порог в 18Gbits/sec (этой цифры достигли используя balance-xor и 802.3ad, между ними в результатах тестов разницы особо не было) и то это значение достигалось "в прыжке" всплесками.
Третий вариант
OSPF
Для настройки этого варианта убрали LACP с коммутаторов (стекирование оставили, но оно использовалось лишь для менеджмента). На каждом коммутаторе собрали по отдельному vlan-у для группы портов (с прицелом на будущее, что в эти же коммутаторы будут воткнуты как QA так и PROD сервера).
Настроили две плоских приватных сети для каждого vlan (по одному интерфейсу в каждый коммутатор). Поверх этих адресов идет анонсирование еще одного адреса из третьей приватной сети, которая и является cluster network для CEPH.
Поскольку public network (по которой мы ходим по SSH ) работает на BGP, то для настройки OSPF использовали frr, который уже стоит в системе.
10.10.10.0/24 и 20.20.20.0/24 — две плоских сети на коммутаторах
172.16.1.0/24 — сеть для анонсирования
Настройка машины:
интерфейсы ens1f0 ens1f1 смотрят в приватную сеть
интерфейсы ens4f0 ens4f1 смотрят в публичную сеть
Конфиг сети на машине выглядит так:
Конфиги frr выглядят так:
На этих настройках сетевые тесты iperf, qperf и т.д. показали максимальную утилизацию обоих каналов в 19.8 Gbit/sec, при этом latency упало до 20us
Поле bgp router-id: Используется для идентификации узла при обработке маршрутной информации и построении маршрутов. Если не указано в конфиге, то выбирается один из IP адресов узла. У разных производителей оборудования и ПО алгоритмы могут разниться, в нашем случае FRR использовал наибольший IP адрес на loopback. Это приводило к двум проблемам:
1) Если мы пытались повесить еще один адрес (например, приватный из сети 172.16.0.0) больше, чем текущий — то это приводило к смене router-id и, соответственно, к переустановке текущих сессий. А значит к кратковременному разрыву и потере сетевой связности.
2) Если мы пытались повесить anycast адрес, общий для нескольких машин и он выбирался в качестве router-id — в сети появлялись два узла с одинаковым router-id.
Часть 2
После тестов на QA приступили к модернизации боевого Ceph.
NETWORK
Переезд с одной сети на две
Параметр cluster network один из тех, которые нельзя поменять на лету, указав OSD его через ceph tell osd.* injectargs. Изменить его в конфиге и перезапустить весь кластер — терпимое решение, но очень не хотелось иметь даже небольшой даунтайм. Перезапускать по одной OSD с новым параметром сети тоже нельзя — в какой-то момент мы бы поимели два полкластера — старые OSD на старой сети, новые на новой. Благо, параметр cluster network (как, кстати, и public_network) это список, то есть можно указать несколько значений. Решили переезжать постепенно — сначала добавить в конфиги новую сеть, потом убрать старую. Ceph идет по списку сетей последовательно — OSD начинает работать сначала с той сетью, которая в списке указана первой.
Сложность заключалась в том, что первая сеть работала через bgp и была подключена к одним коммутаторам, а вторая — на ospf и подключена к другим, физически не связанным с первыми. На момент перехода необходимо было иметь временно сетевой доступ между двумя сетями. Особенность настройки нашей фабрики была в том, что ACLы невозможно настроить на сеть, если её нет в списке аннонсируемой (в этом случае она является "внешней" и ACL для нее может быть создан только вовне. Он создавался на spain-ах, но не приезжал на leaf-ы).
Решение было костыльным, сложным, но работало: анонсировать внутреннюю сеть через bgp, одновременно с ospf.
Последовательность перехода получилась такой:
1) Настраиваем cluster network для ceph на двух сетях: через bgp и через ospf
В конфигах frr менять ничего не пришлось, строка
не ограничивает нас в анонсируемых адресах, сам адрес для внутренней сети поднят на loopback интерфейсе, достаточно было на маршрутизаторах настроить приём анонса этого адреса.
2) Добавляем в конфиг ceph.conf новую сеть
и начинаем по одному перезапускать OSD, пока все не переходят на сеть 172.16.1.0/24.
$ net add ospf router-id 10.0.10.1
$ net add ospf network 10.10.0.0/24 area 0.0.0.0
$ net add ospf network 10.0.10.0/32 area 0.0.0.0
$ net add ospf network 10.11.0.0/16 area 0.0.0.0
После применения такой стандартной конфигурации используя информацию со схемы, можно проверять соседство, маршруты и прочую информацию.
Базовая редистрибуция
На нашей схеме два роутера добавляют в топологию внешние маршруты.$ net add routing route 192.168.0.0/24 null0
$ net add ospf redistribute static metric 100
$ net add ospf redistribute static metric-type 1
$ net add routing route 172.16.0.0/24 null0
$ net add ospf redistribute static metric 100
$ net add ospf redistribute static metric-type 2
Посмотрим на это дело со стороны О6. Два внешних маршрута появились.
Тупики
По "дизайну" у нас тут ворох тупиковых зон - Stub, Totally Stub и NSSA.
Totally stub
Ладно, сделаем из O6 totally stub зону. Со стороны O3 нужно добавить ключ no-summary. Обо всем этом подробнее я рассказывал здесь и здесь.$ net add ospf area 2 stub no-summary
$ net add ospf area 2 stub
По какой-то причине внешние маршруты очень долго не хотели пропадать из ospf database O6, но в итоге мы наблюдаем типичную для "ваще тупиковой" зоны картину. Два LSA первого типа (router), один LSA второго типа (network) и LSA Type3 (summary) который обеспечивает выход из зоны. Ни записей о других зонах, ни тем более внешних префиксов.
Тут же нас поджидает первый сюрприз. Я не нашел поддержку NSSA в Cumulus NCLI. Причем, я говорю именно о NCLI. Да, через нее видимо настроить этот функционал не получится, но ничто не мещает нам настроить это напрямую через Quagga FRR. Для этого понадобится vtysh, который в cisco-like режиме позволяет настроить все что нужно.
После симметричной настройки на О7, соседство поднимается. В ospf database теперь чуть скучней.
Есть у нас еще и stub зона, правда с ней еще рано разбираться, ведь она "изолирована" от backbone области. Несите костыли.
Virtual Link
Вторая особенность, Cumulus NCLI не поддерживает настройку virtual-link. Снова воспользуемся vtysh от FRR.
На стороне O2 добавляем одну строку напрямую через vtysh (консоль FRR). Cisco-like, а значит проблем с ситанксисом возникнуть не должно.
На О5 производим полностью симметричную манипуляцию, меняя только адрес на 10.0.10.2. После чего "линк" до 10.0.10.2 поднимается.
Теперь О8 должен стать обычным OSPF маршрутизатором со всеми нужными маршрутами.
Authentication
Последнее о чем стоит поговорить в этой "заметке". Настроим md5 между О3 и О6. Делается это буквально в две команды. Естественно, все работает.
Читайте также: