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

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

Вопрос по оборудованию.

отредактировано июня 2016 Раздел: Best practice
Всем привет!
Есть задача организовать шифрованный защищенный туннель между двумя точками в разных городах.
В одном городе будет 2 провайдера (Ethernet + ADSL, оборудование на стороне EDGE есть), в другом один, а резерв вероятно на 3G.
Трафик который должен бегать в тунеле не будет превышать 10 мбит.
Требуется решение на Cisco. Желательно на каких-нибудь наиболее оптимальных бюджетных платформах для этих целей. (Ну не покупать же ASR :) )
Какие платформы на Ваш взгляд, лучше всего подойдут?
Так как, пока будет 2 точки и тунель между ними, вероятно, в будущем добавятся еще пара точек. Поэтому, думаю, не плохо было бы иметь DMVPN с IPSec шифрованием.
Что посоветуете? Знаю что среди участников форума многие работают напрямую с Cisco и используют подобные решения у себя в продакшине.
Так-же вопрос, для шифрования IPSec тунельного трафика, требуется ли какие-то аппаратные модули в маршрутизаторы? Если это скажем будут ISR G2.
К сожалению в курсе по CCNP ROUTE такие подробности не обсуждались.
Заранее спасибо.
Тэги темы:
«1

Комментарии

  • для ISR G2, 4000 только лицензия Security нужна и все будет работать. Даже маршрутизаторы Cisco 800-ой серии поддерживают DMVPN и IPsec.
  • отредактировано июня 2016
    cann написал:

    для ISR G2, 4000 только лицензия Security нужна и все будет работать. Даже маршрутизаторы Cisco 800-ой серии поддерживают DMVPN и IPsec.

    Спасибо, за то, что отозвались :)
    Под лицензией Вы пониаете версию IOS? Не совсем понял, что такое "4000"
    То есть, в имени образа должно присутствовать advsecurityk9 ?
    Cогласно этой странице
    Хмм, ISR G2 это серия 19xx, 29xx, 39xx, в принципе для этих скромных целей подойдет и ISR G1 как я понял, начиная от 800 серии, тогда уже IOS c advsecurityk9.
    Если где не прав, поправьте пожалуйста.
  • отредактировано июня 2016
    1841 <-> 3845 организовывали шифрованный туннель. Обе умеют в DMVPN (на текущий момент работает 7 или 8 1841 в режиме spoke к одной 3845 - всё нешифрованные туннели). Образы для поддержки DMVPN должны быть выше 15 (advsecurity или adventerprise не подскажу точно, какого хватит, надо смотреть по спецификациям).
    Только тут вопрос встает, насколько больше у вас станет бранчей? Такая связка много именно шифрованных туннелей вряд ли обработает.
  • Jay-T написал:

    1841 <-> 3845 организовывали шифрованный туннель. Обе умеют в DMVPN (на текущий момент работает 7 или 8 1841 в режиме spoke к одной 3845 - всё нешифрованные туннели). Образы для поддержки DMVPN должны быть выше 15 (advsecurity или adventerprise не подскажу точно, какого хватит, надо смотреть по спецификациям).
    Только тут вопрос встает, насколько больше у вас станет бранчей? Такая связка много именно шифрованных туннелей вряд ли обработает.

    Согласен, что нужно с самого начала думать о масштабируемости и о том, для каких целей и нагрузок будет приобретаться оборудование.
    На первый вопрос о том, сколько будет добавляться бранчей, был ответ ну один или два, через год, может быть.
    Как-то не уверенно они ответили.
    У меня есть старенькая 2651XM, с 12 adventerprise, она вроде даже уже умеет DMVPN, сегодня попробую потестить.
  • feo_sobolev написал:

    cann написал:

    для ISR G2, 4000 только лицензия Security нужна и все будет работать. Даже маршрутизаторы Cisco 800-ой серии поддерживают DMVPN и IPsec.

    Спасибо, за то, что отозвались :)
    Под лицензией Вы пониаете версию IOS? Не совсем понял, что такое "4000"
    То есть, в имени образа должно присутствовать advsecurityk9 ?
    Cогласно этой странице
    Хмм, ISR G2 это серия 19xx, 29xx, 39xx, в принципе для этих скромных целей подойдет и ISR G1 как я понял, начиная от 800 серии, тогда уже IOS c advsecurityk9.
    Если где не прав, поправьте пожалуйста.
    Лицензируется только линейка ISR G2 и ISR 4000 (это более новая линейка маршрутизаторов с интегрированными сервисами). Т.к. там Universal image, в котором весь фунционал уже есть, его просто нужно активировать лицинзией - это отдельный файлик, получается через PAK на портале Cisco, а PAK нужно купить. Можно включить evaluation режим, т.е. пробный период лицензии :)
    Если брать ISR G1, то там, независимо от версии IOS (12.4 или 15), нужен определенный образ, как вы и сказали, advsecurityk9, например.
    Если говорить точно, то 1800,2800,3800 - ISR G1; 1900,2900,3900 - ISR G2, а 800 серия она немного отдельно всегда была, там очень много моделей, нужно смотреть спецификации. Актуальная сейчас 880 серия.

  • cann написал:


    Лицензируется только линейка ISR G2 и ISR 4000 (это более новая линейка маршрутизаторов с интегрированными сервисами). Т.к. там Universal image, в котором весь фунционал уже есть, его просто нужно активировать лицинзией - это отдельный файлик, получается через PAK на портале Cisco, а PAK нужно купить. Можно включить evaluation режим, т.е. пробный период лицензии :)
    Если брать ISR G1, то там, независимо от версии IOS (12.4 или 15), нужен определенный образ, как вы и сказали, advsecurityk9, например.
    Если говорить точно, то 1800,2800,3800 - ISR G1; 1900,2900,3900 - ISR G2, а 800 серия она немного отдельно всегда была, там очень много моделей, нужно смотреть спецификации. Актуальная сейчас 880 серия.

    Спасибо за подробное разъяснение, пр ISR G1 и ISR G2 был в курсе, так-же, про лицензирование слышал на 15-м IOS, теперь ясно, что это касается лишь ISR G2. А вот про отдельной 800й серии не знал.
    В общем, я уточнил у заказчика, примерно что им нужно.
    У них есть сеть, с управляемыми коммутаторами и маршрутизатором (неплохим, на мой взгляд) - Mikrtoik CCR 1008. Собственно можно и на Mikrotik построить решение, но они хотят принципиально на Cisco.
    От Cisco им нужно только организация канала между офисом и бранчем, большого расширения бренчей пока не предвидеться. Также, они не планируют отказываться от Mikrotik в офисе, в роли EDGE-устройства, занимающегося NAT, Firewall Filter, Queues и резервированием каналов.
    В удаленном офисе, они хотят поставить 2 устройства (вижу схему с HRRP, VRRP) и подключить 2х провайдеров.
    Треубется защищенный VPN канал между удаленным офисом и центральным. Построенным на Cisco.
    Как я понимаю, поскольку Cisco в главном офисе будет находится за NAT (Mikrotik), то схема с классическим DMVPN не выйдет. Вероятно требуется другое решение, возможно оно будет не так масштабируемо.
    Думаю над тем, чтобы в удаленном офисе поставить 2 железки, а Cisco из центрального будет в роли VPN-клиента.
    Есть какие-нибудь рекомендации. Хотя такой дизайн, вроде выглядит кривовато. Может кто что посоветует в плане дизайна?
  • Static NAT если сделать и Transport mode, то должно работать, но лучше протестировать на GNS3 или UNL :)
    Если бранчей 2-3 и больше не предвидится, то вполне можно обойтись без DMVPN, имхо
  • Еще, думаю, как вариант, взять у провайдеров по отдельному подключению для Cisco, чтобы она имела отдельные белые IP и независимый канал, для туннелирирования. И тогда уже к ней подключать бранчи.
    Тоже думаю, что если бранчей будет не больше 3-5, то можно обойтись и без DMVPN.
    А вообще есть у кого-нибудь опыт, когда VPN-сервер находился за NAT и при этом использовался IPsec, полагаю тогда нужно шифровать данные внутри GRE пакета.
    У меня опыта с IPsec практически нет. да и с реальным боевым Cisco тоже. Попробую потестить на лабах.
  • feo_sobolev написал:

    Еще, думаю, как вариант, взять у провайдеров по отдельному подключению для Cisco, чтобы она имела отдельные белые IP и независимый канал, для туннелирирования. И тогда уже к ней подключать бранчи.
    Тоже думаю, что если бранчей будет не больше 3-5, то можно обойтись и без DMVPN.
    А вообще есть у кого-нибудь опыт, когда VPN-сервер находился за NAT и при этом использовался IPsec, полагаю тогда нужно шифровать данные внутри GRE пакета.
    У меня опыта с IPsec практически нет. да и с реальным боевым Cisco тоже. Попробую потестить на лабах.

    Собрал на на том, что было под рукой (c2651XM --><--Mikrtoitk RB 2011 --><---c2821) где один из роутеров находился за NAT на Mikrotik был организован static dst-nat для GRE, как минимум классический GRE работает, без шифоования и статический туннель.
    Теперь, попробую поиграться с шифрованием и Dynimic Tunnel.
    Ну и чтобы OSPF/EIGRP могло бегать.
  • отредактировано июня 2016
    Есть очень приятный опыт работы с GRE over IPsec на оборудовании Cisco 2911/K9. Сначала убеждаешься, что на шлюзе провайдеров открыты на вход ESP пакеты и 500 udp порт(для работы ISAKMP протокола) конкретно для твоего хоста. Далее создаешь связь между локальными подсетями через интернет с помощью GRE, а потом создаешь IPsec шифрование интересующего тебя трафика. Ну и заворачиваешь туннельные подсети в работу протоколов динамической маршрутизации. Если туннели работают нормально и счетчики шифрованных/дешифрованных ESP пакетов IPsec тикают нормально и пинги ходят без потерь, то eigrp/ospf смогут работать, потому что GRE носит все что угодно) Потом уже анонсируешь интересующие тебя подсети в eigrp/ospf router.
    Также добавлю, что eigrp схОдится быстрее, чем ospf, но eigrp не умеет редистрибутить подсети на другую сторону =\ ospf в этом плане полезнее, так как если на твоем пограничном рутере есть какие то конкретные статические маршруты, которые ты не хотел бы отдавать, то eigrp со статической редистрибуцией перекинет их все на другую сторону =\ и даже на 0.0.0.0/0, тогда театр и закроется. У ospf есть параметр subnets после redistribute static, что позволяет делать приятные вещи) Ну и еще, если vpn-сервер находится за NAT, то в случае не шифрованных пакетов может понадобиться функция NAT-Traversal. Она есть как в Cisco, так и в Mikrotik.
  • Anumrak написал:

    Есть очень приятный опыт работы с GRE over IPsec на оборудовании Cisco 2911/K9. Сначала убеждаешься, что на шлюзе провайдеров открыты на вход ESP пакеты и 500 udp порт(для работы ISAKMP протокола) конкретно для твоего хоста. Далее создаешь связь между локальными подсетями через интернет с помощью GRE, а потом создаешь IPsec шифрование интересующего тебя трафика. Ну и заворачиваешь туннельные подсети в работу протоколов динамической маршрутизации. Если туннели работают нормально и счетчики шифрованных/дешифрованных ESP пакетов IPsec тикают нормально и пинги ходят без потерь, то eigrp/ospf смогут работать, потому что GRE носит все что угодно) Потом уже анонсируешь интересующие тебя подсети в eigrp/ospf router.
    Также добавлю, что eigrp схОдится быстрее, чем ospf, но eigrp не умеет редистрибутить подсети на другую сторону =\ ospf в этом плане полезнее, так как если на твоем пограничном рутере есть какие то конкретные статические маршруты, которые ты не хотел бы отдавать, то eigrp со статической редистрибуцией перекинет их все на другую сторону =\ и даже на 0.0.0.0/0, тогда театр и закроется. У ospf есть параметр subnets после redistribute static, что позволяет делать приятные вещи) Ну и еще, если vpn-сервер находится за NAT, то в случае не шифрованных пакетов может понадобиться функция NAT-Traversal. Она есть как в Cisco, так и в Mikrotik.

    Спасибо за информацию, хочу немного Вас поправить. В EIGRP при редистрибуции есть возможность делать это через Route-Map, таким образом, отфильтровывать ненужные маршруты о которых не нужно знать другим.

    Вчера на стенде попробовал кое-что, результаты:
    1.За NAT, GRE работает (пока сделал лишь Static Tunnel)
    2. Без NAT заработало GRE over IPsec, где интересным трафиком считал лишь gre пакеты, делал через crypto-map, который вешал на WAN интерфейс роутеров.
    3. С NAT получить GRE over IPsec пока не получилось. У меня ISAKMP SA устанавливались, а вот IPsec пакеты не ходили. Хотя, я видел на Mikrotik что они вылетали из одного cisco роутера (так же это видел командой debug ip packet на нем), и через Mikrotik долетали до второго роутера, проходя нат (на Тике делал проброс портов UDP 500/ 1500, ipsec-esp -50 , gre 47 хотя уже при ipsec gre не использовался)
    Однако, на втором Cisco роутере, что находился за NAT, как не странно, пакеты не видны даже в команде debug ip packet.
    Вчера пытался делать на реальном домашнем стенде, сегодня на работе, будут пробовать через UNL.
    Еще интересно, есть ли у кого опыт внедрения BFD при работе с OSPF/EIGRP.
    Вообще очень интересная тема, кто и как отслеживает именно НАДЕЖНОСТЬ канала, когда допустим есть потери, но каким-то, магическм образом пакеты Hello долетают, и в целом OSPF/EIGRP считает канал нормальным, а по факту реальный трафик нормально не ходит.
    Кто и как с этим борется?
  • отредактировано июня 2016
    Спасибо за информацию, хочу немного Вас поправить. В EIGRP при редистрибуции есть возможность делать это через Route-Map, таким образом, отфильтровывать ненужные маршруты о которых не нужно знать другим.
    Да, Вы правы)
    У меня ISAKMP SA устанавливались, а вот IPsec пакеты не ходили.
    Не фильтруются ли ESP пакеты списками доступа по пути негласным deny any any? Правильно ли видны подсети в таблице маршрутизации?
  • Anumrak написал:


    Не фильтруются ли ESP пакеты списками доступа по пути негласным deny any any? Правильно ли видны подсети в таблице маршрутизации?

    ACL не было, никаких, ни на роутерах, ни на Mikrotik, туннель думаю, настроен был правильно, т.к. стоило мне, отключиь правила NAT на промежуточном Mikrtoik, и изменить tunnel destination на роутере, что находится не за NAT, с ip Mikrotika (на котором dst nat на второй роутер) прямо на айпи второго роутера, (на котором вообще ничего не менял), так сразу же все начинает работать.
    Сегодня попробую еще раз схему в UNL собрать. Правда в промежутке уже будет Cisco, но это не суть важно.
    Сейчас, железки выключены и я не возле них, чтобы еще раз глянть конфиг.
  • А может в crypto acl не указаны нужные подсети для работы? Может интерфейс с crypto-map не считает нужный тебе трафик интересным?
  • отредактировано июня 2016
    Anumrak написал:

    А может в crypto acl не указаны нужные подсети для работы? Может интерфейс с crypto-map не считает нужный тебе трафик интересным?

    Удалось победить схему, используя ipsec profile и привязывая его прямиком к tunnel-interface.
    Без использования crypto-map на WAN интерфейсах.
    Следующий вопрос к участникам форума:
    У кого есть опыт работы с Cisco ISR 880 серии? Планируется взять 3 таких Cisco ISR и связять их между собой по DMVPN + IPSEC, так-же у некоторых планируется работа черз 3G/4G модули.

    Есть у кого, какой-либо позитивный/негативный опыт?
  • feo_sobolev написал:

    Anumrak написал:

    А может в crypto acl не указаны нужные подсети для работы? Может интерфейс с crypto-map не считает нужный тебе трафик интересным?

    Удалось победить схему, используя ipsec profile и привязывая его прямиком к tunnel-interface.
    Без использования crypto-map на WAN интерфейсах.
    Следующий вопрос к участникам форума:
    У кого есть опыт работы с Cisco ISR 880 серии? Планируется взять 3 таких Cisco ISR и связять их между собой по DMVPN + IPSEC, так-же у некоторых планируется работа черз 3G/4G модули.

    Есть у кого, какой-либо позитивный/негативный опыт?
    У меня почти все филиалы (около 30) сидят на 880 и DMVPN с резервированием (2 хаба на каждом свой ISP, на споках есть так же по 2 ISP, сейчас внедрять BGP буду ибо слишком много завязано на IP адреса) явных проблем пока встречал.
    Что значит связать DMVPN + IPSEC? )))
    Если вы хотите связать циску и микротик, это это только GRE over IPSEC (ну или IPSEC over GRE :)))) )
    DMVPN проприетарщина и с микротиком работать не будет. Создавайте отдельные туннели для этих целей.
    Лабу соберите, натыкайте там нодов и играйтесь вдоволь :)))
  • to NAT_GTX
    Спасибо за ответ! В проекте, который маячит, пока будет один филиал и один ЦО, в будущем может добавиться еще один филиал. Их много, скорее всего не будет.
    Стоит вопрос об организации VPN с IPSec.
    Заказчик хочет все строить на Cisco. По этому, для филиалов, решил остановиться на 880й серии, однако заказчик хочет в целях экономии поставить роутер 880й серии и в офис, которые будет в роли HUB. Т.к. большой нагрузки не планируется.
    C Mikrotik ничего скрещивать не буду, Mikrotik в главном офисе играет роль пограничного маршрутизатора, держащего 2 ISP. Собственно он же будет осуществлять статические NAT трансляции дли приходящих туннелей. То есть перенаправлять все на Cisco.
    В DMVPN мне нравится то, что он пробивает NAT, (Я говорю о Spoke-роутерах), т.к. точно не ясно будет ли в филиалах белый IP. Поэтому, выбирал метод, который точно пробьет NAT.
    Лабу собрал) Нодов натыкал, NAT пробил :)
    Кстати, скажите, а какой у Вас dead - интервал между динамической маршрутизацией? И как быстро роутеры меняют маршруты при падании ISP?

  • Коллеги еще вопрос от новичка, скажите пожалуйста, Вы где покупаете Cisco?
    И какую гарантию Вам предлагают, покупаете с TAC или без?
    И вообще рекомендации.
    Моим заказчикам, предлагает магазин, 3х месячную гарантию без TAC, ну и TAC около 500$ за одну единицу 880й серии, как я понял.
  • NAT_GTX написал:


    сейчас внедрять BGP буду ибо слишком много завязано на IP адреса)

    Если не секрет, какой именно функционал ждете от BGP, которого Вам не хватает в IGP для внутренних целей.

  • feo_sobolev написал:

    Коллеги еще вопрос от новичка, скажите пожалуйста, Вы где покупаете Cisco?
    И какую гарантию Вам предлагают, покупаете с TAC или без?
    И вообще рекомендации.
    Моим заказчикам, предлагает магазин, 3х месячную гарантию без TAC, ну и TAC около 500$ за одну единицу 880й серии, как я понял.

    Если у вас нет контракта нет и поддержки, траблшутинг будет основан на гуглении.
    В случаем поломки железа, не будет моментальной замены на новую, вы будете ждать до 45 дней.
    Коллеги, поправьте меня если я в чем то не прав.
  • feo_sobolev написал:

    to NAT_GTX
    Спасибо за ответ! В проекте, который маячит, пока будет один филиал и один ЦО, в будущем может добавиться еще один филиал. Их много, скорее всего не будет.
    Стоит вопрос об организации VPN с IPSec.
    Заказчик хочет все строить на Cisco. По этому, для филиалов, решил остановиться на 880й серии, однако заказчик хочет в целях экономии поставить роутер 880й серии и в офис, которые будет в роли HUB. Т.к. большой нагрузки не планируется.
    C Mikrotik ничего скрещивать не буду, Mikrotik в главном офисе играет роль пограничного маршрутизатора, держащего 2 ISP. Собственно он же будет осуществлять статические NAT трансляции дли приходящих туннелей. То есть перенаправлять все на Cisco.
    В DMVPN мне нравится то, что он пробивает NAT, (Я говорю о Spoke-роутерах), т.к. точно не ясно будет ли в филиалах белый IP. Поэтому, выбирал метод, который точно пробьет NAT.
    Лабу собрал) Нодов натыкал, NAT пробил :)
    Кстати, скажите, а какой у Вас dead - интервал между динамической маршрутизацией? И как быстро роутеры меняют маршруты при падании ISP?

    Выбирайте тайминги для IGP по своему усмотрению, у меня стоят дефолтные для Point-to-multipoint Nonbroadcast mode. Если будет нужна более быстрая сходимость уменьшу тайминги или заюзаю BFD.
  • feo_sobolev написал:

    NAT_GTX написал:


    сейчас внедрять BGP буду ибо слишком много завязано на IP адреса)

    Если не секрет, какой именно функционал ждете от BGP, которого Вам не хватает в IGP для внутренних целей.

    Два ISP, от каждого свои PA адреса. На одном ISP сидят например почта, терминалки и при падении его, я лишаюсь всех сервисов завязанных на DNS. Своя AS и PI адреса избавят меня от этой и других проблем, при падании одного ISP все будет доступно через резервный ISP. Так же каналы разнесены не только по логике, но и по физике, а это отказоустойчиваось. И ещё, не понравился один провайдер, ушёл к другому без геморроя и перенастройки оборудования.
  • Рекомендую к прочтению\просмотру.

    http://linkmeup.ru/blog/33.html
    Динамическая маршрутизация

    http://linkmeup.ru/blog/65.html
    BGP и IP SLA
  • отредактировано июня 2016
    NAT_GTX написал:

    feo_sobolev написал:

    Коллеги еще вопрос от новичка, скажите пожалуйста, Вы где покупаете Cisco?
    И какую гарантию Вам предлагают, покупаете с TAC или без?
    И вообще рекомендации.
    Моим заказчикам, предлагает магазин, 3х месячную гарантию без TAC, ну и TAC около 500$ за одну единицу 880й серии, как я понял.

    Если у вас нет контракта нет и поддержки, траблшутинг будет основан на гуглении.
    В случаем поломки железа, не будет моментальной замены на новую, вы будете ждать до 45 дней.
    Коллеги, поправьте меня если я в чем то не прав.
    Спасибо, информация интересная.
    Отсутствие TAC примерно понятно чем грозит, непонятен срок гарантии железа, без покупки TAC - всего 3 месяца.
    То есть, к примеру, в случае брака, через 3 месяца, что-то (тьфу/тфьу) пойдет не так и все :) Заново покупать новую кошку. Как-то это, ну не очень серьзено как мне кажется. Впрочем...

    Насчет блока адресов и своей AS, я Вас понял, удобно, согласен. Что такое AS и PI и PA адреса я знаю, т.к. работаю в ISP, плюс за спиной курс ROUTE)
    Однако за ссылки на выпуски СДСМ спасибо, думаю обязательно кому-нибудь пригодиться.
    К Вам у меня еще один вопрос. Если Вы используется дефолтные тайминги для OSPF point-to-multipoing nonbroadcast, то это, насколько я помню 30 и 120 секунд.
    То есть, в случае обрыва ISP-1 на бранче, время переключения около 2х минут?
    Также очень интересует как траблшутите и диагностируете проблему, когда у одного из ISP (в бранче) случается деградация сервиса.
    Ну скажем, пинг есть, но скорость меньше заявленной или есть потери 40%.
    В таком случае, вероятно Hello пакеты ходить будут, а реальные данные нет.
    Как избежать этой ситуации, чтобы железо реагировало само, без вмешательства сетевого инженера?

    P.S. У нас в ISP очень мало Cisco, однако есть Extreme, Erricson, Dlihk и Huawei.
    Контрактов по типу TAC нискем из вендоров нет. Все как-то сами обходимся c TSHOOT.
  • отредактировано июня 2016
    feo_sobolev написал:

    NAT_GTX написал:

    feo_sobolev написал:

    Коллеги еще вопрос от новичка, скажите пожалуйста, Вы где покупаете Cisco?
    И какую гарантию Вам предлагают, покупаете с TAC или без?
    И вообще рекомендации.
    Моим заказчикам, предлагает магазин, 3х месячную гарантию без TAC, ну и TAC около 500$ за одну единицу 880й серии, как я понял.

    Если у вас нет контракта нет и поддержки, траблшутинг будет основан на гуглении.
    В случаем поломки железа, не будет моментальной замены на новую, вы будете ждать до 45 дней.
    Коллеги, поправьте меня если я в чем то не прав.
    Спасибо, информация интересная.
    Отсутствие TAC примерно понятно чем грозит, непонятен срок гарантии железа, без покупки TAC - всего 3 месяца.
    То есть, к примеру, в случае брака, через 3 месяца, что-то (тьфу/тфьу) пойдет не так и все :) Заново покупать новую кошку. Как-то это, ну не очень серьзено как мне кажется. Впрочем...

    Насчет блока адресов и своей AS, я Вас понял, удобно, согласен. Что такое AS и PI и PA адреса я знаю, т.к. работаю в ISP, плюс за спиной курс ROUTE)
    Однако за ссылки на выпуски СДСМ спасибо, думаю обязательно кому-нибудь пригодиться.
    К Вам у меня еще один вопрос. Если Вы используется дефолтные тайминги для OSPF point-to-multipoing nonbroadcast, то это, насколько я помню 30 и 120 секунд.
    То есть, в случае обрыва ISP-1 на бранче, время переключения около 2х минут?
    Также очень интересует как траблшутите и диагностируете проблему, когда у одного из ISP (в бранче) случается деградация сервиса.
    Ну скажем, пинг есть, но скорость меньше заявленной или есть потери 40%.
    В таком случае, вероятно Hello пакеты ходить будут, а реальные данные нет.
    Как избежать этой ситуации, чтобы железо реагировало само, без вмешательства сетевого инженера?

    P.S. У нас в ISP очень мало Cisco, однако есть Extreme, Erricson, Dlihk и Huawei.
    Контрактов по типу TAC нискем из вендоров нет. Все как-то сами обходимся c TSHOOT.
    Все верно, это пока не критично для нашей работы, а как только понадобится более быстрая сходимость я приму меры. :)
    Я раньше сам работал в нескольких ISP инженером IP и VoIP, поэтому использую стандартные средства, графики с портов (скорость, дропы, CRC и прочее) по SNMP в заббикс, там все видно.

  • NAT_GTX написал:


    Все верно, это пока не критично для нашей работы, а как только понадобится более быстрая сходимость я приму меры. :)
    Я раньше сам работал в нескольких ISP инженером IP и VoIP, поэтому использую стандартные средства, графики с портов (скорость, дропы, CRC и прочее) по SNMP в заббикс, там все видно.

    Правильно и здорово!
    Однако, иногда, когда беру что-то на аутсорс, бывают случаи, что это дело некому потом поддерживать, по этому, хочется сделать так, чтобы система максимально автоматически реагировала на всевозможные инценденты.
    Так у меня было с проектом на MikroTik для 13 магазинов, где админы, не очень разбираются в сетях. И не вмешиваются вообще в работу сетевого оборудования, практически. А система все переключает быстро сама и траблшутит канал. На предмет если там потери.
    Правда, вот буквально сегодня, на одной из их точек, что находится в другом городе, возникли проблемы с инетом( а ISP у них там один) и им пришлось таки начать траблшутинг.

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

    NAT_GTX написал:


    Все верно, это пока не критично для нашей работы, а как только понадобится более быстрая сходимость я приму меры. :)
    Я раньше сам работал в нескольких ISP инженером IP и VoIP, поэтому использую стандартные средства, графики с портов (скорость, дропы, CRC и прочее) по SNMP в заббикс, там все видно.

    Правильно и здорово!
    Однако, иногда, когда беру что-то на аутсорс, бывают случаи, что это дело некому потом поддерживать, по этому, хочется сделать так, чтобы система максимально автоматически реагировала на всевозможные инценденты.
    Так у меня было с проектом на MikroTik для 13 магазинов, где админы, не очень разбираются в сетях. И не вмешиваются вообще в работу сетевого оборудования, практически. А система все переключает быстро сама и траблшутит канал. На предмет если там потери.
    Правда, вот буквально сегодня, на одной из их точек, что находится в другом городе, возникли проблемы с инетом( а ISP у них там один) и им пришлось таки начать траблшутинг.

    Забыл упомянуть чтобы железо реагировало само, на удалённых точках настраиваем например IP SLA icmp-jitter, но опять же при условии что в филиале есть 2 ISP.
    В случае с BGP в головном офисе и двумя ISP и двумя роутерами нам нужна будет /23 чтобы в каждый ISP анонсировать свою /24 и суммарный маршрут /23. Но можно обойтись и всего одной /24, просто в случае падения активного канала, нужно будет немного подождать пока перестроится BGP. Между роутерами настраиваем IBGP, это не сложно.

    На каждом хабе основной и резервный туннели. По хорошему у спока должно быть 4 туннеля. В работе и жизни бывает абсолютно различные ситуации, а этим нехитрым способом мы увеличиваем отказоустойчивость сети :smile:
  • отредактировано ноября 2016
    NAT_GTX написал:



    Забыл упомянуть чтобы железо реагировало само, на удалённых точках настраиваем например IP SLA icmp-jitter, но опять же при условии что в филиале есть 2 ISP.
    В случае с BGP в головном офисе и двумя ISP и двумя роутерами нам нужна будет /23 чтобы в каждый ISP анонсировать свою /24 и суммарный маршрут /23. Но можно обойтись и всего одной /24, просто в случае падения активного канала, нужно будет немного подождать пока перестроится BGP. Между роутерами настраиваем IBGP, это не сложно.

    На каждом хабе основной и резервный туннели. По хорошему у спока должно быть 4 туннеля. В работе и жизни бывает абсолютно различные ситуации, а этим нехитрым способом мы увеличиваем отказоустойчивость сети :smile:

    Расскажите пожалуйста подробнее про то, как именно вы прикрутили icmp-jitter к OSPF. Через EEM меняете Cost на OSPF?
    Насчет 4 туннеля на каждом споке, абсолютно согласен. В предыдущем проекте, я реализовал именно таким способом. Правда делал на статике и скриптами и на MikroTik, теперь хочу попробовать сделать через OSPF, вероятно сначала будет построено на MikroTik, а в будущем переведут на Cisco. Впрочем, не факт, если на MikroTik будет хорошо работать, а причин чтобы на MikroTik работало "не хорошо" я не вижу :)
  • отредактировано июня 2016
    NAT_GTX написал:


    В случае с BGP в головном офисе и двумя ISP и двумя роутерами нам нужна будет /23 чтобы в каждый ISP анонсировать свою /24 и суммарный маршрут /23. Но можно обойтись и всего одной /24, просто в случае падения активного канала, нужно будет немного подождать пока перестроится BGP. Между роутерами настраиваем IBGP, это не сложно.

    Для более быстрой конвергенции, можете уменьшить KeepAlive таймер на BGP с ISP, по умолчанию это 180 секунд - 3 минуты, но если один из пиров выставит на своей стороне более меньший интервал, то другой будет использовать его автоматически. Можете уменьшить до одной минуты.
    А какие модели Cisco используете в центральном офисе?

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

    NAT_GTX написал:



    Забыл упомянуть чтобы железо реагировало само, на удалённых точках настраиваем например IP SLA icmp-jitter, но опять же при условии что в филиале есть 2 ISP.
    В случае с BGP в головном офисе и двумя ISP и двумя роутерами нам нужна будет /23 чтобы в каждый ISP анонсировать свою /24 и суммарный маршрут /23. Но можно обойтись и всего одной /24, просто в случае падения активного канала, нужно будет немного подождать пока перестроится BGP. Между роутерами настраиваем IBGP, это не сложно.

    На каждом хабе основной и резервный туннели. По хорошему у спока должно быть в апе 4 туннеля. В работе и жизни бывает абсолютно различные ситуации, а этим нехитрым способом мы увеличиваем отказоустойчивость сети :smile:

    Расскажите пожалуйста подробнее про то, как именно вы прикрутили icmp-jitter к OSPF. Через EEM меняете Cost на OSPF?
    Насчет 4 туннеля на каждом споке, абсолютно согласен. В предыдущем проекте, я реализовал именно таким способом. Правда делал на статике и скриптами и на MikroTik, теперь хочу попробовать сделать через OSPF, вероятно сначала будет построено на MikroTik, а в будущем переведут на Cisco. Впрочем, не факт, если на MikroTik будет хорошо работать, а причин чтобы на MikroTik работало "не хорошо" я не вижу :)
    Про icmp-jitter к OSPF не понял вопроса. OSPF это просто IGP, как ты настроишь на хабе, такие приоритеты и будут у маршрутов в данной топологии point-to-multipoint. Ip sla icmp-jitter это просто мониторинг состояния каналов, в случае падения основного канала идет переключение на резерв, понятно что к этим событиям можно прикрутить особые условия поведения, например роутмапы или EEM (а тут все что угодно).
    Event manager, штука полезная, но я в данном случае обхожусь статическим указанием стоимости пути на хабе.
    Имеем 4 туннеля на споке, но по факту работает только один или два (все зависит нужна ли балансировка нагрузки), а настроить можно как угодно :)
Войдите или Зарегистрируйтесь чтобы комментировать.