Comments 11
Это опечатка или в квагге действительно смотрится вначале административаная дистанция а потом только длина префикса? Во всем сетевом оборудовании с которым я работал все в точности до наоборот — вначале сравнивается дина префика и выбирается более точный маршрут, если префиксы равны, то в дела вступает административная дистанция.
«В нашем случае в качестве Control Plane выступает Quagga, а в качестве Control Plane – ядро Linux» — поправьте опечатку пожалуйста
Интересно, зачем демоны bgpd, ospfd и пр. передают значение метрики демону zebra? По идее, выбор лучшего маршрута в рамках каждого протокола динамической маршрутизации должен осуществляться внутри соответствующего демона. Так как для каждого протокола вопрос выбора лучшего маршрута уникален (различные алгоритмы, метрики, правила борьбы с зацикливаними и пр.). А сравнивать метрики разных протоколов вообще бессмысленно. У того же BGP вместо метрики используется целый набор атрибутов.
В случае наличия маршрутов с одинаковой метрикой мы можем иметь балансировку трафика. А значит в таблице маршрутизации может быть несколько маршрутов от одного протокола.
маршрутов для одного префикса немного (не более одного для каждого протокола)
В случае наличия маршрутов с одинаковой метрикой мы можем иметь балансировку трафика. А значит в таблице маршрутизации может быть несколько маршрутов от одного протокола.
Лучший маршрут в рамках одного протокола действительно осуществляется внутри соответствующего демона. Но можно административную дистанцию (AD) у разных протоколов маршрутизации настроить так, что у них она будет совпадать. Тогда, чтобы хоть как-то сравнить такие маршруты от разных протоколов но с одинаковой AD используется метрика. Случаи из жизни, когда нужно было настраивать разные протоколы с одинаковой AD я не могу вспомнить, но, возможно, бывают и такие извращения.
> В случае наличия маршрутов с одинаковой метрикой мы можем иметь балансировку трафика. А значит в таблице маршрутизации может быть несколько маршрутов от одного протокола.
Возможно, Вы действительно правы. По идее, это зависит от конкретных демонов (ospfd, bgpd), будут ли они слать в zebra несколько маршрутов с одинаковой метрикой но с разными next-hop, с ними я еще не разбирался.
Другой вопрос, будет ли zebra все эти маршруты посылать в linux для балансировки трафика. Мне казалось, что она посылает только один из них. В общем, нужно будет с ECMP разобраться повнимательнее, постараюсь посмотреть как оно реализовано.
> В случае наличия маршрутов с одинаковой метрикой мы можем иметь балансировку трафика. А значит в таблице маршрутизации может быть несколько маршрутов от одного протокола.
Возможно, Вы действительно правы. По идее, это зависит от конкретных демонов (ospfd, bgpd), будут ли они слать в zebra несколько маршрутов с одинаковой метрикой но с разными next-hop, с ними я еще не разбирался.
Другой вопрос, будет ли zebra все эти маршруты посылать в linux для балансировки трафика. Мне казалось, что она посылает только один из них. В общем, нужно будет с ECMP разобраться повнимательнее, постараюсь посмотреть как оно реализовано.
Вот, к примеру, OSPF. ECMP вполне себе работает:
$ vtysh -c «show ip route 172.16.163.12/30»
Routing entry for 172.16.163.12/30
Known via «ospf», distance 110, metric 20, best
Last update 04:52:00 ago
* 172.16.172.77, via eth2.700
* 172.16.172.90, via eth2.700
$ ip route list 172.16.163.12/30
172.16.163.12/30 proto zebra metric 20
nexthop via 172.16.172.77 dev eth2.700 weight 1
nexthop via 172.16.172.90 dev eth2.700 weight 1
$ vtysh -c «show ip route 172.16.163.12/30»
Routing entry for 172.16.163.12/30
Known via «ospf», distance 110, metric 20, best
Last update 04:52:00 ago
* 172.16.172.77, via eth2.700
* 172.16.172.90, via eth2.700
$ ip route list 172.16.163.12/30
172.16.163.12/30 proto zebra metric 20
nexthop via 172.16.172.77 dev eth2.700 weight 1
nexthop via 172.16.172.90 dev eth2.700 weight 1
Вроде бы разобрался.
В том, что я называл маршрутной информацией (т.е. структуре, где хранится тип протокола, метрика, 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 и т.д., в 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 для одного префикса. Поэтому убрал из текста "(не более одного для каждого протокола)"
На оборудовании Cisco, если AD совпадает для разных протоколов, выберется только тот, который является более приоритетным для AD по умолчанию. Предположу, что в Quagga реализация будет аналогичной, так как сравнивать разные типы метрик, не самая удачная идея.
Возможно, передавать значение метрики демону zebra нужно в информационных целях. Чтобы администратор видел всю картину.
Возможно, передавать значение метрики демону zebra нужно в информационных целях. Чтобы администратор видел всю картину.
> В нашем случае в качестве Control Plane выступает Quagga, а в качестве Control Plane – ядро Linux.
Опечатка
Опечатка
Sign up to leave a comment.
Таблица маршрутизации в Quagga