Привет, незнакомец!

Похоже, вы здесь новенький. Чтобы принять участие, нажмите одну из кнопок ниже!

А как бы поступили Вы?

отредактировано июня 2016 Раздел: Best practice
Коллеги добрый день! Хочу поделиться с Вами своей статейкой, наброшенной вчера ночью для Хабра.
Скажу сразу, речь пойдет о костыльном решении. Поэтому и интересно как бы поступили Вы?
Рекомендую ознакомиться с первой статьей, написанной в декабре.
На исходной имеем сеть, состоящую из 12 магазинов, разбросанных по городу, и подключенных провайдером в единую VLAN.
В сети есть всего один управляемый коммутатор, размещенный в центральном офисе. Во всех магазинах стоят неуправляемые мыльницы.
Главный офис подключен по схеме Dual-Homed, то есть туда от провайдера заведено 2 линка, один - медиаконвертер, зависимый от ближайшей 5-ти этажки, второй gPON терминал (Huawei), 810e на обоих терминируется один и тот же vlan.
Свитч в офисе хоть и управляемый но в дефолте. Таблица fdb состоит из ~ 400 mac-ов.
В этом же влане, на стороне провайдера есть PPPoE сервер, а у клиента разбросано по городу 4 PPPoE-клиента.
Сам интернет в главном офисе они берут через выделенную сеть /30, алиас так-же в этом влане на стороне провайдера.

Бюджет минимальный, не более 10 тысяч. на магазин. Цель - сделать хорошо. Организовать резервирование связи, предприятие готово подключить второго провайдера. Правда в при внедрении возникают разные любопытные моменты. О которых, если интересно написано в первой статье.

P.S. Когда взялся за решение, опыт работы с протокалами Динамической Маршрутизации был лишь из курса лаб по CCNA, так сложилось что в нашем ISP один единый брас, и нам нет необходимости гонять L3. По этому, выбрал костыльный вариант со статикой. Однако, в последствии динамику ввести все-же пришлось, но для специфической нетривиальной, как мне кажется задачи об этом во второй статье.
Собственно, хоть вторя статья и написана вчера, но по факту все это было внедрено еще до того, как я взялся читать курс 300-101 ROUTE. Естественно, после прочтения и сдачи экзамена многие кирпичики сложились.
Но все равно, интересно, как проверять надежность канала в случае использования dynamic routing.

Комментарии

  • Я бы коротко описал исходные данные и поставленную задачу, а не заставлял бы людей проходить по разным ссылкам в поисках информации.
  • trilka написал:

    Я бы коротко описал исходные данные и поставленную задачу, а не заставлял бы людей проходить по разным ссылкам в поисках информации.

    Хорошо, постараюсь.
    Есть торговая сеть из 12ти магазинов, все точки подключены к одному провайдеру. На стороне провайдера организована связность всех магазинов (они находятся в одном выделенном VLAN), в этом vlan на стороне провайдера на BRASS есть интерфейс /30 для доступа клиенту в интернет, и PPPoE сервер. Т.к. клиент кое-где у себя еще и PPPoE поднимает.
    У клиента плоская L2 сеть, без управляемых коммутаторов (лишь один в офисе, в дефолтных настройках).
    Магазины клиента завязаны на офис:
    1.Им необходим интернет при проведении безналичных оплат.
    2.Кассы в целом работают автономно, но им периодичеки необходима синхронизация остатоков и цен с БД в офисе.
    3.Есть сотрудники магазина с ТСД (терминал сбора данных), которые работают напрямую с БД в офисе.
    Сам офис, подключен по схеме Dual-Homed, к нему от провайдера приходят 2 линка, один через медиа-конвертер подключенный от многквартирного дома (и зависим от питания в этом доме), второй через PON-терминал. Но, ONU установленное в офисе, работает спецефически, оно не пропускает DHCP-Offer пакеты от офиса в сеть. Другие магазины подключены в основном через ONU, у ONU есть еще одна специфика, она не пропускает OSPF пакеты из сети к клиенту. То есть, если за ONU есть OSPF-роутер, то во VLAN за OLT будут видны OSPF Hello пакеты, и роутеры за пределами OLT будут пытаться установить соседство, но роутер за ONU их не увидит.
    Так как, клиент раздает из офиса DHCP для мобильных устройств сотрудников всех магазинов, то связь у них идет через медиа-конвертер, а если этот линк ложиться, то в ручную переключают на PON иначе петля.

    Задача организовать резервирование канала, чтобы при аварии у ISP магазины продолжали работать, варианты аварий:
    1. Нет связи между конкретным магазином и ISP. Результат в магазине нет инета, платежи не проходят, нет связи с сервером для ТСД.
    2. Нет связи между линком 1 от ISP с офисом, во всех магазинах повторение ситуации N1, пока админы вручную не переключат линк с медика на PON-терминал. В таком случае все работает, за исключением DHCP для мобильных устройств сотрудников в магазине.
    3. Нет интернета у ISP. Локалка работает, платежи через безнал не прохдят.
    4. Полный ахтунг, нету обоих линков от ISP к офису. Комментировать последствия думаю не надо.

    Бюджет не более 10К на магазин. Необходимо решение: "чтобы все было хорошо". И при любом из вариантов аварий, работа магазина не останавливалась.
    Как-то так.
  • Могу ошибаться, но может хотя бы на мысль правильную подтолкну. Если есть разные точки подключения в интернет к провайдеру и нужно чтобы ходили пакеты протоколов, которые ходить отказываются, то можно попробовать все нужное упаковать в GRE туннели(можно еще и запаковать в защищенный IPsec) и после деинкапсуляции нужные пакеты пройдут до интерфейсов назначения и там уж точно их примут. Также можно воспользоваться протоколом HSRP или его аналогом VRRP для надежного резервирования канала связи с внутренним/внешним миром. Есть очень хорошие роутеры Mikrotik, которые очень сильно выручают в разных схемах и сценариях.
  • отредактировано июня 2016
    Anumrak написал:

    Могу ошибаться, но может хотя бы на мысль правильную подтолкну. Если есть разные точки подключения в интернет к провайдеру и нужно чтобы ходили пакеты протоколов, которые ходить отказываются, то можно попробовать все нужное упаковать в GRE туннели(можно еще и запаковать в защищенный IPsec) и после деинкапсуляции нужные пакеты пройдут до интерфейсов назначения и там уж точно их примут. Также можно воспользоваться протоколом HSRP или его аналогом VRRP для надежного резервирования канала связи с внутренним/внешним миром. Есть очень хорошие роутеры Mikrotik, которые очень сильно выручают в разных схемах и сценариях.

    Ну или glbp только он понятное дело проприетарный :)
  • отредактировано июня 2016
    Anumrak написал:

    Могу ошибаться, но может хотя бы на мысль правильную подтолкну. Если есть разные точки подключения в интернет к провайдеру и нужно чтобы ходили пакеты протоколов, которые ходить отказываются, то можно попробовать все нужное упаковать в GRE туннели(можно еще и запаковать в защищенный IPsec) и после деинкапсуляции нужные пакеты пройдут до интерфейсов назначения и там уж точно их примут. Также можно воспользоваться протоколом HSRP или его аналогом VRRP для надежного резервирования канала связи с внутренним/внешним миром. Есть очень хорошие роутеры Mikrotik, которые очень сильно выручают в разных схемах и сценариях.

    С GRE идея хорошая, но на том этапе, меня смущала дополнительная инкапсуляция.
    Но главным для меня фактором, который я на тот момент точно не знал, как решить, это каким образом, гарантированноо определить, что канал является доверенным. Ну скажем, потянулась оптика и часть пакетов, особенно больших пропадает. А вот мелкие OSPF Hello будут себе замечательно бегать и канал будет считаться нормальным и роутер будет слать трафик через него.
    Собственно, честно говоря, этот вопрос для меня открыт и сейчас. Думаю, тут нужно смотреть в сторону BFD.
    Очень хочется узнать мнение коллег и опыт.
  • Плюсую за GRE, ИМХО - оптимальный вариант. Оверлейная сеть должна избавить от проблем с прохождением мультикаста и сигнализации через провайдера. Туннели можно аггрегировать на роутере в ЦО, получится hub-and-spoke топология. С бранчей - по одному туннелю в ЦО через каждый имеющийся канал для резервирования. На туннельных интерфейсах поднимите OSPF, можно сразу сделать задел на масштабируемость и побить его на зоны: нулевая (бэкбон) внутри GRE, плюс по зоне на внутренние сети бранчей. Так сможете делать суммаризацию и бранчи анонсировать как стаб-зоны.
    Про растянутую оптику не осилил мысль. Если нужно мониторить качество канала, посмотрите аналоги Цисковского ip-sla в Микротике и насколько они прикручиваемы к OSPF (например, менять cost на интерфейсе, в зависимости от packet loss, jitter и т.п.). Тут могу только предполагать.
  • Debug_all написал:

    Плюсую за GRE, ИМХО - оптимальный вариант. Оверлейная сеть должна избавить от проблем с прохождением мультикаста и сигнализации через провайдера. Туннели можно аггрегировать на роутере в ЦО, получится hub-and-spoke топология. С бранчей - по одному туннелю в ЦО через каждый имеющийся канал для резервирования. На туннельных интерфейсах поднимите OSPF, можно сразу сделать задел на масштабируемость и побить его на зоны: нулевая (бэкбон) внутри GRE, плюс по зоне на внутренние сети бранчей. Так сможете делать суммаризацию и бранчи анонсировать как стаб-зоны.
    Про растянутую оптику не осилил мысль. Если нужно мониторить качество канала, посмотрите аналоги Цисковского ip-sla в Микротике и насколько они прикручиваемы к OSPF (например, менять cost на интерфейсе, в зависимости от packet loss, jitter и т.п.). Тут могу только предполагать.

    Идея интересна. Были такие мысли, но, т.к. ходили нехрошие слухи о том, что на MikroTik multi-area ospf работает не очень стабильно, то я решил перестраховаться и делать статику, с аналогом ip-sla, скриптом пинговал через разные каналы и менял административное расстояние статических маршрутов.
    Просто, в MikroTik есть утилита NetWatch она, как ip-sla/icmp-echo шлет ровно один пакет, в определенный интервал с определенным тайм-аутом. То есть, пинг пробежал один, ок, работает, следущий не пробижал, лежим.
    Однако, бывают моменты, когда маленькими пакетами все будет бегать, где-то 64-128 kbytes, а вот 256-1024 и более уже будут потери. (Например такое было с одним стареньким свитчем Planet у которого померали sfp-uplink порты, а магазин был подключен медью от этого Planet)
    По этому, меня интересовал способ, как именно проверять надежность канала ни одним echo-пакетом, пусть и большего размера (в ip-sla/icmp-echo можно менять размер), а именно слать несколько пакетов (например 7 подряд) по 1400 байт каждый и уже по результатам решать.
    Кстати, как можно на Cisco прикрутить ip-sla к OSPF?
    Насколько я понял, для именно таких целей, как у меня используется протокол BFD, в курсе по ROUTE (300-101) он не рассматривается.
    Вот и интересуюсь, может быть, кто-то применял в бою?
  • Так-же, пикантности добавлял тот момент, что изначально по ТЗ, в офис приходит 2 канала от ISP-1 и один канал от ISP-2, магазины по дефолту питались инетом через ISP-1, через центральной маршрутизатор в офисе, и так-же была цель сделать так, что, если офис берет интернет от ISP-2, при этом локалка через ISP-1 жива, то магазины должны брать инет уже не из офиса, а через свои ISP-2
  • отредактировано июня 2016
    feo_sobolev написал:

    Так-же, пикантности добавлял тот момент, что изначально по ТЗ, в офис приходит 2 канала от ISP-1 и один канал от ISP-2, магазины по дефолту питались инетом через ISP-1, через центральной маршрутизатор в офисе, и так-же была цель сделать так, что, если офис берет интернет от ISP-2, при этом локалка через ISP-1 жива, то магазины должны брать инет уже не из офиса, а через свои ISP-2

    По два туннеля на каждую точку, рулите через ip ospf cost. Если праймари туннель падает, по таймауту отобьется маршрут и вы переключитесь на резервный туннель.

    Соберите лабу в каком-нибудь сетевом эмуляторе, например unetlab и все вопросы отпадут. :)

  • отредактировано июня 2016
    NAT_GTX написал:


    По два туннеля на каждую точку, рулите через ip ospf cost. Если праймари туннель падает, по таймауту отобьется маршрут и вы переключитесь на резервный туннель.
    Соберите лабу в каком-нибудь сетевом эмуляторе, например unetlab и все вопросы отпадут. :)

    Спасибо. Собственно система уже работает в продакшене более чем пол года, правда на статике.
    Сейчас рисуется еще один подобный проект, но уже на Cisco, там точно буду делать на Dynamiic Routing, наверное с использованием BFP (если ISR их поддержат).
    P.S. GRE - тунелли, разные ospf cost, DMVPN за NAT + IPSec уже в UnetLab собрал - работает.
    Вот только с BFD еще не практиковался, не знаю, как именно воспроизвести ситуацию.
  • отредактировано июня 2016
    точно буду делать на Dynamiic Routing, наверное с использованием BFP
    У OSPF механизм детектирования упавших линков заложен архитектурно - периодический обмен hello-сообщениями. Вопрос лишь в том, что при возникновении ошибки где-то на промежуточном участке между роутерами, когда их интерфейсы с обоих сторон останутся в апе, детектирование проблемы произойдет только по истечении dead-интервала, который, если мне не изменяет память, меньше секунды в Цисках не ставится. BFD в этом случае может помочь добиться суб-секундной пересходимости сети. Исходя из описания выше, смысла Вам в этом мало. А в ситуации с потерями пакетов может быть даже и вредно, т.к. соседство с большой вероятностью начнет флапать.
    как можно на Cisco прикрутить ip-sla к OSPF?
    Напрямую, кажется, никак. Первое обходное решение, пришедшее в голову, - сделать трек ip-sla объекта и привязать его к Embedded Event Manager'у (EEM). При срабатывании триггера в треке EEM может вбивать произвольную последовательность команд, например:
    conf t
    int gi 0/0
    ip ospf cost 65535
    Второй вариант - поднять линуксовую машину в ЦО и запустить мониторинг сети и каналов с нее. В минимальном исполнении - простая пинговалка с двух source'ов. На каждом споке поднимаете два лупбэка. Статиками в ЦО загоняете пинги на один лупбэк через основной канал, на другой - через резервный. Со стороны спока - аналогично, чтобы не было ассиметрии в реплаях. Далее к пинговалке прикручиваете обработку статистики и какие-то триггеры. При попадании в триггер скрипт уже логинится на роутеры по ssh и меняет cost нужных интерфейсов. Все перечисленное делается на Python+pexpect, навскидку.

    p.s. на истину не претендую. И да поправят меня гуру.
  • Мне кажется, у второго вариант есть недостатки:
    Если устройство для мониторинга и исполнения скриптов будет находится на стороне провайдера, то в случае потери пакетов, она сможет изменить машрут в центральном офисе, в удаленном, роут будет по прежнему через плохой канал. Мне кажется, необходима автономность. По этому, возможно вариант с ip sla, кстати у самиx MikrtoTik с этим все хорошо - он и пинганет, и посчитатет, и метрику изменит, и письмо о падении отправит.
    С Cisco практического опыта мало, особенно в таких нетривиальных задачках, по этому, и спрашиваю у кого какие варианты.
    Тут хочется именно автономности, чтобы пинговал роутер офис, по одному каналу, потом по другому, потом по третьем и четвертому и желательно раз по 5 :smile: и если 4 из 5 вернулось то ок.

    А вообще, надо будет попробовать на UNL c BFD побаловаться. Если, скажем использовать EIGRP вместо OSPF за счет более быстрой сходимости, плюс BFD. Там вроде бы процент потерь высчитывается и размер пакета можно поставить. А интервал можно сделать и 3-5 секунд, этого, думаю будет достаточно.
    Собственно, в первом посту, я скидвал статью на хабр, где описал как подобное запилил на тике, там у меня и вышло как раз время реакции 3-5 секунд, и что больше всего интересно, если к примеру начались потери, алгоритм сработал, канал сменился и не вернется обратно, пока потери не прекратятся. Хотя, конечно. тоже может флапать, если будет то совсем плохо, то совсем хорошо.
  • Если достаточно, чтобы все 12 магазинов варились в одной IP среде без сегментации какой то, то eigrp+любой приятный глазу протокол резервирования шлюза. Если хочется больше контроля и иерархичности, то ospf+тот же протокол.
  • Anumrak написал:

    Если достаточно, чтобы все 12 магазинов варились в одной IP среде без сегментации какой то, то eigrp+любой приятный глазу протокол резервирования шлюза. Если хочется больше контроля и иерархичности, то ospf+тот же протокол.

    Не совсем понял Вашу мысль. Если одна IP среда, без сегментации, то это один Layer-2 же.
    А если у нас в каждом из магазинов стоит свой роутер, который уже по OSPF/EIGRP обменивается маршрутами, то IP среда, в каждом из магазинов уже будет своя и уже будет сегментация широковещательных пакетов, что собственно и было нужно, как одна из задач.
  • отредактировано июня 2016
    Я не правильно выразился) Имел в виду отсутствие какой либо выборки, деления или группирования. Если группирование магазинов не нужно, то пойдет eigrp. Если нужно группирование типа 12 магазинов, но ты хочешь их разбить на 3, 2, 4, 3 или что то подобное, чтобы удобнее было, то подойдет ospf, так как ты можешь сделать основные офисы в backbone регионе, а дальние - в стандартных, тупиковых или не совсем тупиковых регионах. Для удобства ассоциации магазинов с построенной сетью, вот)
  • feo_sobolev написал:

    trilka написал:

    Другие магазины подключены в основном через ONU, у ONU есть еще одна специфика, она не пропускает OSPF пакеты из сети к клиенту. То есть, если за ONU есть OSPF-роутер, то во VLAN за OLT будут видны OSPF Hello пакеты, и роутеры за пределами OLT будут пытаться установить соседство, но роутер за ONU их не увидит.

    Пару лет назад, когда PON пошел в массы, у многих решений (в том числе и у тех, что внедрялись крупными операторами типа МГТС), были проблемы с работой multicast. Со временем проблемы решили, но вероятно не все и не везде. Подозреваю, что тут и кроется причина странной работы OSPF.
    В принципе, проблема известна еще и до PON, сталкивался на некоторых арендованных каналах с проблемами подобного рода. Лечилось очень просто - перевод работы OSPF на этом канале в NBMA и прописывание ручками всех соседей, далее OSPF начинает работать в unicast. Если топология меняется не часто, то решение гораздо удобнее, чем VPN. Если топология часто меняется и вообще не сильно однородная по транспорту (ethernet-канал, L3VPN, интернет статический, интернет через сотовую сеть), то тут только DMVPN, но это отдельная песня.

    Я так же за Mikrotik в каждом офисе, можно брать самые примитивные, типа RB95x. В центральный офис взял бы что-то более продвинутое типа RB2011 (можно с WiFi, если это требуется), в количестве двух штук. Хорошая, надежная железка, плюс SFP порт, что в теории позволит убрать медиаконвертор (лишняя точка отказа).
    Я бы подключил интернет на каждый из RB2011 и настроил один из них как резерв (анонс дефолта в OSPF с большой метрикой). IP-SLA или его аналог можно настроить для мониторинга последней мили до провадера и завязать это все на OSPF, не знаю как это настроить на Mikrotik, но наверно можно.
    Не забываем положить в ЗИП хотя бы один RB95x, лучше два. Может вылезти задача срочного подключения, не говоря о потенциальной аварии.

    Так же, сразу замечу, что при появлении необходимости организовать резерв на одной из точек, вы, без дополнительных затрат, поднимаете между удаленным офисом и центральным туннель через резервного провайдера и просто добавляете его в OSPF с ухудшенной метрикой. Вы даже можете рассмотреть вариант быстрого резерва, когда использую USB-свисток с мобильным интернетом, сможете организовать быстрый и более менее работающий резервный канал, пока провайдер будет чинить свою сеть.

    Бюджет по текущим ценам:
    15 т.р. на центральный офис (два RB2011)
    3,5 на каждый офис (один RB951)
    7 т.р. - ЗИП (два RB951)
  • gs1571 написал:

    feo_sobolev написал:

    trilka написал:

    Другие магазины подключены в основном через ONU, у ONU есть еще одна специфика, она не пропускает OSPF пакеты из сети к клиенту. То есть, если за ONU есть OSPF-роутер, то во VLAN за OLT будут видны OSPF Hello пакеты, и роутеры за пределами OLT будут пытаться установить соседство, но роутер за ONU их не увидит.

    Пару лет назад, когда PON пошел в массы, у многих решений (в том числе и у тех, что внедрялись крупными операторами типа МГТС), были проблемы с работой multicast. Со временем проблемы решили, но вероятно не все и не везде. Подозреваю, что тут и кроется причина странной работы OSPF.
    В принципе, проблема известна еще и до PON, сталкивался на некоторых арендованных каналах с проблемами подобного рода. Лечилось очень просто - перевод работы OSPF на этом канале в NBMA и прописывание ручками всех соседей, далее OSPF начинает работать в unicast. Если топология меняется не часто, то решение гораздо удобнее, чем VPN. Если топология часто меняется и вообще не сильно однородная по транспорту (ethernet-канал, L3VPN, интернет статический, интернет через сотовую сеть), то тут только DMVPN, но это отдельная песня.
    Кстати да, я тоже думал про то, что ONU не пропускает мультикаст и пробовал делать через NBMA, где пакеты уже будут ходить Unicast, но, так тоже не взлетело. Снятие трафика WireShark показывает, что клиенты со стороны OLT Uplink на классическом Ethernet, видият пакеты приходящие из сети PON (как мультикаст, так и юникаст) и даже пытаются им отвечать (Unicast и Multicast OSPF Hello пакетами, в которых в качестве соседей указаны клиенты подключенные PON), но клиенты PON ответов этих упорно не видят.
    Можно было бы, сделать внутри сети провайдера GRE туннели.
    Но, я тогда решил несколько извратится по-своему.
    Прописал статические маршруты, с разной метрикой, далее запустил Netwach (аналог IP Sla) до всех шлюзов, со скриптом, который в случае падения, сразу ухудшает метрику роута на 100, например было 10 стало 110, и после чего запускает еще один, но уже отдельный скрипт, который будет пинговать удаленных хост 7 раз по 1500 байт. И если 5 из 7 пакетов приходят хорошо, то возвращаем метрику со 110 до 10. Если нет то оставляем 110 и так-же проверяем другие маршруты до этого филиала.
    gs1571 написал:

    <
    Бюджет по текущим ценам:
    15 т.р. на центральный офис (два RB2011)
    3,5 на каждый офис (один RB951)
    7 т.р. - ЗИП (два RB951)

    По бюджету сделали несколько иначе, т.к. в магазинах уже были свои точки доступа Wi-Fi. Поэтому взяли в филиалы MikroTik hEx, а в центральный офис один RB1100AHx2.

    Так-же, во все филиалы поставили резервный канал от Ростелекома, через который держим поднятыми туннели до офиса, именно через резервный инет (PBR). Таким образом, в случае, падение основного канала, резерв уже поднят и готов к работе.

    В общем, суммарно, время реакции у меня составляет около 3 секнд на переключение. Причем, если будут проблемы с линией (там потери пакетов на промежутке у провайдера) система будет продолжать работать именно на резерве, за счет скрипта с 7-ю пингами по 1500 байт.
  • Красота лепота :)
  • Меня, конечно, оторопь берет пред решениями типа PBR + IP SLA (или аналоги). Но если работает, то что уж тут.
Войдите или Зарегистрируйтесь чтобы комментировать.