[landy]

Есть два роутера (CentOS), каждый подключен к отдельному провайдеру и считает его шлюзом по умолчанию. Между роутерами есть iBGP, между каждым роутером и его провайдером есть eBGP. Есть отдельная сеть /24 на роль DMZ. Дал каждому роутеру по интерфейсу в эту сеть, на них поднял vrrp (через keepalived), роутер 1 выдаёт себя за шлюз, роутер 2 его страхует. При таком раскладе весь трафик из DMZ уходит через роутер 1, пока он жив. Если роутер 1 внезапно погибает, роутер 2 подхватывает роль шлюза dmz, а интернет узнаёт о переменах через bgp. Работает, годится.

Есть одно "но" - если у роутера 1 по какой-то причине теряется связь с dmz, сам он анонсировать себя по bgp как маршрут к dmz не перестаёт. При таком раскладе трафик из dmz выходит через роутер 2, а возвращается через роутер 1, где благополучно дохнет.

Вопрос - как следует разбираться с такой ситуацией? Есть какие-то решения на уровне дизайна, кроме хитрой системы скриптовых костылей?

[Liner's]

всё очень просто, питание на роутер 1 надо подать через диодный мост на микротике (220В), на нём поставить ватчдог на роутер 1, как только пропадает пинг на него, микротик выключает poe на диод и гасит роутер1 по питанию до прихода экстренных служб

[NiTr0]

Железяка в DMZ которая собссно и анонсирует маршруты в BGP? LACP (для уменьшения вероятности отказа)?

[landy]

всё очень просто, питание на роутер 1 надо подать через диодный мост на микротике (220В), на нём поставить ватчдог на роутер 1, как только пропадает пинг на него, микротик выключает poe на диод и гасит роутер1 по питанию до прихода экстренных служб

Бомба :D у меня были мысли через хитрые каналы скриптами довыключать, но вот так прямо по питанию...

Если серьезно, то решение выглядит очень драконовским, хотя проблему решает.

 

 

Железяка в DMZ которая собссно и анонсирует маршруты в BGP? LACP (для уменьшения вероятности отказа)?

Можно поподробнее идею про железку в dmz? Перетащить ebgp к провайдерам на отдельную железку, живущую внутри dmz?

[Ivan Rostovikov]

Роутер 1 должен анонсировать /24 (DMZ) по данным от какого-либо динамического протокола. Если у роутера 1 пропадет связность с подсетью /24 то динамический протокол (например OSPF) позволит Роутеру1 узнать об этом и тот прекратит анонсировать ее в BGP.

В принципе аналогичное справедливо и для Роутера2

[rdntw]

Есть одно "но" - если у роутера 1 по какой-то причине теряется связь с dmz, сам он анонсировать себя по bgp как маршрут к dmz не перестаёт. При таком раскладе трафик из dmz выходит через роутер 2, а возвращается через роутер 1, где благополучно дохнет.

 

анонсить сеть DMZ как connected.

грубо говоря пока линк в UP то анонс уходит, ушел в down, анонса нет)

[Night_Snake]

Роутер 1 должен анонсировать /24 (DMZ) по данным от какого-либо динамического протокола. Если у роутера 1 пропадет связность с подсетью /24 то динамический протокол (например OSPF) позволит Роутеру1 узнать об этом и тот прекратит анонсировать ее в BGP.

В принципе аналогичное справедливо и для Роутера2

два чая этому господину

[sol]

анонсить сеть DMZ как connected.

грубо говоря пока линк в UP то анонс уходит, ушел в down, анонса нет)

Не полностью решает проблему. Линк может быть, а связи при этом может не быть. Медиаконвертор завис.

[alibek]

BFD

[landy]

1. Анонсировать DMZ как connected - не вариант, об этом уже упомянули.
   
2. BFD - помогло бы ускорить обсыхание BGP, но мне по сути надо рвать подключение eBGP при разрыве сессии iBGP. Мимо.
   
3. Анонсировать DMZ от третьего лица. Предположим между роутерами 1-2 и DMZ я ставлю роутеры 3 и 4 (чтобы иметь резервный шлюз из DMZ), через которые кручу DMZ. 3 и 4 дружу по какому-нибудь протоколу с 1 и 2. Пусть это будет ospf, между 1-2-3-4 один VLAN, все динамично друг с другом дружатся. На 1 и 2 редистрибуцию из ospf, играться с метриками... На бумаге выглядит реализуемым, но громоздким.
   
4. Своя идея - на роутере 1 запускать раз в 5 секунд пинговалку до 2 через dmz-интерфейс. Если связность пропала, скриптом рвать ebgp с провайдером (вариант - убирать dmz из анонсов). 2 подхватывает шлюз, по ebgp всем всё рассказывает, наступает идиллия до момента, пока 1 не вернётся в строй. Когда связность восстанавливается, роль шлюза возвращается на 1, а скрипт возвращает ebgp к исходному состоянию. Выглядит реализуемым, несложным, но попахивает колхозом :)
   

 

Всем спасибо за участие, будут ещё комментарии и предложения?

PS. Три сообщения в сутки - это сильно.

[ollsanek]

[*]Анонсировать DMZ от третьего лица. Предположим между роутерами 1-2 и DMZ я ставлю роутеры 3 и 4 (чтобы иметь резервный шлюз из DMZ), через которые кручу DMZ. 3 и 4 дружу по какому-нибудь протоколу с 1 и 2. Пусть это будет ospf, между 1-2-3-4 один VLAN, все динамично друг с другом дружатся. На 1 и 2 редистрибуцию из ospf, играться с метриками... На бумаге выглядит реализуемым, но громоздким.

 

3/4 ставьте просто в ДМЗ, не надо "между", и "дружите" их с 1/2 по iBGP,

потом на 3/4 делаете редистрибъют коннектед, на 1/2 - не делаете.

тогда если 2 видит 3/4, то отдаёт провайдеру маршруты, если не видит, то не отдаёт.

 

[*]Своя идея - на роутере 1 запускать раз в 5 секунд пинговалку до 2 через dmz-интерфейс. Если связность пропала, скриптом рвать ebgp с провайдером (вариант - убирать dmz из анонсов). 2 подхватывает шлюз, по ebgp всем всё рассказывает, наступает идиллия до момента, пока 1 не вернётся в строй. Когда связность восстанавливается, роль шлюза возвращается на 1, а скрипт возвращает ebgp к исходному состоянию. Выглядит реализуемым, несложным, но попахивает колхозом :)

если работает правильно, коментарии в коде/конфигах есть и в вики всё задокументировано, то это фантомные ароматы.

Изменено 21 октября, 2015 пользователем ollsanek

[NiTr0]

Своя идея - на роутере 1 запускать раз в 5 секунд пинговалку до 2 через dmz-интерфейс. Если связность пропала, скриптом рвать ebgp с провайдером (вариант - убирать dmz из анонсов).

Упал шлюз 2. Связность пропала. Шлюз 1 - скукожился тоже. И?...

 

Если уж колхозить - я бы vrrp на всех ифейсах устроил, и запускал бы bgpd на одной из нод этого "кластера". Хотя все равно надо по-хорошему еще одна нода для кворума...

[landy]

Упал шлюз 2. Связность пропала. Шлюз 1 - скукожился тоже. И?...

 

Спасибо, дельное замечание.

 

3/4 ставьте просто в ДМЗ, не надо "между", и "дружите" их с 1/2 по iBGP,

потом на 3/4 делаете редистрибъют коннектед, на 1/2 - не делаете.

тогда если 2 видит 3/4, то отдаёт провайдеру маршруты, если не видит, то не отдаёт.

 

Сейчас погоняю такой вариант, отпишусь по результатам. В первом приближении завелось.

[landy]

Косяк нечаянно нагрянул. Если трафик порождается откуда-то из сетей резервного провайдера, то он очевидным образом идёт через роутер 2, а обратно через 1, т.е. рушится внутри.

Попробую добавить к схеме conntrackd...

[martini]

надо подать через диодный мост на микротике (220В), на нём поставить ватчдог на роутер 1, как только пропадает пинг на него, микротик выключает poe на диод и гасит роутер1 по питанию

 

Saab после прочтения в блаженстве )))

[NiTr0]

Косяк нечаянно нагрянул. Если трафик порождается откуда-то из сетей резервного провайдера, то он очевидным образом идёт через роутер 2, а обратно через 1, т.е. рушится внутри.

Попробую добавить к схеме conntrackd...

У вас что, нат? Если нет - то ниего не должно рушиться, и conntrackd не спасет. А если трафик криво ходит - смотрите rp_filter

[ollsanek]

Косяк нечаянно нагрянул. Если трафик порождается откуда-то из сетей резервного провайдера, то он очевидным образом идёт через роутер 2, а обратно через 1, т.е. рушится внутри.

Попробую добавить к схеме conntrackd...

У вас что, нат? Если нет - то ниего не должно рушиться, и conntrackd не спасет. А если трафик криво ходит - смотрите rp_filter

не, там скорее всего, просто стейтфул фаервол и конекты отлетают по таймауту, т.к. на "2" нет ответного трафика, а на "1" соединение не создано и пакеты вообще дропаются.

 

landy - пишите как получается.

[landy]

ollsanek

NiTr0

Всё оказалось проще - у провайдера были свои прихотливые настройки в плане доверия анонсам из интернета и от клиентов. Месяц мучал провайдера - получил перенастроенный local preference. Коммуните через него как-то своенравно ходили.

 

В принципе, схема действительно рабочая. Сейчас буду ловить тараканов в плане доступа изнутри - у меня тут своё тяжелое наследство. Возможно, по итогам даже рожу статью :)

[YuryD]

всё очень просто, питание на роутер 1 надо подать через диодный мост на микротике (220В), на нём поставить ватчдог на роутер 1, как только пропадает пинг на него, микротик выключает poe на диод и гасит роутер1 по питанию до прихода экстренных служб

Круть :) Вспомнились советские счпу, с их корзинами питания. Каждый источник имел предохранитель плавкий, тиристор в козу, и стабилитрон для контроля выхода. Как напряжение на выходе превышало номинал, открывался стабилитрон и открывал тиристор. Тиристор коротил выход источника и пережигал предохранитель :)

[vmoroz]

Круть :) Вспомнились советские счпу, с их корзинами питания. Каждый источник имел предохранитель плавкий, тиристор в козу, и стабилитрон для контроля выхода. Как напряжение на выходе превышало номинал, открывался стабилитрон и открывал тиристор. Тиристор коротил выход источника и пережигал предохранитель :)

что-там счпу...

на подстанциях 110кВ без выключателей! (называется мы придумали как экономить), защита трансформатора выполнена по классической схеме (газовая, диф, мтз и т.д.) вот только нет выключателя, а есть отделитель и короткозамыкатель, который принудительно создает замыкание на землю (одну из фаз принудительно заземляет) и находящиеся в несколько км питающий центр видя что на линии произошло КЗ, отключает ее на 6-8 сек. (за это время на подстанции где произошла авария должны отключится отделители), через 6-8 сек. линия включается по АПВ (автоматическое повторное включение), если отделители сработали, ура, если что-то пошло не так, включение на кз и линия отключается еще раз но уже без АПВ....а Вы говорите тиристор в козу...

Изменено 1 декабря, 2015 пользователем vmoroz