grifin.ru Posted February 23, 2017 · Report post Коллеги, помогите, бьюсь уже несколько часов. Распробовал BFD, поэтому перехожу с Quagga на Bird Не могу сделать одну вещь, которая в квагге делалась одной строчкой. Нужно проанонсировать BGP соседям маршрут, но в локальной таблице маршрутизации этот маршрута быть не должно в квагге просто пишешь natwork x.x.x.x/x и все как это сделать в bird ? Смотрел в торону export/import но на этой поляне решения не нашел. Маршруты прописываются у меня в протоколе static и они автоматически попадают в локальную таблицу маршрутизации, несмотря на export none; Я уже готов делать отдельную таблицу маршрутизации для этих маршрутов, но как-то это уж совсем через задницу.... Скажите как правильно ? Спасибо. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted February 23, 2017 · Report post В cisco это делается так: создаешь static route с AD 255, такие роуты можно анонсить, но они не попадают в локальную таблицу маршрутизации В bird не эксперт, но стал бы пробовать этот вариант. Вообще говоря, в этом случае должна возникнуть петля маршрутизации, если только трафик не блэкхолится или не роутится какими-то особыми способами, в обход RT Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NiTr0 Posted February 23, 2017 · Report post protocol kernel - ставите фильтры на экспорт (только RTS_BGP, без RTS_STATIC), протокол статик - прописываете мершрут, ну и протокол бгп - импорт всех, экспорт только выбранных. коротко логика птички: есть таблица(-ы) маршрутизации птички, и есть кучка протоколов, которые суть обмен между таблицей птички и второй точкой (будь то бгп клиент, оспф клиент или таблица маршрутизации ядра). import - то, что попадает из второй точки протокола в таблицу птички, export - то, что из таблицы птички утекает наружу. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
grifin.ru Posted February 23, 2017 · Report post NiTr0 Почему тогда если в Static поставить export none - маршруты все-равно оказываются в ядре ? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
grifin.ru Posted February 23, 2017 · Report post NiTr0 Так,к кажется понял. Сейчас попробую. Спасибо. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
grifin.ru Posted February 23, 2017 · Report post не влетает ( protocol kernel. { learn;<----><------><------># Learn all alien routes from the kernel persist;<--><------># Don't remove routes on bird shutdown scan time 20;<-----><------># Scan kernel routing table every 20 seconds import none;<------><------># Default is import all export filter. <------>{ <------>if source = RTS_STATIC then. <------> { <------> reject; <------> } <------>accept; <------>}; # export all;<------><------># Default is export none } Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
v_r Posted February 23, 2017 · Report post Зачем включен learn в kernel? У вас какие-то другие демоны маршрутизации работают помимо bird? У вас также включен persist, вы уверены что статический роут в системе находится потому что bird его только что добавил? Может он был добавлен во время начала экспериментов и больше не удалялся? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
grifin.ru Posted February 23, 2017 · Report post Я поменял запрет RTS_STATIC на разрешение RTS_BGP, RTS_OSPF И вроде все завелось, но теперь другая удивительная проблема BFD работает ЛИБО на OSFP, либо на BGP (на другой стороне CCR, интерфейс тот-же) Убираешь из OSFP протокола BFD ON; BGP заводится, и BFD тоже, включаешь BFD на OSPF - рвется BGP сессия и больше не поднимается, правда если отключить BFD на BGP то поднимается, но естественно без BFD Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
grifin.ru Posted February 24, 2017 · Report post v_r Два CCR'а, если что, нормально работают в таком-же режиме (BFD на OSPF + BGP) а тут - чудеса какие-то. Работает только один, причем OSPF - в приоритете Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
v_r Posted February 24, 2017 · Report post Детально с BFD на bird не разбирался так что не подскажу в чем причина, и на Микротике BFD одновременно для OSPF и BGP не приходилось включать. В связке bird-Cisco BFD нормально работает в вилане с OSPF и BGP-сессией построенной на интерфейсных адресах на линке c /30, причем работает одна BFD-сессия для обоих протоколов (как и должно быть), во всяком случае Cisco пишет что привязаны два протокола, в bird посмотреть такое нельзя. Кстати на линках где есть несколько пиров BFD на bird капризничал: в подсети /29 с несколькими BGP-маршрутизаторами Cisco и bird BFD между Cisco поднимается сразу, а между bird и Cisco бывало поначалу флапает и в течении минут 10-15 устаканивается. Помогло включение BFD echo mode со стороны Cisco. Можете попробовать в bird включить пассивный режим BFD, но это не осознанное решение а перебор возможных вариантов. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
v_r Posted February 24, 2017 · Report post Два CCR'а, если что, нормально работают в таком-же режиме (BFD на OSPF + BGP) И сколько BFD сессий поднято в таком режиме между CCR? BGP на интерфейсных адресах построен или с "лупбеков"? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NiTr0 Posted February 24, 2017 · Report post а зачем вам нужен оспф собссно? чем iBGP не устраивает? у вас несколько area, и нужно агрегировать маршруты что ли? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SUrov_IBM Posted February 24, 2017 · Report post а зачем вам нужен оспф собссно? чем iBGP не устраивает? у вас несколько area, и нужно агрегировать маршруты что ли? NiTr0, доброго Вам времени суток. Пожалуйста, подскажите (поделитесь опытом), если не требуется агрегации маршрутов, а требуется простое перестроение (для резервирования) внутри автономных VPN точка-точка соединений, Вы бы использовали iBGP? Просто мне казалось, что OSPF значительно быстрее детектирует изменение состояния канала? Идея использовать iBGP, вместо OSPF в простых переключениях мне самому давно нравиться, поскольку iBGP гибче настраивается. Очень хочется услышать Ваше мнение. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted February 24, 2017 · Report post SUrov_IBM Если вам нужно быстрое детектирование, то прикрутите к iBGP BFD. Вообще, классическая типовая схема это 2 RR и iBGP-сессии ко всем лупбэкам. Если вы откажитесь от ospf/isis внутри IS-IS и уйдёте на голый bgp, то вам надо будет собирать full-mesh или конфедерации Ну и если у вас MPLS, то собирать его без OSPF/IS-IS это отдельная история, лучше даже не пытаться это делать в классических сетях Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
zi_rus Posted February 24, 2017 · Report post В cisco это делается так: создаешь static route с AD 255, такие роуты можно анонсить, но они не попадают в локальную таблицу маршрутизации Шикарная вещь, применю как-нибудь, никогда не задумывался что так можно Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted February 24, 2017 · Report post В cisco это делается так: создаешь static route с AD 255, такие роуты можно анонсить, но они не попадают в локальную таблицу маршрутизации Шикарная вещь, применю как-нибудь, никогда не задумывался что так можно Да, но зачем? какой реальный юз-кейс для такой штуки? Проанонсить, а роутить всякими PBR-ами с явным заданием next-hop'а? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SUrov_IBM Posted February 24, 2017 (edited) · Report post SUrov_IBM Если вам нужно быстрое детектирование, то прикрутите к iBGP BFD. Вообще, классическая типовая схема это 2 RR и iBGP-сессии ко всем лупбэкам. Если вы откажитесь от ospf/isis внутри IS-IS и уйдёте на голый bgp, то вам надо будет собирать full-mesh или конфедерации Ну и если у вас MPLS, то собирать его без OSPF/IS-IS это отдельная история, лучше даже не пытаться это делать в классических сетях S.lobanov, доброго Вам времени суток. Если я правильно понимаю, то под «Full-Mesh» подразумевается «точка-точка» соединение каждого маршрутизатора с каждым (из-за особенности механизма предотвращения петель в iBGP)? Ничего страшного в таком количестве тоннелей (соединений), не вижу. Как по мне, так даже гибче настраивается анонс внутри-автономных маршрутов. У меня AS маленькая, можно сказать любительская, построенная на разном оборудовании, MPLS не используется, максимум - OpenVPN для L2 траффика. :) Edited February 24, 2017 by SUrov_IBM Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted February 24, 2017 · Report post SUrov_IBM А в ospf типа у вас петли чтоль появляются? вы только определитесь зачем вам такая гибкость. большинство нормальных кейсов и ospf-ом покрываются Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SUrov_IBM Posted February 24, 2017 · Report post SUrov_IBM А в ospf типа у вас петли чтоль появляются? вы только определитесь зачем вам такая гибкость. большинство нормальных кейсов и ospf-ом покрываются S.lobanov, доброго Вам времени суток. В моей маленькой системе вообще не бывает петель, независимо от протокола динамической маршрутизации. Просто давно была идея, отказаться от OSPF, поскольку у меня нет коммутаторов (и мелких узлов) участвующих в анонсе маршрутов по OSPF. Динамическая маршрутизация строится исключительно между пограничными (спикерами) и головным маршрутизатором. Протокол iBGP логически мне более понятен, при настройке фильтров маршрута. Просто мне всегда казалось, что OSPF более быстро реагирует, на изменение состояния канала. Вот теперь думаю, что стоит пересобрать схему с использованием iBGP. :) Было интересно услышать мнение, знающих телеком'овцев! Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
zhenya` Posted February 24, 2017 · Report post iBGP is the best IGP. Ржака. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SUrov_IBM Posted February 24, 2017 · Report post iBGP is the best IGP. Ржака. Zhenya`, доброго Вам времени суток. Простите, не понял Вас, это утверждение или наоборот указание на то, что я не правильно мыслю? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
grifin.ru Posted February 24, 2017 · Report post Раз уж пошел тут такой базар, в моем топике, то я тогда еще вопрос подкину. Когда OSPF маршрутизаторы имеют более одного пути между друг-другом и COST маршрута одинаковый, то начинается какая-то интересная балансировка ! пакеты летят то так, то так. Я испугался такого поведения и срочно изменил стоимость маршрутов, но очень хочется разобраться в этом. Возможно эту особенность можно поставить на службу мне ) Расскажите кто-нибудь как оно работает и кто эту возможность как использует ? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
v_r Posted February 24, 2017 · Report post При наличии нескольких маршрутов с одинаковой метрикой на сеть некоторые протоколы могут добавлять в таблицу маршрутизации больше одного маршрута, и если ОС/железо умеет и настроено использовать несколько маршрутов то трафик будет балансироваться. У многих протоколов есть тонкие настройки сколько одинаковых маршрутов добавлять и добавлять ли вообще, и у ОС/железа есть настройки балансировать ли трафик и каким способом, хотя сейчас большинство L3 устройств балансирует по потокам (per-flow, оптимальный вариант), может какие-то динозавры остались что не умеют такого и балансируют только по пакетам (per-packet, лучше вообще такое не использовать). Реализация на конкретных платформах сильно отличается: на Cisco OSPF сразу настроен на equal-cost multi-path load balancing а в BGP это надо включать, на Juniper при настройках по умолчанию OSPF может добавлять несколько маршрутов в RIB но в FIB попадает только один, и т.д. Quagga не умеет добавлять в таблицу маршрутизации несколько маршрутов, bird умеет, балансирует ли дальше ядро при настройках по умолчанию я не помню. В вашем случае стоит разобраться/почитать как работает балансировка на Linux/Mikrotik, нет ли жалоб, и если все ОК то пользуйтесь этим как вам удобно. Балансировку используют довольно часто, запустите traceroute на американские ресурсы и увидите что практически во всех случаях по пути будет несколько хопов с явными признаками балансировки (ответы от разных хостов на одном хопе), типа: 6 72.52.48.192 31.781 ms 72.52.48.200 31.683 ms 31.783 ms 7 72.52.48.197 30.750 ms 30.501 ms 72.52.48.205 30.694 ms 8 93.191.173.61 42.556 ms 93.191.173.18 40.572 ms 93.191.173.61 42.549 ms Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NiTr0 Posted February 25, 2017 · Report post Просто мне всегда казалось, что OSPF более быстро реагирует, на изменение состояния канала при смерти соседа (ушел в себя и не отвечает) - без bfd что одно, что другое долго перестраивается если не крутить тайм-ауты. при изменении маршрутов - что одно, что другое быстро анонсит новые маршруты. Когда OSPF маршрутизаторы имеют более одного пути между друг-другом и COST маршрута одинаковый, то начинается какая-то интересная балансировка ! ну да. если поддерживается демоном/ОС multihop - идет балансировка. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted February 25, 2017 · Report post SUrov_IBM А в ospf типа у вас петли чтоль появляются? вы только определитесь зачем вам такая гибкость. большинство нормальных кейсов и ospf-ом покрываются S.lobanov, доброго Вам времени суток. В моей маленькой системе вообще не бывает петель, независимо от протокола динамической маршрутизации. Просто давно была идея, отказаться от OSPF, поскольку у меня нет коммутаторов (и мелких узлов) участвующих в анонсе маршрутов по OSPF. Динамическая маршрутизация строится исключительно между пограничными (спикерами) и головным маршрутизатором. Протокол iBGP логически мне более понятен, при настройке фильтров маршрута. Просто мне всегда казалось, что OSPF более быстро реагирует, на изменение состояния канала. Вот теперь думаю, что стоит пересобрать схему с использованием iBGP. :) Было интересно услышать мнение, знающих телеком'овцев! iBGP часто используют когда надо анонсить много и часто, например типичная задача это принимать /32 маршруты от BRAS-ов на ASBR-е, потому что на некоторых железках OSPF может сильно нагрузить CPU Если у вас теоретический интерес, то лучше откройте CCNA/CCNP и изучайте что там умные люди написали. Если практический, то надо обсуждать конкретную сеть, с конкретными железками и что и куда и как часто анонсится Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
