Современные сети, основанные на маршрутизации IP-пакетов, а точнее сервисы, которые они предоставляют, по факту управляются протоколом BGP. Этот протокол был спроектирован в конце 80-хх на трех салфетках. Да, с тех пор в этот протокол добавили массу возможностей, в том числе обмен маршрутной информацией VPN, правилами фильтрации трафика и всяким прочим полезным, но основа там осталась все той же, описанной на трех салфетках. И в этом есть свой плюс, потому что этот протокол в своей сути очень прост.
Но я хотел поговорить не о его простоте, а о "махании кулаками после драки", с которой частенько приходится сталкивать любой службе эксплуатации сети, или NOC - network operation centre (а может быть и center).
Поступает жалоба "а у меня вот сайт не открывается", или "вот час тому назад плохо работал сайт такой-то, а 5 минут тому назад он починился". Инженер идет на маршрутизатор и смотрит что маршрут к адресу рекомого сайта изменился 5 минут тому назад. И что с этим можно сделать? Чаще всего мало чего. Маршрутизатор знает, что вот такой маршрут "прилетел" 5 минут тому назад, а вот что было раньше? Может быть ничего существенного и не произошло, у маршрута обновились какие-нибудь информационные параметры, а пакеты как летели, так и летят в том же направлении. А может быть наоборот - маршрут изменился существенно и пакеты летят совсем в другом направлении. И узнать историю без дополнительного инструментария (или машины времени) нет возможности. И опять же - хорошо бы узнать, что же именно менялось. Да, есть глобальный инструмент bgplay. Но он рассчитан на использование в Интернете и запоминает изменения при перестроении маршрута между разными провайдерами. А вот изменения внутри сети одного провайдера он не ловит, да и не должен, так как не все то что происходит внутри автономной системы, должно быть видно снаружи.
И вот захотелось мне заиметь такой инструмент. Поиски готового ни к чему не привели (ни на что тут не претендую, может плохо искал). Соответственно, если нет готового решения - почему бы и не попробовать сделать самому? Все вроде понятно, собираем маршрутную информацию и храним историю изменений.
А вот дальше я подзавис. Самая лучшая библиотека, даже я бы сказал целый фреймворк, для обработки BGP - это пакет exabgp. Всем хорош и удобен. Один, на мой взгляд, существенный минус - он на python. Не то чтобы я был питононенавистником, отнюдь. Но каждый инструмент хорош, когда применяется по назначению. А python имеет всем известные особенности (интерпретатор, GIL), которые препятствуют эффективной обработке данных, если алгоритмы реализовывать именно на нем. И в данном случае мне хотелось бы иметь реализацию инструмента на компилируемом (как минимум) языке, с управляемыми политиками блокировок. А также иметь возможность выделить обработку протокола BGP в виде библиотеки и желательно чтобы применяемый язык мог позволить библиотеке жить без своего неотделимого и неотъемлемого рантайма (привет, golang!). Для чего? Ну, например, для того чтобы в перспективе применять эту библиотеку для других bgp-шных приложений. Ну и для скорости. Далеко не для всех видов запросов для поиска маршрутной информации возможно построить эффективный индекс.
Решил я попробовать в качестве основного языка по этой теме Rust и в общем все что хотел — получилось. Работу с протоколом BGP выделил в библиотеку. В отличие от exabgp реализовывать логику работы BGP FSM в библиотеке я не стал, по той простой причине что в Rust для сети используется не одно API, std там строго синхронное, а в реальных задачах лучше иметь возможность применять по желанию и потребности асинхронные библиотеки. Библиотеку разумеется назвал zettabgp, а приложение — bgpexplorer.
Принцип работы прост. Bgpexplorer может как выступать в роли bgp-спикера, то есть роутер (лучше всего route reflector) устанавливает с сервером bgp-соседство, и отдает в сторону сервера всю маршрутную информацию. Приложение накапливает в своей RIB (Routing Information Database) как актуальную маршрутную информацию, так и историческую. Для просмотра и поисковых запросов доступен веб-интерфейс. Сейчас все хранится в оперативной памяти и ее нужно достаточно много - в зависимости разумеется от того, какого объема таблицу маршрутизации нужно отслеживать.
Если интересно попробовать - то это просто. Нужна сеть, которую нужно мониторить и комп (сервер) с достаточно большим объемом ОЗУ чтобы маршрутная информация туда поместилась.
На сервере нужно взять исходники с гитхаба, предполагается что уже есть git и rust.
$ git clone https://github.com/wladwm/bgpexplorer
...
$ cd bgpexplorer
$ cargo build
...
Приложение собрано. Теперь на роутере настроим соседство с сервером.
Если это Cisco, то:
! Номер автономки тут 65535 разумеется для примера, как и адреса
router bgp 65535
! указываем адрес сервера с той же автономкой, чтобы сессия была IBGP
neighbor 10.1.1.1 remote-as 65535
! указываем с какого адреса соединяться
neighbor 10.1.1.1 update-source Loopback0
! будем ждать попыток соединения с сервера
neighbor 10.1.1.1 transport connection-mode passive
address-family ipv4
! для паблик инета активируем
neighbor 10.1.1.1 activate
! отправляем на сервер вообще все что есть
neighbor 10.1.1.1 route-reflector-client
! Активируем если нужно ipv4 labeled-unicast
neighbor 10.1.1.1 send-label
address-family vpnv4
! включаем VPNv4
neighbor 10.1.1.1 activate
neighbor 10.1.1.1 send-community extended
Возвращаемся на сервер и подготовим конфигурационный файл для приложения
$ cat > bgpexplorer.ini <<EOF
[main]
httplisten=0.0.0.0:8080
httproot=contrib
session=s0
whoisjsonconfig=whois.json
[s0]
mode=bmpactive
bgppeer=10.0.0.1
peeras=65535
EOF
В секции main указываем:
cargo run
После чего можно открыть браузер и направить его на адрес сервера с указанием порта.
На самом верху будет выбор RIB для просмотра - IPv4, IPv6, VPN разные всякие и т.п.
Далее строка для фильтра, а уже после нее - пейджинг и собственно маршрутная информация.
Неактивные маршруты будут отображены серым курсивом. У маршрутов, у которых есть история изменений будет кнопка разворачивания истории.
В фильтре можно задавать кроме собственно подсетей фильтрацию по community, aspath, nexthop, route-target, route-distinguisher.
При наведении курсора на ASn, адреса роутеров будет выполняться запрос к whois или DNS, и полученная информация будет отображаться в попапе. Иногда это долго, но бывает полезно.
Источник статьи: https://habr.com/ru/post/562218/
Но я хотел поговорить не о его простоте, а о "махании кулаками после драки", с которой частенько приходится сталкивать любой службе эксплуатации сети, или NOC - network operation centre (а может быть и center).
Поступает жалоба "а у меня вот сайт не открывается", или "вот час тому назад плохо работал сайт такой-то, а 5 минут тому назад он починился". Инженер идет на маршрутизатор и смотрит что маршрут к адресу рекомого сайта изменился 5 минут тому назад. И что с этим можно сделать? Чаще всего мало чего. Маршрутизатор знает, что вот такой маршрут "прилетел" 5 минут тому назад, а вот что было раньше? Может быть ничего существенного и не произошло, у маршрута обновились какие-нибудь информационные параметры, а пакеты как летели, так и летят в том же направлении. А может быть наоборот - маршрут изменился существенно и пакеты летят совсем в другом направлении. И узнать историю без дополнительного инструментария (или машины времени) нет возможности. И опять же - хорошо бы узнать, что же именно менялось. Да, есть глобальный инструмент bgplay. Но он рассчитан на использование в Интернете и запоминает изменения при перестроении маршрута между разными провайдерами. А вот изменения внутри сети одного провайдера он не ловит, да и не должен, так как не все то что происходит внутри автономной системы, должно быть видно снаружи.
И вот захотелось мне заиметь такой инструмент. Поиски готового ни к чему не привели (ни на что тут не претендую, может плохо искал). Соответственно, если нет готового решения - почему бы и не попробовать сделать самому? Все вроде понятно, собираем маршрутную информацию и храним историю изменений.
А вот дальше я подзавис. Самая лучшая библиотека, даже я бы сказал целый фреймворк, для обработки BGP - это пакет exabgp. Всем хорош и удобен. Один, на мой взгляд, существенный минус - он на python. Не то чтобы я был питононенавистником, отнюдь. Но каждый инструмент хорош, когда применяется по назначению. А python имеет всем известные особенности (интерпретатор, GIL), которые препятствуют эффективной обработке данных, если алгоритмы реализовывать именно на нем. И в данном случае мне хотелось бы иметь реализацию инструмента на компилируемом (как минимум) языке, с управляемыми политиками блокировок. А также иметь возможность выделить обработку протокола BGP в виде библиотеки и желательно чтобы применяемый язык мог позволить библиотеке жить без своего неотделимого и неотъемлемого рантайма (привет, golang!). Для чего? Ну, например, для того чтобы в перспективе применять эту библиотеку для других bgp-шных приложений. Ну и для скорости. Далеко не для всех видов запросов для поиска маршрутной информации возможно построить эффективный индекс.
Решил я попробовать в качестве основного языка по этой теме Rust и в общем все что хотел — получилось. Работу с протоколом BGP выделил в библиотеку. В отличие от exabgp реализовывать логику работы BGP FSM в библиотеке я не стал, по той простой причине что в Rust для сети используется не одно API, std там строго синхронное, а в реальных задачах лучше иметь возможность применять по желанию и потребности асинхронные библиотеки. Библиотеку разумеется назвал zettabgp, а приложение — bgpexplorer.
Принцип работы прост. Bgpexplorer может как выступать в роли bgp-спикера, то есть роутер (лучше всего route reflector) устанавливает с сервером bgp-соседство, и отдает в сторону сервера всю маршрутную информацию. Приложение накапливает в своей RIB (Routing Information Database) как актуальную маршрутную информацию, так и историческую. Для просмотра и поисковых запросов доступен веб-интерфейс. Сейчас все хранится в оперативной памяти и ее нужно достаточно много - в зависимости разумеется от того, какого объема таблицу маршрутизации нужно отслеживать.
Если интересно попробовать - то это просто. Нужна сеть, которую нужно мониторить и комп (сервер) с достаточно большим объемом ОЗУ чтобы маршрутная информация туда поместилась.
На сервере нужно взять исходники с гитхаба, предполагается что уже есть git и rust.
$ git clone https://github.com/wladwm/bgpexplorer
...
$ cd bgpexplorer
$ cargo build
...
Приложение собрано. Теперь на роутере настроим соседство с сервером.
Если это Cisco, то:
! Номер автономки тут 65535 разумеется для примера, как и адреса
router bgp 65535
! указываем адрес сервера с той же автономкой, чтобы сессия была IBGP
neighbor 10.1.1.1 remote-as 65535
! указываем с какого адреса соединяться
neighbor 10.1.1.1 update-source Loopback0
! будем ждать попыток соединения с сервера
neighbor 10.1.1.1 transport connection-mode passive
address-family ipv4
! для паблик инета активируем
neighbor 10.1.1.1 activate
! отправляем на сервер вообще все что есть
neighbor 10.1.1.1 route-reflector-client
! Активируем если нужно ipv4 labeled-unicast
neighbor 10.1.1.1 send-label
address-family vpnv4
! включаем VPNv4
neighbor 10.1.1.1 activate
neighbor 10.1.1.1 send-community extended
Возвращаемся на сервер и подготовим конфигурационный файл для приложения
$ cat > bgpexplorer.ini <<EOF
[main]
httplisten=0.0.0.0:8080
httproot=contrib
session=s0
whoisjsonconfig=whois.json
[s0]
mode=bmpactive
bgppeer=10.0.0.1
peeras=65535
EOF
В секции main указываем:
- httplisten — на каком адресе и порту будет работать протокол http
- httproot — где лежит корень файлового сервиса. Там лежит index.html и все такое прочее.
- Whoisjsonconfig указывает на файл конфигурации сервиса whois
- Session – это имя секции, описывающей режим работы bgp, в данном примере s0
- bgppeer — адрес роутера BGP для активного режима
- Peeras — номер автономной системы
- protolisten — адрес:порт, где ожидать входящего соединения по протоколу BGP или BMP
- Mode — варианты работы протокола
- bgppassive — ждать входящего подключения от роутера
- bgpactive — инициировать подключение к роутеру
- bmpactive — инициировать подключение к роутеру по протоколу BMP
- bmppassive — ждать входящего подключения от роутера по протоколу BMP
cargo run
После чего можно открыть браузер и направить его на адрес сервера с указанием порта.
На самом верху будет выбор RIB для просмотра - IPv4, IPv6, VPN разные всякие и т.п.
Далее строка для фильтра, а уже после нее - пейджинг и собственно маршрутная информация.
Неактивные маршруты будут отображены серым курсивом. У маршрутов, у которых есть история изменений будет кнопка разворачивания истории.
В фильтре можно задавать кроме собственно подсетей фильтрацию по community, aspath, nexthop, route-target, route-distinguisher.
При наведении курсора на ASn, адреса роутеров будет выполняться запрос к whois или DNS, и полученная информация будет отображаться в попапе. Иногда это долго, но бывает полезно.
Источник статьи: https://habr.com/ru/post/562218/