CentOS 7
This document describes installation from source. If you want to build an RPM, see Packaging Red Hat .
CentOS 7 restrictions:
- MPLS is not supported on CentOS 7 with default kernel. MPLS requires Linux Kernel 4.5 or higher (LDP can be built, but may have limited use without MPLS)
Install required packages
sudo yum install git autoconf automake libtool make \ readline-devel texinfo net-snmp-devel groff pkgconfig \ json-c-devel pam-devel bison flex pytest c-ares-devel \ python-devel python-sphinx libcap-devel \ elfutils-libelf-devel libunwind-devel
The libunwind library is optional but highly recommended, as it improves backtraces printed for crashes and debugging. However, if it is not available for some reason, it can simply be left out without any loss of functionality.
FRR depends on the relatively new libyang library to provide YANG/NETCONF support. Unfortunately, most distributions do not yet offer a libyang package from their repositories. Therefore we offer two options to install this library.
Option 1: Binary Install
The FRR project builds some binary libyang packages.
RPM packages are at our RPM repository.
DEB packages are available as CI artifacts here.
libyang version 2.0.0 or newer is required to build FRR.
The libyang development packages need to be installed in addition to the libyang core package in order to build FRR successfully. Make sure to download and install those from the link above alongside the binary packages.
Depending on your platform, you may also need to install the PCRE development package. Typically this is libpcre2-dev or pcre2-devel .
Option 2: Source Install
Ensure that the libyang build requirements are met before continuing. Usually this entails installing cmake and libpcre2-dev or pcre2-devel .
git clone https://github.com/CESNET/libyang.git cd libyang git checkout v2.0.0 mkdir build; cd build cmake -D CMAKE_INSTALL_PREFIX:PATH=/usr \ -D CMAKE_BUILD_TYPE:String="Release" .. make sudo make install
Get FRR, compile it and install it (from Git)
This assumes you want to build and install FRR from source and not using any packages
Add frr groups and user
sudo groupadd -g 92 frr sudo groupadd -r -g 85 frrvty sudo useradd -u 92 -g 92 -M -r -G frrvty -s /sbin/nologin \ -c "FRR FRRouting suite" -d /var/run/frr frr
Download Source, configure and compile it
(You may prefer different options on configure statement. These are just an example.)
git clone https://github.com/frrouting/frr.git frr cd frr ./bootstrap.sh ./configure \ --bindir=/usr/bin \ --sbindir=/usr/lib/frr \ --sysconfdir=/etc/frr \ --libdir=/usr/lib/frr \ --libexecdir=/usr/lib/frr \ --localstatedir=/var/run/frr \ --with-moduledir=/usr/lib/frr/modules \ --enable-snmp=agentx \ --enable-multipath=64 \ --enable-user=frr \ --enable-group=frr \ --enable-vty-group=frrvty \ --disable-ldpd \ --enable-fpm \ --with-pkg-git-version \ --with-pkg-extra-version=-MyOwnFRRVersion \ SPHINXBUILD=/usr/bin/sphinx-build make make check sudo make install
Create empty FRR configuration files
sudo mkdir /var/log/frr sudo mkdir /etc/frr sudo touch /etc/frr/zebra.conf sudo touch /etc/frr/bgpd.conf sudo touch /etc/frr/ospfd.conf sudo touch /etc/frr/ospf6d.conf sudo touch /etc/frr/isisd.conf sudo touch /etc/frr/ripd.conf sudo touch /etc/frr/ripngd.conf sudo touch /etc/frr/pimd.conf sudo touch /etc/frr/nhrpd.conf sudo touch /etc/frr/eigrpd.conf sudo touch /etc/frr/babeld.conf sudo chown -R frr:frr /etc/frr/ sudo touch /etc/frr/vtysh.conf sudo chown frr:frrvty /etc/frr/vtysh.conf sudo chmod 640 /etc/frr/*.conf
Install daemon config file
sudo install -p -m 644 tools/etc/frr/daemons /etc/frr/ sudo chown frr:frr /etc/frr/daemons
Edit /etc/frr/daemons as needed to select the required daemons
Look for the section with watchfrr_enable=. and zebra=. etc. Enable the daemons as required by changing the value to yes
Enable IP & IPv6 forwarding
Create a new file /etc/sysctl.d/90-routing-sysctl.conf with the following content:
# Sysctl for routing # # Routing: We need to forward packets net.ipv4.conf.all.forwarding=1 net.ipv6.conf.all.forwarding=1
Load the modified sysctl’s on the system:
sudo sysctl -p /etc/sysctl.d/90-routing-sysctl.conf
Install frr Service
sudo install -p -m 644 tools/frr.service /usr/lib/systemd/system/frr.service
Register the systemd files
sudo systemctl preset frr.service
Enable required frr at startup
sudo systemctl enable frr
Reboot or start FRR manually
sudo systemctl start frr
Динамическая маршрутизация на основе FRRouting
Меня зовут Евгений, я занимаюсь развитием сетевой инфраструктуры в Домклик. Сегодняшняя статья будет охватывать только применение динамической маршрутизации на основе FRRouting (FRR), но, возможно, в будущем я напишу продолжение о том, как конфигурировать другое оборудование, которое вы встретите в тексте.
Задача
Понадобилось мне создать сетевую связность между двумя локациями, но так вышло, что по техническим причинам использовать для этого протоколы семейства IGP (например, всеми любимый OSPF) не представлялось возможным, а вот применить BGP оказалось вполне реально. Из вводных у меня на одной локации имеется два маршрутизатора Juniper MX204, а на второй — среда виртуализации.
Выбор решения
Начал я с изучения интернета и некоторой документации, что, в итоге, привело меня к решению использовать связку из двух виртуальных машин OPNsense с пакетом FRR на борту. Выбор был обусловлен тем, что я получаю знакомый мне межсетевой экран на границе периметра, с которым у меня уже сложились отношения, и возможность в один клик получить динамическую маршрутизацию благодаря простой установке плагина. Ещё одним преимуществом решения послужила отличная возможность поближе познакомиться с FRR на реальной задаче.
OPNsense — это open-source дистрибутив на основе FreeBSD, который из коробки имеет всё необходимое, чтобы стать защитником вашего периметра, включая механизм репликации тех кусков конфигурации, что вы сами выберите. Также он имеет удобный механизм установки дополнительных плагинов (коих много), включая FRR, Bind, Proxy, WireGuard и т.д.
FRRouting — это программный пакет, который на текущий момент позволяет реализовать работу таких протоколов, как OSPF, IS-IS, EIGRP, RIP, PBR, VRRP и т.д. на всех современных *NIX-системах, включая Linux и BSD. Для конфигурирования используется набор Cisco-like команд, что удобно специалистам вроде меня. Иными словами, это очень мощный инструмент с большим набором возможностей, но, конечно, есть и различные ограничения, которые зависят от операционной системы и используемого ею ядра. Исходя из этого рекомендую перед применением погрузиться в документацию. Для примера могу сказать, что мои эксперименты с VRRP на Centos 7 с FRR не принесли ожидаемых результатов, и в этом случае пакет keepalived даёт больше гибкости.
Архитектура
В локации №1 расположены два Juniper MX204, и мы будем считать, что у них уже настроено по одной eBGP-сессии до транспортного уровня и одна iBGP-сессия между ними. Такая конфигурация обеспечивает мне отказоустойчивость.
В локации №2 расположена среда виртуализации, в которой поднято две виртуальные машины с OPNsense на борту. У каждой из них будет по две eBGP-сессии до транспортной инфраструктуры и вообще не будет iBGP. Такое решение связано с моим желанием использовать классическую для межсетевых экранов схему работы кластера: active-passive. Я не планирую прокачивать через эти виртуальные машины большое количество данных, и схема active-active мне тут попросту не нужна.
Локации будут обмениваться трафиком через транспортную инфраструктуру, маршрутизаторы которой просто пересылают между собой анонсы, полученные по BGP от локаций.
Я знаю, что есть много разных способов организовать сетевую связность, например можно было поднять VPN и гонять какой-нибудь OSPF внутри него, но в моём случае выбранная архитектура обусловлена причинами, выходящими за рамки статьи.
Реализация
Берём за основу, что у нас уже установлено две виртуальные машины с OPNSense и настроены базовые параметры, такие как интерфейсы, статическая маршрутизация, правила Firewall, доступы, репликация конфигурации на резервную машину посредством HA и т.д.
На время отладки маршрутизации можно вовсе отключить функционал межсетевого экрана, чтобы ничего не препятствовало движению трафика, правда, вместе с этим отключится и NAT. Для этого надо в Firewall -> Settings -> Advanced поставить галочку «Disable all packet filtering».
Начнём с установки плагина FRR на наши OPNSense, для этого перейдём в System -> Firmware -> Plugins и в строке поиска напишем frr.
Чтобы после установки плагина его можно было начать конфигурировать, необходимо разлогиниться из системы и залогиниться обратно.
После успешной установки плагина переходим в Routing -> General и включаем FRR, здесь же включаем «Enable CARP Failover». Эта функция позволяет на основании состояния виртуального IP-адреса выключать сервис FRR на резервной машине. Для этого необходимо создать конфигурацию виртуального IP-адреса. Перейдём в Interfaces -> Virtual IPs -> Settings и создадим новый виртуальный IP-адрес через значок плюсика.
Думаю, что описывать каждое поле смысла нет, но хочу заострить внимание на паре моментов:
- Mode: нужен CARP.
- Advertising Frequency состоит из двух значений: Base и Skew. Первое отвечает за частоту обновлений в секунду, а второе — за приоритет, при этом меньшее значение приоритетнее большего, что противоположно VRRP.
После сохранения конфигурации её можно реплицировать на резервную машину по HA, и на ней значение Skew будет автоматически больше, то есть менее приоритетным.
Возвращаемся в Routing и приступаем к настройке протокола BGP. Первым делом включим протокол и зададим базовые значения:
- BGP AS Number: номер нашей автономной системы.
- Network: список подсетей, которые мы хотим анонсировать.
Во вкладке Neighbors настраиваются параметры установления соседства с другим маршрутизатором, в моём случае это eBGP-соседи, расположенные на границе транспортной инфраструктуры. Из обязательного тут нужно настроить IP-адреса соседей и их AS-номера, всё остальное по желанию и зависит от конкретных условий и потребностей.
Например, может понадобиться параметр Multi-Hop, когда сосед находится не в одной с вами подсети, или параметр Next-Hop-Self, когда вы хотите в передаваемых анонсах по iBGP менять значение next-hop на адрес локального маршрутизатора (в eBGP этот параметр работает по умолчанию).
Базовая конфигурация меня не устраивает и я хочу её изменить. Первым делом мне нужно выставлять собственный Local preference для получаемых по BGP префиксов. Для настройки этого параметра переходим во вкладку Route Maps и нажимаем плюсик рядом с кнопкой Reload Service. В открывшемся окне задаём уникальное название в поле Name, пусть будет RM-local-pref-150, уникальный номер в ID, выполняемое действие при срабатывании в Action, и вводим команду local-preference 150 в поле Set. Таким образом я буду указывать своему OPNSense, в какой из двух каналов отправлять трафик: чем выше значение, тем приоритетнее.
Значение по умолчанию у Local preference зачастую равно 100, но в FRR оно равно 0.
Вторая кастомизация — это сообщить маршрутизатору в транспортной инфраструктуре увеличенный атрибут AS-Path , чтобы он понимал, какой канал я считаю приоритетным для приёма от него трафика. Для этого создадим ещё один Route map с названием RM-as-path и другим ID, а в поле Set укажем as-path prepend 65010 65010 . Атрибут AS-Path указывает на количество автономных систем, которые придётся пройти трафику, соответственно, чем он короче, тем приоритетнее.
Конечно, этот атрибут будет иметь значение только в том случае, если соседский маршрутизатор не выставил у себя локально значения Weight или Local preference таким образом, чтобы канал, в котором мы увеличили путь, всё равно для него являлся приоритетным, так как при выборе лучшего пути атрибут AS-Path учитывается не в первую очередь.
Последнее изменение — установка списка префиксов, которые я буду принимать по BGP, чтобы только они могли попасть в таблицу маршрутизации. Для этого перейдём во вкладку Prefix Lists и создадим новый с названием PF-IN.
Если требуется описать несколько подсетей для одного списка префиксов, то для каждой настройки должно быть неизменно поле Name, а значение в Number должно быть уникальным, оно выступает тут в роли порядкового номера. Ниже представлен пример, как описать несколько подсетей в рамках одно списка префиксов.
Все изменения готовы и теперь их надо добавить в настройки соседства. Для этого вернёмся на вкладку Neighbors и сделаем так:
- В Route Map inbound добавляем RM-local-pref-150 , так как мы регулируем входящие анонсы.
- В Route Map outbound добавляем RM-as-path для того канала, который хотим сделать резервным, эту информацию получит маршрутизатор на границе транспортной инфраструктуры.
- В Prefix List inbound добавляем PF-IN , так как мы фильтруем входящие из анонсов префиксы.
Итоговая конфигурация для eBGP-соседств будет выглядеть так:
По завершении настройки в любой из вкладок находим Reload Service и тем самым перезапускаем сервис FRR, чтобы наша конфигурация применилась и начала работать. Есть возможность увидеть итоговую конфигурацию в формате набора Cisco-like команд, для этого переходим в Routing -> Diagnostics -> General и идём во вкладку Running Configuration. В ходе экспериментов мне это помогло понять, как применяется та или иная настройка.
Результат
Если перейти в Routing -> Diagnostics -> BGP и выбрать вкладку IPv4 Routing Table, то можно посмотреть, какие подсети мы получили и добавили в таблицу маршрутизации.
В других вкладках можно найти массу полезной информации о всём, что связано работой BGP.
В рамках этой статьи я не описывал конфигурацию Juniper, возможно, сделаю по этой теме отдельную статью, а пока предлагаю убедиться, что передаваемые подсети в анонсах FRR успешно достигают Juniper.
За сим откланиваюсь и желаю тебе, дорогой читатель, хорошего настроения!
Introduction
So I had this idea when looking at FRRouting. As it’s a Linux package, you can install it on a box running KVM/Libvirt, then you can enable BGP and redistribute the connected networks. This makes spinning up new virtual networks on the hypervisor very easy as you do not need to rely on static routes and as soon as you spin up a new virtual network it’s advertising to the rest of your network.
What is FRRouting (FRR)
FRRouting (FRR) is a fork of Quagga. It’s used in Cumulus networks OS as the routing suite.
This guide is based on an install of CentOS 7.5.
Step 1 Install FRR
Install the latest FRR rpm from https://github.com/FRRouting/frr/releases.
yum install -y https://github.com/FRRouting/frr/releases/download/frr-5.0.1/frr-5.0.1-2018070501.el7.centos.x86_64.rpm
Edit the daemons file and change the routing protocols you want from no to yes (you must always enable zebra) in this case zebra and bgpd.
vi /etc/frr/daemons
Start FRR and set to start on boot.
systemctl enable frr && systemctl start frr
Check status of FRR — should show as active (running).
systemctl status frr
Step 2 configure FRR and BGP
open the FRR shell by typing the command.
vtysh
Enter configuration mode.
This step is optional this command puts all the FRR configuration into one file.
service integrated-vtysh-config
Configure BGP on the KVM host.
I am configuring a route-map used to prevent some routes from being redistributed also will tag a BGP community for all the permitted routes you do not need to do this but it gives you more control and tagging the route helps with visibility.
ip prefix-list PL_BGP_DENY_CONNECTED seq 5 permit 10.25.10.0/24
route-map RM_BGP_REDISTRIBUTED_CONNECTED deny 10
match ip address prefix-list PL_BGP_DENY_CONNECTED
route-map RM_BGP_REDISTRIBUTED_CONNECTED permit 9999
set community 65010:10100
Here we are configuring the BGP process AS/router id/tuning the timers from the default to 2/6 and configuring the neighbour.
router bgp 65010
bgp router-id 10.25.10.100
bgp log-neighbor-changes
timers bgp 2 6
neighbor 10.25.10.1 remote-as 65000
Now to configure the redistribute connected command and set the route map we have created.
address-family ipv4 unicast
redistribute connected route-map RM_BGP_REDISTRIBUTED_CONNECTED
exit-address-family
Exit and save the configuration.
Step 3 Verify BGP is up and that we have routes
Here we can see that the BGP session is up.
Below we can see that have two connected virtual networks in BGP and are receiving a default route from the router we are connected to.
Building a Networking Virtual Lab part 3: Install Vagrant on CentOS 7
Introduction This is part three of Building a Networking Virtual Lab. Vagrant can be used to build a virtual lab on top of KVM/Libvirt. Step 1 Vagrant CentOS packages to install Install the latest Vagrant rpm from https://releases.hashicorp.com/vagrant/. yum install -y https://releases.hashicorp.com/
Feb 26, 2018 1 min read
Building a Networking Virtual Lab part 2: Install VNC with XFCE on CentOS 7
Introduction This is part two of Building a Networking Virtual Lab. VNC can be used to manage your Hypervisor via the Virtual Machine Manager GUI. Step 1 Install VNC/XFCE CentOS packages yum install epel-release –y yum groupinstall xfce -y yum install tigervnc-server -y yum -y groupinstall X11 -y Step
Feb 26, 2018 1 min read
Building a Networking Virtual Lab part 1: Install KVM/Libvirt on CentOS 7
Introduction I have split this guide into three parts. Part one deals with installing KVM/Libvirt. Part two installs VNC to connect to your remote host to use Virtual Machine Manager (VMM), Useful if you are accessing the hypervisor via a Windows or Mac computer, Linux has an installable version
frr (FRRouting)
BGP/OSPFv2/OSPFv3/ISIS/RIP/RIPng/PIM routing daemon FRRouting (FRR) is free software which manages TCP/IP based routing protocols. It supports BGP4, BGP4+, OSPFv2, OSPFv3, IS-IS, RIPv1, RIPv2, RIPng, PIM, LDP, EIGRP, Babel, BFD, Policy Routing, as well as the IPv6 versions of these. FRRouting (frr) is a fork of Quagga.
Details for frr (FRRouting)
License
- GPL-2.0+
Last updated
- 14 January 2023 — latest/stable
- 14 January 2023 — latest/stable