Комментарии 67
Не смущает, что EoIP не шифруется в данном случае?
а шифрование в данном случае добавляется элементарно. IPSec с политиками, реагирующими на EoIP.
Не надо там этого, если внимательно читать доку.
В Eoip уже была дабавленна поддержка ipsec.
Пример:
/interface eoip add comment=«To SkyNet» name=«To SkyNet EoIP» remote-address=2.2.2.2 tunnel-id=0 ipsec-secret=jfv0wev9rg356bg1
Хотя тот же meshbird и tinc намного проще в разы, но под mikrotik мы их не увидем.
В Eoip уже была дабавленна поддержка ipsec.
Пример:
/interface eoip add comment=«To SkyNet» name=«To SkyNet EoIP» remote-address=2.2.2.2 tunnel-id=0 ipsec-secret=jfv0wev9rg356bg1
Хотя тот же meshbird и tinc намного проще в разы, но под mikrotik мы их не увидем.
У меня в голове "общее" решение. Возможно, попытавшись настроить EoIP в условиях автора, я бы заметил и настроил встроенную поддержку, просто я аналогичную задачу всегда решал с помощью GRE.
Принципиально мой ответ означает, что проблема добавки шифрования здесь выеденного яйца не стоит, даже если бы специальной конфигурации не было — можно было бы реализовать стандартными средствами.
Да-а, это хорошо, конечно, но когда точек пять и везде по два интернета, это начинает раздражать. (Я знаю по себе, строил и эксплуатирую такую сеть, только у нас GRE и зашифровано IPSec)
DMVPN не хватает. Ну или хотя бы умел бы микротик статический multipoint GRE, хотя бы статически настроено было бы — ну один или два тоннеля с каждой стороны, но не столько
DMVPN не хватает. Ну или хотя бы умел бы микротик статический multipoint GRE, хотя бы статически настроено было бы — ну один или два тоннеля с каждой стороны, но не столько
Да, раздражает, но тем не менее на восьми точках вполне работало на момент написания. С тех пор все сильно поменялось и фирма таки арендовала L2VPN между всеми офисами, так что теперь там все гораздо скучнее — просто IPSec с OSPF.
Не совсем понял, почему стало скучнее. Предполагаю, что L2VPN у вас всё-таки резервируется.
Возможно, из-за незнания особенностей данного оборудования я что-то упускаю, но разве удобно использовать чистый IPSec и OSPF? Ведь в настройках политик IPSec приходится жёстко прописывать, трафик который будет шифроваться. А это самым отрицательным образом начинает сказываться на гибкости в работе сети (добавление новых подсетей, передачи интернет трафика через туннели, например, при NAT публикациях и пр.).
Возможно, из-за незнания особенностей данного оборудования я что-то упускаю, но разве удобно использовать чистый IPSec и OSPF? Ведь в настройках политик IPSec приходится жёстко прописывать, трафик который будет шифроваться. А это самым отрицательным образом начинает сказываться на гибкости в работе сети (добавление новых подсетей, передачи интернет трафика через туннели, например, при NAT публикациях и пр.).
Резервируется. Еще одним L2VPN. Насчет удобства — да, вполне. В рамках этой сети нет нужды гонять интернет трафик через внутреннюю сеть между локациями, там гуляет исключительно локальный трафик. Соответственно и политики настроены на шифрование всего идущего в приватную сеть.
В таком случае, почему изначально стоили туннели EoIP? Почему было не достаточно чистого IPSec и OSPF?
чистый ipsec — tunnel mode имеете ввиду?
Да
Ниже в комментах есть ответ на этот вопрос — изначально по историческим причинам оставили EoIP, а позже при первой возможности перешли на L2VPN + на момент написания статьи наши микротики как-то странно криво работали с tunnel mode IPSec — при увеличении количества туннелей до 5 и выше начинали дропать часть трафика. Разбираться было некогда, так что построили на базе имевшегося, а позже уже сделали нормально.
скрипты решают, когда филиалов/бранчей более 3-ёх, ибо на 20 роутеров добавить ещё 1 тоннель, заоспефить его и не облажаться, нужно быть магом.
В целом направление выбрано верное, я лишь отмечу несколько недочетов:
1) Не стоит использовать CCR в корпоративных сетях. Да, в нем больше процессорных ядер, но для обработки IPsec и туннелей он использует одно ядро. В 1100 AHx2 работают оба ядра и каждый из них быстрее ядер в CCR. Купив CCR вы заплатили лишнего и только ухудшили инфраструктуру.
2) В вашей схеме развертывания (1 роутер, 2 провайдера) скорее всего исходящий трафик во всех туннелях идет через основного провайдера. Балансировку трафика вы получаете только для входящего трафика. Чтобы туннели у вас действительно грузили обоих провайдеров, вам нужно прописывать соответствующие статические маршруты до внешних адресов соседних микротиков — чтобы исходящий трафик до принимающей стороны шел через нужного провайдера.
3) Очень странно, что вы зарезервировали каналы интернет и даже электричество, а микротики не зарезервировали. В вашей схеме вам ничего не стоит сделать схему 1 провайдер — 1 микротик, добавить VRRP протокол и сделать по настоящему отказоустойчивое решение.
4) Решение использовать проприентарный протокол EoIP лично я считаю недальновидным. При прочих равных я бы предпочел использовать GRE или IPIP.
5) За использование адресов 192.168.0.0 и 192.168.1.0 я бы расстреливал. Надеюсь, что в рабочей сети у вас таких адресов нет.
6) В качестве area-id лучше использовать адрес loopback интерфейса, а не маршутизируемого интерфейса.
7) Про ipsec уже говорили, добавлю только, что если он у вас не используется и если у вас действительно сделан full-mesh, то, чисто теоетически, ничто не мешает врезавшись в линию в одном из допофисов, перенаправить трафик ото всех офисов через снифер используя фейковые данные ospf. Но это уже немного космос :)
8) Именование туннелей лучше делать более информативными, чем «один, два, три, тридцатьтри» — в дальнейшем при траблешутинге ой как пригодится.
1) Не стоит использовать CCR в корпоративных сетях. Да, в нем больше процессорных ядер, но для обработки IPsec и туннелей он использует одно ядро. В 1100 AHx2 работают оба ядра и каждый из них быстрее ядер в CCR. Купив CCR вы заплатили лишнего и только ухудшили инфраструктуру.
2) В вашей схеме развертывания (1 роутер, 2 провайдера) скорее всего исходящий трафик во всех туннелях идет через основного провайдера. Балансировку трафика вы получаете только для входящего трафика. Чтобы туннели у вас действительно грузили обоих провайдеров, вам нужно прописывать соответствующие статические маршруты до внешних адресов соседних микротиков — чтобы исходящий трафик до принимающей стороны шел через нужного провайдера.
3) Очень странно, что вы зарезервировали каналы интернет и даже электричество, а микротики не зарезервировали. В вашей схеме вам ничего не стоит сделать схему 1 провайдер — 1 микротик, добавить VRRP протокол и сделать по настоящему отказоустойчивое решение.
4) Решение использовать проприентарный протокол EoIP лично я считаю недальновидным. При прочих равных я бы предпочел использовать GRE или IPIP.
5) За использование адресов 192.168.0.0 и 192.168.1.0 я бы расстреливал. Надеюсь, что в рабочей сети у вас таких адресов нет.
6) В качестве area-id лучше использовать адрес loopback интерфейса, а не маршутизируемого интерфейса.
7) Про ipsec уже говорили, добавлю только, что если он у вас не используется и если у вас действительно сделан full-mesh, то, чисто теоетически, ничто не мешает врезавшись в линию в одном из допофисов, перенаправить трафик ото всех офисов через снифер используя фейковые данные ospf. Но это уже немного космос :)
8) Именование туннелей лучше делать более информативными, чем «один, два, три, тридцатьтри» — в дальнейшем при траблешутинге ой как пригодится.
1) ccr ipsec 1,8 гигабита
rb1100ahx2 до 1 гигабита (c тюнингом) чуток не хватало
Но есть нюанс, 1 тоннель = 1 ядро, я так понял
2) Тоннели на разные провайдеры, если верить разным буковкам вместо ip. Балансирует у автора OSPF (ECMP), правильнее делать бонд из тоннелей тогда уж, но равноценных линков я ещё не встречал, а траблешутить дропы ему, видимо, ещё придётся.
3) тогда уж BGP
4) GRE медленней (нагрузка cpu)
7) оспф поломать просто, он у него беспарольный, и скорей всего, по дефолту, анонсится на все интерфейсы, network-то описан.
Ну и bfd не в ethernet всё-таки чересчур, имхо
rb1100ahx2 до 1 гигабита (c тюнингом) чуток не хватало
Но есть нюанс, 1 тоннель = 1 ядро, я так понял
2) Тоннели на разные провайдеры, если верить разным буковкам вместо ip. Балансирует у автора OSPF (ECMP), правильнее делать бонд из тоннелей тогда уж, но равноценных линков я ещё не встречал, а траблешутить дропы ему, видимо, ещё придётся.
3) тогда уж BGP
4) GRE медленней (нагрузка cpu)
7) оспф поломать просто, он у него беспарольный, и скорей всего, по дефолту, анонсится на все интерфейсы, network-то описан.
Ну и bfd не в ethernet всё-таки чересчур, имхо
2) Тоннели на разные провайдеры, если верить разным буковкам вместо ip. Балансирует у автора OSPF (ECMP), правильнее делать бонд из тоннелей тогда уж, но равноценных линков я ещё не встречал, а траблешутить дропы ему, видимо, ещё придётся.
Да, тоннели у него на разные провайдеры. Вот только если у маршрутизатора шлюз по умолчанию через интерфейс 1, то он все пакеты во вне по умолчанию будет слать через этот интерфейс, вне зависимости от того, какой в пакете будет стоят source IP. В итоге исходящий трафик в тоннеле 2, который, теоретически, должен уходить через интерфейс 2, уходит во вне через интерфейс 1.
lookup решает, я вас понял. Автор много не учёл. Но, в принципе, вариант рабочий, хоть и с кучей оговорок :)
Автор учел многое, но вот конфиг из прода автору выложить не дали, даже на конфиге из лабы сильно попросили потереть все адреса и все, что могло указать на фирму. По сути, выложенный мануал и конфиг показывают как это настроить чтобы вообще заработало, а вот доп. мелочи типа правил mangle для корректной работы обоих провайдеров вместе, маршрутов на внешние IP точек, шифрования трафика и т.д. можно настроить по надобности.
Вот про ядра вопрос интересный: по доке http://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Hardware_encryption поддержка и там, и там сделана «на ядрах», а не на одном ядре. Вот как уже балансировка работает, если туннелей несколько — вопрос интересный, сам Mikrotik обычно неохотно рассказывает.
А вы откуда уверены, что CCR использует только 1 ядро?
А вы откуда уверены, что CCR использует только 1 ядро?
А вы откуда уверены, что CCR использует только 1 ядро?
В интернете полно информации по тестированию ipsec на CCR и отзывов недоуменных владельцев. Некоторые факт о использовании одного ядра узнают от поддержки микротика, другие — из наблюдения за загрузкой ядер во время тестирования.
Я в тесте наблюдал как раз загрузку многих ядер, когда много туннелей поднималось. Даже любопытно стало.
Ну и настройки крипто тоже важны. Я тестировал на тех настройках, что рекомендованы (читаем: делай так — не ошибешься), но подозреваю, что с какими-то настройками крипто будет аппаратное, с какими-то — программное, но многоядерное, а с какими-то вообще бы просто завелось, и ладно.
Уже не говоря, что версия от версии отличаются заметно, в т.ч. и по тому, что работает как надо, а что — нет.
Свежие (недавно анонсированные) недорогие машинки стали очень дружить с IPSec, например. http://wiki.mikrotik.com/wiki/Manual:IP/IPsec#HEXv3_.28mmips.29_Config_Optimizations у них немного свои оговорки, как и что надо настраивать, и рекомендации кажутся разумными.
AHx2 https://routerboard.com/RB1100AHx2 вообще интереная железка. Долгожитель, с кулерами, с PPC, грузится долго (на фоне CCR), второго БП в нем нет (тоже на фоше CCR), но при этом продается, используется часто, и сравнительно многими.
Ну и настройки крипто тоже важны. Я тестировал на тех настройках, что рекомендованы (читаем: делай так — не ошибешься), но подозреваю, что с какими-то настройками крипто будет аппаратное, с какими-то — программное, но многоядерное, а с какими-то вообще бы просто завелось, и ладно.
Уже не говоря, что версия от версии отличаются заметно, в т.ч. и по тому, что работает как надо, а что — нет.
Свежие (недавно анонсированные) недорогие машинки стали очень дружить с IPSec, например. http://wiki.mikrotik.com/wiki/Manual:IP/IPsec#HEXv3_.28mmips.29_Config_Optimizations у них немного свои оговорки, как и что надо настраивать, и рекомендации кажутся разумными.
AHx2 https://routerboard.com/RB1100AHx2 вообще интереная железка. Долгожитель, с кулерами, с PPC, грузится долго (на фоне CCR), второго БП в нем нет (тоже на фоше CCR), но при этом продается, используется часто, и сравнительно многими.
Я в тесте наблюдал как раз загрузку многих ядер, когда много туннелей поднималось. Даже любопытно стало.
Вполне может быть так, что один туннель может занять не более одного ядра, но много туннелей могут занять все ядра. В этом случае действительно CCR покажет большую производительность. Я почему-то по своей наивности предпологала, что одно ядро процессора в принципе отвечает за процессинг на одном из портов — возможно, мое предлоложение было ошибочным.
А за что расстреливать в пункте 5? По вашему нужно из 10ой подсети строить?
За использование 192.168.0.0/24 и 192.168.1.0/24, прямо же сказано. Да, за это надо расстреливать, как и за использование VLAN 1.
Дело в том, что все, абсолютно все SOHO железки имеют такие адреса по умолчанию. Если вы, скажем, имеете задачу сделать удалённому пользователю работу VPN, у него дома практически наверняка будет одна из этих сетей. И вы столкнётесь с проблемами: сервер в офисе в 192.168.1.5, вы кидаете клиенту в VPN маршрут до 192.168.1.0/24 через VPN… а у него роутер 192.168.1.1, и подключившись к VPN, он теряет роутер, VPN, интернет и всё на свете.
А поскольку задача возникает всегда, то использовав такие сети вы с этой проблемой столкнётесь всегда. И придётся сеть в офисе — упс — перенумеровывать. Это очень больно.
ну, и по моему опыту, проще линки делать из абсолютно левой сетки, например, 172.16.0.0/12
1) Не стоит использовать CCR в корпоративных сетях. Да, в нем больше процессорных ядер, но для обработки IPsec и туннелей он использует одно ядро. В 1100 AHx2 работают оба ядра и каждый из них быстрее ядер в CCR. Купив CCR вы заплатили лишнего и только ухудшили инфраструктуру.
Откуда это?
Про ядра: CCR1036 — 1.2 GHz Tile, AH1100x2 — 1GHz PPC. Напрямую сравнить Tile с PPC не удастся, но по крайней мере частота в CCR больше.
А про то, как там IPsec и тоннели по ядрам распределяются — хочется подробностей — ссылок там, и так далее. Когда мы заводили на CCR1009 подобную штуку, на синтетических тестах (вроде flood-ping через тоннель) ядра нагружались равномерно. Жаль, что я сейчас туда посмотреть не могу.
1) Пробовали ставить на место CCR 1100AHx2 — не тянул, там по факту кроме туннелей еще и OVPN, DHCP,DNS, куча правил firewall.
2,3,4) С тех пор уже не надо стало — арендовали L2VPN от разных провайдеров, обернули в IPSec и радуемся
5) Естественно нет)) Хотя когда-то были.
6) Возможно, но пока работает — трогать смысла не вижу.
7) OSPF запароленный в проде. Уж извините, но конфиг сюда я копировал с тестового стенда, а не с прода, что, впрочем, не отменяет его работоспособности.
8) Естественно. В проде туннели называются согласно именам локаций в которые собственно они ведут.
2,3,4) С тех пор уже не надо стало — арендовали L2VPN от разных провайдеров, обернули в IPSec и радуемся
5) Естественно нет)) Хотя когда-то были.
6) Возможно, но пока работает — трогать смысла не вижу.
7) OSPF запароленный в проде. Уж извините, но конфиг сюда я копировал с тестового стенда, а не с прода, что, впрочем, не отменяет его работоспособности.
8) Естественно. В проде туннели называются согласно именам локаций в которые собственно они ведут.
IMHO можно для IP туннелей использовать /32 маску, в микротике /31 не работает, а /32 работает нормально
Рисовать схему удобно и красиво можно через draw.io (и онлайн и как приложение хром)
А вот гонять в открытом виде трафик через интернет как-то совсем не айс.
Если у вас есть основная площадка то почему там только один роутер.
Как мониторите такой FullMesh?
А вот гонять в открытом виде трафик через интернет как-то совсем не айс.
Если у вас есть основная площадка то почему там только один роутер.
Как мониторите такой FullMesh?
я не автор, но ipip и eoip отлично мониторится snmp, всё есть в доках
name=.1.3.6.1.2.1.2.2.1.2.14 mtu=.1.3.6.1.2.1.2.2.1.4.14
mac-address=.1.3.6.1.2.1.2.2.1.6.14
admin-status=.1.3.6.1.2.1.2.2.1.7.14
oper-status=.1.3.6.1.2.1.2.2.1.8.14 [b]bytes-in=.1.3.6.1.2.1.2.2.1.10.14 [/b]
packets-in=.1.3.6.1.2.1.2.2.1.11.14
discards-in=.1.3.6.1.2.1.2.2.1.13.14
errors-in=.1.3.6.1.2.1.2.2.1.14.14 [b]bytes-out=.1.3.6.1.2.1.2.2.1.16.14 [/b]
packets-out=.1.3.6.1.2.1.2.2.1.17.14
discards-out=.1.3.6.1.2.1.2.2.1.19.14
errors-out=.1.3.6.1.2.1.2.2.1.20.1
name=.1.3.6.1.2.1.2.2.1.2.14 mtu=.1.3.6.1.2.1.2.2.1.4.14
mac-address=.1.3.6.1.2.1.2.2.1.6.14
admin-status=.1.3.6.1.2.1.2.2.1.7.14
oper-status=.1.3.6.1.2.1.2.2.1.8.14 [b]bytes-in=.1.3.6.1.2.1.2.2.1.10.14 [/b]
packets-in=.1.3.6.1.2.1.2.2.1.11.14
discards-in=.1.3.6.1.2.1.2.2.1.13.14
errors-in=.1.3.6.1.2.1.2.2.1.14.14 [b]bytes-out=.1.3.6.1.2.1.2.2.1.16.14 [/b]
packets-out=.1.3.6.1.2.1.2.2.1.17.14
discards-out=.1.3.6.1.2.1.2.2.1.19.14
errors-out=.1.3.6.1.2.1.2.2.1.20.1
Как я говорил выше — в проде на всех площадках не один роутер по факту, но к теме это отношения имеет мало. За draw.io спасибо, буду иметь ввиду. Мониторим заббиксом по SNMP.
ipsec полиси можно навесить, но вот использовать л2 тоннели вместо «нормальных» — оригинально. Отчего выбрано столь «оригинальное» туннелирование?
при включении bfd не смущает большое количество служебных пакетов (в вашем случае вроде получается 64 пакета за 0.2 секунды )?
при включении bfd не смущает большое количество служебных пакетов (в вашем случае вроде получается 64 пакета за 0.2 секунды )?
Таким образом нас перестали пугать технические работы у провайдера, а также периодические проблемы с проходимостью GRE пакетов по определенным направлениям
Тут автор сам себе противоречит. Протокол EoIP работает на основе инкапсуляции L2-трафика внутрь GRE-пакетов. Достаточно внимательно посмотреть с помощью torch либо сделать tcpdump на транзитном маршрутизаторе.
Не противоречу. Я знаю, что EoIP работает внутри GRE, но перестали данные проблемы пугать за счет большого количества других маршрутов — даже если по какому-либо направлению такие проблемы всплывали — на них просто падал OSPF и по данному туннелю трафик не шел до восстановления корректной работы.
Немного странный выбор pseudo-wire технологии туннелирования, когда для этого есть IPIP/GRE/L2TP и прочие протоколы точка-точка? Были какие-то проблемы с реализацией OSPF/BGP на линках? Изначально EoIP совсем не для этого предназначен.
Так любят строить туннели наши «азиатские партнеры» из Индонезии и близлежащих к ней стран. Там некоторые вообще как дети — набриджуют EoIP туннелей в огромный broadcast-домен и чего-то с ним шаманят, извращаются…
Так любят строить туннели наши «азиатские партнеры» из Индонезии и близлежащих к ней стран. Там некоторые вообще как дети — набриджуют EoIP туннелей в огромный broadcast-домен и чего-то с ним шаманят, извращаются…
автор должен отписать, что в проде у него не так, это конфиг лабораторный :)
EoIP в данном случае был оставлен по историческим причинам — EoIP туннели между основным офисом и каждым из других уже существовали, так что просто достроили недостающие и настроили маршрутизацию. При первой же возможности от этого отказались в пользу L2VPN от провайдеров между всеми локациями.
Классное «просто падал OSPF». А то что при падении одного интерфейса в OSPF, в вашей фул меш топологии, в рамках одной area начинался флудинг по всем n(n-1) линкам (без деления на 2, т.к по два провайдера на каждой ноде), вас видимо не сильно волновало.
флуд-то ещё куда ни шло, хотя выглядит занятно, а вот перестроение маршрутов в area, где link state поменялся…
если не грамотно подойти к разделению на арии, эффект, при количестве маршрутизаторов от 20, будет весьма интересен :)
если не грамотно подойти к разделению на арии, эффект, при количестве маршрутизаторов от 20, будет весьма интересен :)
Флуд выглядит куда занятнее, когда в такой топологии (фул меш с кучей провайдеров) один из провайдеров начинает биться в конвульсиях, прыгая из up в down каждые несколько секунд.
давно не видел
на микротах не видел противодействий данному, есть там по количеству отправляемого-принимаемого?
на микротах не видел противодействий данному, есть там по количеству отправляемого-принимаемого?
Про микротики как то не в курсе
блин, на цисках сие просто, но я с такими проблемами только на них и сталкивался, когда провайдеры дурили
а вот на микротах придумал только фаерволом канал резать для ospf, но это топорно и л3, а хотелось бы повыше уровнем
либо чуть ли не на каждый тоннель арию делать и передать маршруты уже выше lsa3 :)
а вот на микротах придумал только фаерволом канал резать для ospf, но это топорно и л3, а хотелось бы повыше уровнем
либо чуть ли не на каждый тоннель арию делать и передать маршруты уже выше lsa3 :)
чуть ли не на каждый тоннель арию делать и передать маршруты уже выше lsa3
Маршруты между разными area передаются как раз в рамках LSA 3.
а в чем здесь смысл использования л2 туннелей? какой от них профит? чисто чтобы оспф мультикаст мог слать? так это делается куда проще — ptp, и никакого мультикаста. и никаких туннелей к слову не нужно. и нет завязки на проприетарную технологию, которая ни с чем больше не совместима.
к слову, с оспф у микротика все очень печально по части реализации — вплоть до закольцовывания маршрутов, поймете как только появится более одной area…
к слову, с оспф у микротика все очень печально по части реализации — вплоть до закольцовывания маршрутов, поймете как только появится более одной area…
EoIP исключительно по историческим причинам, а насчет OSPF на микротике — возможно и печально, но работает нормально в наших условиях.
Прямо заинтриговали. В системе несколько областей. В том числе не тупиковых. ASBR взаимодействует с quagga. Всё живет нормально. Возможно дело в правильной настройке ABR, инстансов и Area Ranges?
За исключением глюка, когда сразу после интенсивной настройки/переконфигурации, требуется рестартовать инстанс, других не попадалось.
Поделитесь примерами топологии и конфигов при закольцовывании. Можно в личку, поскольку чуть оффтоп.
За исключением глюка, когда сразу после интенсивной настройки/переконфигурации, требуется рестартовать инстанс, других не попадалось.
Поделитесь примерами топологии и конфигов при закольцовывании. Можно в личку, поскольку чуть оффтоп.
около 20 area, около 300 сетей, началась война и немцы, из того, что я смог натраблешутить в bird/quagga — с неправильным подсчётом костов, Маршруты в микротик выбирались неоптимально и не симметрично, пришлось лепить кучу рулесов в микроте, делать кучу инстансов. Тупиковые-то как раз нормально работают :)
И это я ещё суммаризацию отключил. Ладно хоть в новых прошивках применение умных рулесов излечили, раньше (с год назад) надо было ребутить роутер, моргание демоном не помогало :)
коротко — примерно в такой топологии маршруты начинают весело кольцеваться:
где A1..A4 — разные area
где-то было описание этого случая на наге, но что-то с ходу найти не могу.
A1 - A2
| .. |
A3 - A4
где A1..A4 — разные area
где-то было описание этого случая на наге, но что-то с ходу найти не могу.
Классический подход администраторов miktorik. На форуме сетевиков nag.ru есть пара фанатов Mikrotik, которые предлагают использовать mikrotik в любых местах, где спрашивают помощи. Так и здесь: для L3 сети не нужны L2 технологии вроде EOIP. Нужны ipip или OpenVPN в режиме L3. А для обмена маршрутами BGP. Как минимум сэкономить на L2 заголовках, которые для конечных устройств не нужны, как максимум управлять анонсами более оптимально. Я не говорю, что EOIP и OSPF плохи, но они для других ситуаций предназначены.
А передавать по арендуемым L2-каналам OSPF опасно — никто не даст вам 100% гарантии прохождения multicast. Когда-нибудь оно сломается может и не по Вашей вине. С BGP unicast такого точно не произойдет.
А передавать по арендуемым L2-каналам OSPF опасно — никто не даст вам 100% гарантии прохождения multicast. Когда-нибудь оно сломается может и не по Вашей вине. С BGP unicast такого точно не произойдет.
bgp дольше сходимость, и чё-то все мои знакомые, любящие микрот, бгп крутят на кошках с джунами :)
openvpn не советую вообще, мало того, что rtt добавляет, да ещё и рандомно при нагрузке большой, дык ещё и тормозной, без сжатия и в TCP
openvpn не советую вообще, мало того, что rtt добавляет, да ещё и рандомно при нагрузке большой, дык ещё и тормозной, без сжатия и в TCP
объясните в чем дольше сходимость BGP? В первом установлении TCP-сессии? Пусть Ваши знакомы продолжают крутить — я не об это говорил. OpenVPN с шифрованием работает быстрее чем EoIP, завернутый в ipsec. OpenVPN можно гонять и через UDP. Еще плюсом является кроссплатформенность и возможность пройти через NAT в отличии от GRE, но здесь это возможно не существенно.
блин, ну наверно в значениях таймеров по умолчанию, RFC 4271 (30 секунд) х (3 кипалива) = 90, причём в разном оборудовании значение периода от 30 до 180 может быть.
для оспф 10х4
в данном случае рассматриваем ibgp или ebgp? там разные периоды рассылки изменений
на микротах нет UDP
по моим тестам openvpn медленнее ipip, и даже без разницы что на другой стороне: микрот, линукса, винда, всё зависит от количества пакетов, при моих нагрузках больше 80мегабит в одном канале я не смог родить.
Цифры для EOIP должны отличаться на 10% максимум, т.к. с eoip я тоже жил, ибо по-другому л2 не прокинуть, а мплс на мини микротах очень медленный
про eoip я вообще не говорил, его использование для меня — дикость
для оспф 10х4
в данном случае рассматриваем ibgp или ebgp? там разные периоды рассылки изменений
на микротах нет UDP
по моим тестам openvpn медленнее ipip, и даже без разницы что на другой стороне: микрот, линукса, винда, всё зависит от количества пакетов, при моих нагрузках больше 80мегабит в одном канале я не смог родить.
Цифры для EOIP должны отличаться на 10% максимум, т.к. с eoip я тоже жил, ибо по-другому л2 не прокинуть, а мплс на мини микротах очень медленный
про eoip я вообще не говорил, его использование для меня — дикость
Оффтоп по времени сходимости. Очень наглядный пример — это одновременное использование и bgp и igp. Тот самый случай, когда мы получаем black hole из-за того что, к примеру, ospf уже поднялся, а bgp ещё нет. Не зря придумали overload механизмы для «запрета» прохождения транзитного трафика: overload bit (is-is), max-metric (ospf). Помимо стандартных таймеров там есть опция «жди меня», а точнее «жди его» — дождаться пока поднимется братюня bgp и только потом возвращать работу igp в штатный режим. Eigrp в этом плане нервно курит в сторонке.
бгп на микротике убого и ущербно от рождения. мало того что разрабы не отличают rib от fib и все пихают в kernel routing table, так оно еще и эпически тормозное + никак не параллелится. и итоге при флапе 2 пиров с full view 72-ядерная поделка за 3000 мертвых президентов обновляет маршруты в течение 20-30 минут. а в обычном состоянии одно из ядрышек постоянно нагружено на 100% бгп процессом — потому что в интернете где-то периодически что-то отпадает/подключается, а при скорости изучения порядка пары десятков маршрутов в секунду работа ядрышку есть всегда.
ну и прочие «мелочи», как к примеру отсутствие нормальной поддержки приема анонсов от route reflector, с next nop не из connected/static (пример: узел 1.1.1.1 анонсит дефолт через 2.2.2.2 и 2.2.2.0/24 через 1.1.1.1 — микротик это не поймет и сделает default unreachable).
а для быстрой сходимости есть bfd…
ну и прочие «мелочи», как к примеру отсутствие нормальной поддержки приема анонсов от route reflector, с next nop не из connected/static (пример: узел 1.1.1.1 анонсит дефолт через 2.2.2.2 и 2.2.2.0/24 через 1.1.1.1 — микротик это не поймет и сделает default unreachable).
а для быстрой сходимости есть bfd…
про bfd и так ясно
А с RR вообще возможно как-то на микроте?
у меня ни сделать, ни пообщаться не получилось, только руками/скриптами, только хардкор, но в продакшен я это не пихнул, оно как бы есть и заявлено, но ожидаемый результат получается как-то не так, как хотелось бы. Такое чувство, что микротом можно только натить/чуток_фаерволить (исключительно cisco ASA style). Как только начинаешь изображать что-то умное, выскакивает куча ограничений, многотунелье не любит, динамику не понимает, над фулвьюшечкой думает, роутинг с блокируемой коммутацией получается, VRRP не выгоден, куча правил в фаере тож с трудом переваривается. Такой он, для очень вялого энтерпрайза, дешёвый pps спасает. Ну нет у них желания влезать в нормальные сети.
А с RR вообще возможно как-то на микроте?
у меня ни сделать, ни пообщаться не получилось, только руками/скриптами, только хардкор, но в продакшен я это не пихнул, оно как бы есть и заявлено, но ожидаемый результат получается как-то не так, как хотелось бы. Такое чувство, что микротом можно только натить/чуток_фаерволить (исключительно cisco ASA style). Как только начинаешь изображать что-то умное, выскакивает куча ограничений, многотунелье не любит, динамику не понимает, над фулвьюшечкой думает, роутинг с блокируемой коммутацией получается, VRRP не выгоден, куча правил в фаере тож с трудом переваривается. Такой он, для очень вялого энтерпрайза, дешёвый pps спасает. Ну нет у них желания влезать в нормальные сети.
микротик ни разу не для энтерпрайза. обычная сохо поделка, пускай и перекачанная стероидами. ибо подход к софтописательству — типичный сохо: мы тут вам наговнякали 100500 плюшек, и они вроде как должны работать, но плюшка А вешает систему когда включена плюшка В, плюшка С работает не по стандарту т.к. индус, ее писавший, стандарт не понял (либо вообще не читал), а в плюшке D есть critical bug, допускающий remote DoS атаку — но править мы его вот прямо сейчас не будем, потому что за багфиксы деньги не платят, может, если вам повезет, лет через 5 пофиксим, а пока — пользуйтесь тем что есть. и да, никакого сервис-контракта, по которому отказавшую железку заменят в течение суток-двух, а всплывший баг исправят за адекватные сроки, тоже нет, в принципе. а сервис-контракт — основное требование энтерпрайза.
ИМХО микротик — скорее для тех, кто не осилил *nix и не любит думать — т.к. есть 100500 гайдов, как сконфигурить что-то, с расписанным порядком куда ткнуть мышкой для получения результата.
а с RR — пообщаться получится только если напихать микротику маршруты к аплинкам статикой через RR. возможно — еще получится если маршруты будут получаться не статикой а через ospf/rip, но не пробовал.
ИМХО микротик — скорее для тех, кто не осилил *nix и не любит думать — т.к. есть 100500 гайдов, как сконфигурить что-то, с расписанным порядком куда ткнуть мышкой для получения результата.
а с RR — пообщаться получится только если напихать микротику маршруты к аплинкам статикой через RR. возможно — еще получится если маршруты будут получаться не статикой а через ospf/rip, но не пробовал.
а сервис-контракт — основное требование энтерпрайза.
ну, в случае с микротиком дешевле купить ящик резервных железок
каким образом ящик резервных железок позволит бороться с багами в софте/особенностями используемых сохо компонентов (свиччипы, эзернет чипы и т.п.)? вы вообще с энтерпрайзом и их требованиями сталкивались? там, где час простоя обходится суммой с 3-4 и более нулями, ессно мертвых президентов?
а багов таки имеется. к примеру, вис микротика наглухо при частых ssh коннектах (порядка нескольких коннектов в секунду) — эту багу фиксили более 3 лет (!). или из относительно свеженького (вроде еще непофиксенного) — вис при переполнении коннтрака… и по железу там часто все печально — тот же встроенный свич в rb2011 к примеру при наличии в л2 сегменте более 50-70 маков превращается в хаб из-за колизий хешей (спасибо дешевому AR8337), начинает рассылать трафик во все свои порты, и бороться можно только свичуя (бриджуя) все на и так чахлом проце; на тех же CCR с гигабитными портами распаяны сетевые адаптеры atheros которые на 500-600 мбитах реального трафика с мелкими пакетами начинают превращаться в тыкву, и т.п.
ну и да, микротики по цене не дешевле б/у циски/джунипера сравнительной производительности.
а багов таки имеется. к примеру, вис микротика наглухо при частых ssh коннектах (порядка нескольких коннектов в секунду) — эту багу фиксили более 3 лет (!). или из относительно свеженького (вроде еще непофиксенного) — вис при переполнении коннтрака… и по железу там часто все печально — тот же встроенный свич в rb2011 к примеру при наличии в л2 сегменте более 50-70 маков превращается в хаб из-за колизий хешей (спасибо дешевому AR8337), начинает рассылать трафик во все свои порты, и бороться можно только свичуя (бриджуя) все на и так чахлом проце; на тех же CCR с гигабитными портами распаяны сетевые адаптеры atheros которые на 500-600 мбитах реального трафика с мелкими пакетами начинают превращаться в тыкву, и т.п.
ну и да, микротики по цене не дешевле б/у циски/джунипера сравнительной производительности.
Опенвпн на микротике? Лучше бы его там совсем не было, чем этот огрызок.
А передавать по арендуемым L2-каналам OSPF опасно — никто не даст вам 100% гарантии прохождения multicast.
Вот с этим вынужден согласиться. Сам наелся, и на цисках, а не на микротиках. Уже не помню, к чему там в итоге пришли, к nbma или что-то ещё изобретали.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Настройка FullMesh сети на Mikrotik через EoIP туннели