gruber Posted April 21, 2017 · Report post Недавно в соседней ветке - http://forum.nag.ru/forum/index.php?showtopic=128474&st=0 было обсуждение на тему 4-х значных ASN. А именно дает ли какие-либо преимущества использование 4-х значных номеров AS перед 5-ти и более значными? В rfc конечно все расписано - https://tools.ietf.org/html/rfc4271#section-9.1 и даже перевод есть - https://rfc2.ru/4271.rfc/print#p9.1 Но RFC есть RFC, а конкретная реализация BGP может вести себя немного иначе. Если честно, ну совсем не верил я в то что размер номера AS может как-то влиять на решение о выборе маршрута. Поэтому на досуге поднял несколько виртуалок из того что было под рукой и поэкспериментировал немного. Из этого эксперимента мы должны понять, влияет ли размер номера AS на выбор маршрута в BGP. А под рукой в этот раз оказался OpenBGPd из состава OpenBSD 6.1 Наша тестовая сеть представлена на рисунке. R1(AS10001) и R4(AS10002) - наши воображаемые клиенты подключенные к двум аплинкам R2 (AS1234) и R3 (AS49999) Сеть за R1 - 123.123.0.0/16 Сеть за R4 - 244.244.0.0/16 За маршрутами к этим двум сетям мы и будем наблюдать. R2 - Аплинк с коротким номером AS1234 R3 - Аплинк с длинным номером AS49999 Сценарий первый, когда у R2 номер ASN и router-id меньше чем у R3. Тут мы видим, что на R1 маршрут к сети 244.244/16 пролегает как и положено через R2 R1 # bgpctl sh rib flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin AI*> 123.123.0.0/16 0.0.0.0 100 0 i *> 222.222.0.0/16 1.1.1.2 100 0 1234 i *> 233.233.0.0/16 2.2.2.2 100 0 49999 i *> 244.244.0.0/16 1.1.1.2 100 0 1234 10002 i * 244.244.0.0/16 2.2.2.2 100 0 49999 10002 i # netstat -rn | grep 244 244.244/16 1.1.1.2 UG 0 0 - 48 em0 Так же и на R4 маршрут в сеть 123.123/16 лежит через R2 R4 # bgpctl sh rib flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin *> 123.123.0.0/16 4.4.4.2 100 0 1234 10001 i * 123.123.0.0/16 3.3.3.1 100 0 49999 10001 i *> 222.222.0.0/16 4.4.4.2 100 0 1234 i * 222.222.0.0/16 3.3.3.1 100 0 49999 10001 1234 i *> 233.233.0.0/16 3.3.3.1 100 0 49999 i * 233.233.0.0/16 4.4.4.2 100 0 1234 10001 49999 i AI*> 244.244.0.0/16 0.0.0.0 100 0 i # netstat -rn | grep 123 123.123/16 4.4.4.2 UG 0 0 - 48 em1 Сценарий второй, когда у R2 номер ASN меньше, а router-id больше чем у R3. На R1 картина изменилась: # bgpctl sh rib flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin AI*> 123.123.0.0/16 0.0.0.0 100 0 i *> 222.222.0.0/16 1.1.1.2 100 0 1234 i *> 233.233.0.0/16 2.2.2.2 100 0 49999 i *> 244.244.0.0/16 2.2.2.2 100 0 49999 10002 i * 244.244.0.0/16 1.1.1.2 100 0 1234 10002 i # netstat -rn | grep 244 244.244/16 2.2.2.2 UG 0 0 - 48 em1 Так че как и на R4: # bgpctl sh rib flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin *> 123.123.0.0/16 3.3.3.1 100 0 49999 10001 i * 123.123.0.0/16 4.4.4.2 100 0 1234 10001 i *> 222.222.0.0/16 4.4.4.2 100 0 1234 i * 222.222.0.0/16 3.3.3.1 100 0 49999 10001 1234 i *> 233.233.0.0/16 3.3.3.1 100 0 49999 i * 233.233.0.0/16 4.4.4.2 100 0 1234 10001 49999 i AI*> 244.244.0.0/16 0.0.0.0 100 0 i # netstat -rn | grep 123 123.123/16 3.3.3.1 UG 0 0 - 48 em0 Теперь весь трафик между R1 и R4 бежит через R3, так как router-id меньше у R3. Сценарий третий, аномальный и в природе не встречается, когда router-id у двух пиров одинаковый. Большинство реализаций BGP в этом случае ругнутся примерно как cisco: %BGP-3-NOTIFICATION: sent to neighbor 10.0.0.1 2/3 (BGP identifier wrong) и BGP сессия не установится. Но, к примеру последний OpenBGPd, спокойно относится к этому, устанавливает сессию и прекрасно работает. Немного про router-id: В общем то нормальной практикой является назначение router-id руками, поэтому все нижеописанное актуально для небольшого процента конфигураций в которых админ не озаботился этим и оставил настройки RID дефолтными. Если RID = 0.0.0.0 то bgp-сессия не установится. Что у нас по дефолту в router-id (RID) для разных распространенных девайсов? Cisco: Если RID не был назначен административно, то он выбирается автоматически, в зависимости от настроек маршрутизатора, по таким правилам: Наибольший IP присвоенный активному loopback-у или наибольший IP из всех других активных интерфейсов. Если никакой из этих вариантов недоступен, и router-id не сконфигурирован вручную то будет 0.0.0.0. Juniper: Если RID не был назначен административно, то это будет IP первого поднявшегося интерфейса, как правило это loopback. Если никакой из этих вариантов недоступен, и router-id не сконфигурирован вручную то будет так же как в цыске 0.0.0.0 Mikrotik: По дефолту, если не назначен вручную стоит 0.0.0.0, или IP первого поднявшегося интерфейса. HP Procurve: Тут HP немного схитрили, и назначают наименьший IP присвоенный loopback-ам или VLAN-ам, но само собой можно и руками задать. OpenBGPd: Если не задан вручную, то берется наибольший IP на роутере. Bird: Наименьший адрес на не-loopback интерфейсе. Quagga: Толком не знаю, но подозреваю что также как на цыске. Что стало с нашими подопытным? Напомню что router-id на машинах R2 и R3 мы установили руками в одинаковые значения 255.255.0.1 На R1, выбран маршрут через R2 . R1 # bgpctl sh rib flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin AI*> 123.123.0.0/16 0.0.0.0 100 0 i *> 222.222.0.0/16 1.1.1.2 100 0 1234 i *> 233.233.0.0/16 2.2.2.2 100 0 49999 i *> 244.244.0.0/16 1.1.1.2 100 0 1234 10002 i * 244.244.0.0/16 2.2.2.2 100 0 49999 10002 i # netstat -rn | grep 244 244.244/16 1.1.1.2 UG 0 0 - 48 em0 Но вот R4 все равно выбирает путь через R3 R4 # bgpctl sh rib flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin *> 123.123.0.0/16 3.3.3.1 100 0 49999 10001 i * 123.123.0.0/16 4.4.4.2 100 0 1234 10001 i *> 222.222.0.0/16 4.4.4.2 100 0 1234 i * 222.222.0.0/16 3.3.3.1 100 0 49999 10001 1234 i *> 233.233.0.0/16 3.3.3.1 100 0 49999 i * 233.233.0.0/16 4.4.4.2 100 0 1234 10001 49999 i AI*> 244.244.0.0/16 0.0.0.0 100 0 i # netstat -rn | grep 123 123.123/16 3.3.3.1 UG 0 0 - 48 em0 Почему так происходит? Думаю что в данном случае BGP смотрит на IP адреса пиров, со стороны R1 выбирается пир с наименьшим IP - 1.1.1.2 - меньше чем 2.2.2.2, также как со стороны R4 выбирается пир с IP - 3.3.3.1 - меньше чем 4.4.4.2. Длина номера AS в данном случае никак не влияет на выбор маршрута. Проверим? Меняем местами только номера AS, теперь у нас R2 (AS49999) а R3 (AS1234) Напомню, что router-id у них по прежнему одинаковые - 255.255.0.1 Смотрим на R1 Маршрут проходит через R2 несмотря на то что номер AS у него теперь больше чем у R3 R1 # bgpctl sh rib flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin AI*> 123.123.0.0/16 0.0.0.0 100 0 i *> 222.222.0.0/16 1.1.1.2 100 0 49999 i *> 233.233.0.0/16 2.2.2.2 100 0 1234 i *> 244.244.0.0/16 1.1.1.2 100 0 49999 10002 i * 244.244.0.0/16 2.2.2.2 100 0 1234 10002 i # netstat -rn | grep 244 244.244/16 1.1.1.2 UG 0 0 - 48 em0 А на R4 маршрут проходит через R3 и это не из-за меньшего номера ASN, а из-за меньшего IP-адреса пира 3.3.3.1 меньше чем 4.4.4.2 R4 # bgpctl sh rib flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin *> 123.123.0.0/16 3.3.3.1 100 0 1234 10001 i * 123.123.0.0/16 4.4.4.2 100 0 49999 10001 i *> 222.222.0.0/16 4.4.4.2 100 0 49999 i * 222.222.0.0/16 3.3.3.1 100 0 1234 10001 49999 i *> 233.233.0.0/16 3.3.3.1 100 0 1234 i * 233.233.0.0/16 4.4.4.2 100 0 49999 10001 1234 i AI*> 244.244.0.0/16 0.0.0.0 100 0 i # netstat -rn | grep 123 123.123/16 3.3.3.1 UG 0 0 - 48 em0 Данный эксперимент показывает, что до выбора маршрута по номеру AS дело никогда не доходит, так что можно считать, что размер номера AS не влияет на выбор маршрута. Возможно другие реализации BGP ведут себя иначе, но мне не на чем сейчас проверить. Если у кого-то есть опыт, давайте обсудим. Всем спасибо. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
iValera Posted April 21, 2017 · Report post Просто у вас нет 4ех знака для продажи, вот вы и злитесь! ps: а если по делу отличная доказательная база. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
gruber Posted April 21, 2017 · Report post Просто у вас нет 4ех знака для продажи, вот вы и злитесь! ps: а если по делу отличная доказательная база. ггг ;)) Да я и не злюсь вовсе :) Если кто-то покупает, значит нужно, ради бога. Просто интересно узнать о практической пользе, может тоже купить захочется когда-нибудь. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
shvlad1 Posted April 21, 2017 · Report post Просто интересно узнать о практической пользе, может тоже купить захочется когда-нибудь. Думаю, при прочих равных (цена,...) клиент выберет того аплинка, у которого номер поменьше. Типа больше лет на рынке, опыта, экспертизы,.... Как то не вяжутся мастодонты-тиарваны с 32 битными асками. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
gruber Posted April 21, 2017 · Report post Да, согласен, это понятно…. Просто хотел удостовериться в том, что чисто технических преимуществ меньший номер AS не дает. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
v_r Posted April 21, 2017 · Report post У Cisco 10й пункт при выборе пути - сравнение времени получения префикса (для eBGP): When both paths are external, prefer the path that was received first (the oldest one). Router-id сравнивается позже, на 11 шаге. У OpenBGP такой же пункт. Вероятно в ваших тестах срабатывает этот фактор. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
v_r Posted April 21, 2017 · Report post Включите на OpenBGPD дебаг (если он там есть), процесс BGP должен писать почему префикс выбран лучшим. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
gruber Posted April 21, 2017 · Report post Возраст сессии в данном случае не влияет, пробовал дергать сессию на R2 и R3 для того чтобы возраст у них стал разный, это не меняет поведения. В OpenBGPd по умолчанию игнорируется возраст сессии: из man bgpd.conf rde route-age (ignore|evaluate) If set to evaluate, the best path selection will not only be based on the path attributes but also on the age of the route, giving preference to the older, typically more stable, route. In this case the decision process is no longer deterministic. The default is ignore. В циске как я понял, по дефолту возраст учитывается, если не установлен bgp best path compare-routerid ? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
