Bgpd по функционалу и синтаксису CLI довольно сильно похож на Cisco. Поскольку bgpd работает по BGP и с другими маршрутизаторами, то, видимо, придерживается RFC.
BGP Scanner периодически (по-умолчанию раз в минуту) запускается внутри bgpd и работает следующим образом: последовательно проходится вся таблица BGP, для каждого префикса последовательно проходятся все его маршруты и из каждого маршрута берется его next-hop. Для каждого next-hop делается запрос в zebra, чтобы она его разрешила (в смысле, посмотрела, есть ли у нее маршрут до next-hop). В ответе от zebra содержится в том числе информация о валидности next-hop и IGP метрика до него, которые bgpd обновляет в таблице BGP. В конце запускается перерасчет выбора лучших маршрутов BGP и их рассылка соседям.
В zebra могут храниться рекурсивные next-hop у маршрутов от bgpd (с одним уровнем рекурсии). Т.е. например, у маршрута 10.0.0.1 хранится next-hop 1.1.1.1, а к этому next-hop еще «прикреплены» resolved next-hop, например, 2.2.2.2. В таблицу маршрутизации linux идет маршрут 10.0.0.1 c next-hop 2.2.2.2.
В том, что я называл маршрутной информацией (т.е. структуре, где хранится тип протокола, метрика, AD и т.д., в zebra данная структура называется rib) на самом деле может храниться не один next-hop, а несколько разных next-hop'ов (в виде связного списка). При этом если данная маршрутная информация выбирается лучшей, то в ядро linux (FIB) попадают все ее next-hop'ы (если они валидны). Получается, что лучшая маршрутная информация (rib) выбирается одна, но в ядро linux действительно может попасть несколько маршрутов, поскольку у rib может быть несколько next-hop'ов.
При выводе команды show ip route хорошо видно rib с несколькими next-hop. Например, в следующем примере для префикса 10.0.0.1/32 имеются два rib — один статический и другой ospf. При этом у ospf имеется два next-hop — 10.158.47.30 и 172.16.1.30.
При этом, как минимум, для статических маршрутов с разной AD действительно может быть несколько разных rib для одного префикса. Поэтому убрал из текста "(не более одного для каждого протокола)"
Лучший маршрут в рамках одного протокола действительно осуществляется внутри соответствующего демона. Но можно административную дистанцию (AD) у разных протоколов маршрутизации настроить так, что у них она будет совпадать. Тогда, чтобы хоть как-то сравнить такие маршруты от разных протоколов но с одинаковой AD используется метрика. Случаи из жизни, когда нужно было настраивать разные протоколы с одинаковой AD я не могу вспомнить, но, возможно, бывают и такие извращения.
> В случае наличия маршрутов с одинаковой метрикой мы можем иметь балансировку трафика. А значит в таблице маршрутизации может быть несколько маршрутов от одного протокола.
Возможно, Вы действительно правы. По идее, это зависит от конкретных демонов (ospfd, bgpd), будут ли они слать в zebra несколько маршрутов с одинаковой метрикой но с разными next-hop, с ними я еще не разбирался.
Другой вопрос, будет ли zebra все эти маршруты посылать в linux для балансировки трафика. Мне казалось, что она посылает только один из них. В общем, нужно будет с ECMP разобраться повнимательнее, постараюсь посмотреть как оно реализовано.
В zebra могут храниться рекурсивные next-hop у маршрутов от bgpd (с одним уровнем рекурсии). Т.е. например, у маршрута 10.0.0.1 хранится next-hop 1.1.1.1, а к этому next-hop еще «прикреплены» resolved next-hop, например, 2.2.2.2. В таблицу маршрутизации linux идет маршрут 10.0.0.1 c next-hop 2.2.2.2.
В том, что я называл маршрутной информацией (т.е. структуре, где хранится тип протокола, метрика, AD и т.д., в zebra данная структура называется rib) на самом деле может храниться не один next-hop, а несколько разных next-hop'ов (в виде связного списка). При этом если данная маршрутная информация выбирается лучшей, то в ядро linux (FIB) попадают все ее next-hop'ы (если они валидны). Получается, что лучшая маршрутная информация (rib) выбирается одна, но в ядро linux действительно может попасть несколько маршрутов, поскольку у rib может быть несколько next-hop'ов.
При выводе команды show ip route хорошо видно rib с несколькими next-hop. Например, в следующем примере для префикса 10.0.0.1/32 имеются два rib — один статический и другой ospf. При этом у ospf имеется два next-hop — 10.158.47.30 и 172.16.1.30.
При этом, как минимум, для статических маршрутов с разной AD действительно может быть несколько разных rib для одного префикса. Поэтому убрал из текста "(не более одного для каждого протокола)"
> В случае наличия маршрутов с одинаковой метрикой мы можем иметь балансировку трафика. А значит в таблице маршрутизации может быть несколько маршрутов от одного протокола.
Возможно, Вы действительно правы. По идее, это зависит от конкретных демонов (ospfd, bgpd), будут ли они слать в zebra несколько маршрутов с одинаковой метрикой но с разными next-hop, с ними я еще не разбирался.
Другой вопрос, будет ли zebra все эти маршруты посылать в linux для балансировки трафика. Мне казалось, что она посылает только один из них. В общем, нужно будет с ECMP разобраться повнимательнее, постараюсь посмотреть как оно реализовано.