Начальная ситуация такая: есть 8 офисов в разных частях страны, надо их свести в единую сеть так, чтобы доступность каждого офиса была максимальной при любых катаклизмах. В качестве роутеров во всех офисах стоят Mikrotik. На основной площадке — CCR CCR1036-12G, на остальных — 1100 AHx2

Во избежание проблем с интернетом было протянуто по 2 канала от разных провайдеров, питание тоже зарезервировали и пришли к вопросу “а какую сеть-то строить?”. Как видно из названия статьи, в итоге решили строить FullMesh.

Эта схема полностью удовлетворяет требованиям руководства — при выходе из строя любого интернет-канала или даже любого офиса сеть остается связной. Остался только вопрос с маршрутизацией. Из вариантов был всеобщий бридж с RSTP, OSPF и статические маршруты. Естественно я в итоге выбрал OSPF — меньше проблем, чем на статике и меньше нагрузки для маршрутизаторов, чем при RSTP.

Сама настройка и готовый конфиг под катом.

Соединять маршрутизаторы решил с помощью EoIP туннелей, по 2 на каждую пару — с основного провайдера на основной и с резервного на резервный. Конфигурацию опишу для одной пары, так как остальные настраиваются идентично.

На первом маршрутизаторе создаем 2 туннеля:

/interface eoip
ladd keepalive=1s,3 local-address=xxx.xxx.xxx.xxx  name=FIRST remote-address=yyy.yyy.yyy.yyy tunnel-id=1
add keepalive=1s,3 local-address=zzz.zzz.zzz.zzz  name=FIRST_BAK remote-address=www.www.www.www tunnel-id=2

Поднимаем туннели со второй стороны:

/interface eoip
ladd keepalive=1s,3 local-address=yyy.yyy.yyy.yyy   name=FIRST remote-address=xxx.xxx.xxx.xxx tunnel-id=1
add keepalive=1s,3 local-address=www.www.www.www  name=FIRST_BAK remote-address=zzz.zzz.zzz.zzz tunnel-id=2

Настраиваем OSPF, маршрутами будем обмениваться через зону backbone.

На первом маршрутизаторе:

/routing ospf area
add area-id=192.168.0.1 name=FIRST

/routing ospf interface
add cost=10 dead-interval=5s hello-interval=1s interface=FIRST     network-type=point-to-point use-bfd=yes
add cost=10 dead-interval=5s hello-interval=1s interface=FIRST_BAK     network-type=point-to-point use-bfd=yes

/routing ospf network
add area=FIRST network=192.168.0.0/24
add area=backbone network=10.0.0.0/22

На втором маршрутизаторе:

/routing ospf area
add area-id=192.168.1.1 name=SECOND

/routing ospf interface
add cost=10 dead-interval=5s hello-interval=1s interface=FIRST     network-type=point-to-point use-bfd=yes
add cost=10 dead-interval=5s hello-interval=1s interface=FIRST_BAK     network-type=point-to-point use-bfd=yes

/routing ospf network
add area=SECOND network=192.168.1.0/24
add area=backbone network=10.0.0.0/22

И наконец добавляем адреса для созданных туннелей:

На первом маршрутизаторе:

ip address add address=10.0.1.1/30 interface=FIRST network=10.0.1.0
ip address add address=10.0.1.5/30 interface=FIRST_BAK network=10.0.1.4

На втором маршрутизаторе:

ip address add address=10.0.1.2/30 interface=FIRST network=10.0.1.0
ip address add address=10.0.1.6/30 interface=FIRST_BAK network=10.0.1.4

Получаем 2 маршрутизатора, которые обмениваются маршрутами на свои зоны по OSPF. Повторяем данную процедуру для всех пар маршрутизаторов.

В итоге получаем вот такую FullMesh сеть (заранее прошу прощения за качество схемы — не нашел чем адекватно рисовать схему сети на Linux, потому использовал онлайн рисовалку Gliffy):



Все маршрутизаторы входят в общую backbone area с id 0.0.0.0 + каждый из них является пограничным для своей собственной зоны с ID равным локальному IP маршрутизатора.

Сразу после того, как маршрутизаторы обнаруживают друг друга, они обмениваются известными им маршрутами, и на основании стоимости линка выбирают лучшие. В данной конфигурации лучшим маршрутом всегда будет самый прямой (точнее 2 прямых маршрута — основной и резервный), в случае отказа которого трафик, идущий через отказавший маршрут будет доставлен через все маршрутизаторы, оставшиеся доступными.

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

Если у вас возникнут вопросы или предложения по оптимизации данной конфигурации — добро пожаловать в комментарии.

Как и обещал, готовый конфиг одного из маршрутизаторов (все имена и IP изменены по соглашению со службой безопасности):

Конфиг
# aug/23/2015 19:15:28 by RouterOS 6.30.2
# software id = 4RCZ-RTPX
#

/interface ethernet
set [ find default-name=ether10 ] mac-address=4C:5E:0C:5A:64:22 name=    ISP2
set [ find default-name=ether1 ] mac-address=4C:5E:0C:5A:64:19
set [ find default-name=ether2 ] mac-address=4C:5E:0C:5A:64:1A master-port=    ether1
set [ find default-name=ether3 ] mac-address=4C:5E:0C:5A:64:1B master-port=    ether1
set [ find default-name=ether4 ] mac-address=4C:5E:0C:5A:64:1C master-port=    ether1
set [ find default-name=ether5 ] mac-address=4C:5E:0C:5A:64:1D master-port=    ether1
set [ find default-name=ether6 ] mac-address=4C:5E:0C:5A:64:1E
set [ find default-name=ether7 ] mac-address=4C:5E:0C:5A:64:1F
set [ find default-name=ether8 ] mac-address=4C:5E:0C:5A:64:20
set [ find default-name=ISP1 ] mac-address=4C:5E:0C:5A:64:21 name=ISP1
set [ find default-name=ether11 ] mac-address=4C:5E:0C:5A:64:23
set [ find default-name=ether12 ] mac-address=4C:5E:0C:5A:64:24
set [ find default-name=ether13 ] mac-address=4C:5E:0C:5A:64:25
/interface eoip
add keepalive=1s,3 local-address=xxx.xxx.xxx.xxx mac-address=02:74:DC:6B:70:C1     name=FIRST remote-address=xxx.xxx.xxx.xxx tunnel-id=1
add keepalive=1s,3 local-address=xxx.xxx.xxx.xxx mac-address=02:74:DC:6B:70:C1     name=FIRST_BAK remote-address=xxx.xxx.xxx.xxx tunnel-id=2
add keepalive=1s,3 local-address=xxx.xxx.xxx.xxx mac-address=02:B8:B3:AB:DB:17     name=SECOND remote-address=xxx.xxx.xxx.xxx tunnel-id=3
add keepalive=1s,3 local-address=xxx.xxx.xxx.xxx mac-address=02:3B:12:E5:7E:BC     name=SECOND_BAK remote-address=xxx.xxx.xxx.xxx tunnel-id=4
add keepalive=1s,3 local-address=xxx.xxx.xxx.xxx mac-address=02:3B:12:E5:7E:BC     name=THIRD remote-address=xxx.xxx.xxx.xxx tunnel-id=5
add keepalive=1s,3 local-address=xxx.xxx.xxx.xxx mac-address=02:B8:B3:AB:DB:17     name=THIRD_BAK remote-address=xxx.xxx.xxx.xxx tunnel-id=6
add keepalive=1s,3 local-address=xxx.xxx.xxx.xxx mac-address=02:B8:B3:AB:DB:17     name=FOURTH remote-address=xxx.xxx.xxx.xxx tunnel-id=7
add keepalive=1s,3 local-address=xxx.xxx.xxx.xxx mac-address=02:3B:12:E5:7E:BC     name=FOURTH_BAK remote-address=xxx.xxx.xxx.xxx tunnel-id=8
add keepalive=1s,3 local-address=xxx.xx.xxx.xxx mac-address=02:3B:12:E5:7E:BC     name=FIFTH remote-address=xxx.xxx.xxx.xxx tunnel-id=9
add keepalive=1s,3 local-address=xxx.xxx.xxx.xxx mac-address=02:B8:B3:AB:DB:17     name=FIFTH_BAK remote-address=xxx.xxx.xxx.xxx tunnel-id=10
add keepalive=1s,3 local-address=xxx.xxx.xxx.xxx mac-address=02:B8:B3:AB:DB:17     name=SIX remote-address=xxx.xxx.xxx.xxx tunnel-id=11
add keepalive=1s,3 local-address=xxx.xxx.xxx.xxx mac-address=02:3B:12:E5:7E:BC     name=SIX_BAK remote-address=xxx.xxx.xxx.xxx tunnel-id=12
add keepalive=1s,3 local-address=xxx.xxx.xxx.xxx mac-address=02:B8:B3:AB:DB:17     name=SEVENTH remote-address=xxx.xxx.xxx.xxx tunnel-id=13
add keepalive=1s,3 local-address=xxx.xxx.xxx.xxx mac-address=02:3B:12:E5:7E:BC     name=SEVENTH_BAK remote-address=xxx.xxx.xxx.xxx tunnel-id=14

/routing ospf area
add area-id=192.168.0.1 name=LOCAL
/snmp community
set [ find default=yes ] addresses=192.168.0.0/16
/system logging action
set 0 memory-lines=100
set 1 disk-lines-per-file=100
/tool user-manager customer
set admin access=    own-routers,own-users,own-profiles,own-limits,config-payment-gw
/user group
set read policy="read,test,winbox,sniff,sensitive,!local,!telnet,!ssh,!ftp,!re    boot,!write,!policy,!password,!web,!api"

/ip firewall connection tracking
set generic-timeout=1m tcp-close-timeout=5s tcp-close-wait-timeout=5s     tcp-established-timeout=1m tcp-fin-wait-timeout=5s tcp-last-ack-timeout=    5s tcp-time-wait-timeout=5s udp-stream-timeout=1m
/ip address
add address=192.168.0.1/24 interface=ether1 network=192.168.0.0
add address=xxx.xxx.xxx.xxx/xx interface=ISP2 network=xxx.xxx.xxx.xxx
add address=xxx.xxx.xxx.xxx/xx interface=ISP1 network=xxx.xxx.xxx.xxx
add address=10.0.1.18/30 interface=FIRST_BAK network=10.0.1.16
add address=10.0.1.46/30 interface=SECOND network=10.0.1.44
add address=10.0.1.50/30 interface=SECOND_BAK network=10.0.1.48
add address=10.0.1.73/30 interface=THIRD network=10.0.1.72
add address=10.0.1.77/30 interface=THIRD_BAK network=10.0.1.76
add address=10.0.1.86/30 interface=FOURTH network=10.0.1.84
add address=10.0.1.90/30 interface=FOURTH_BAK network=10.0.1.88
add address=10.0.1.94/30 interface=FIFTH network=10.0.1.92
add address=10.0.1.98/30 interface=FIFTH_BAK network=10.0.1.96
add address=10.0.1.102/30 interface=FIRST network=10.0.1.100
add address=10.0.1.217/30 interface=SIX network=10.0.1.216
add address=10.0.1.221/30 interface=SIX_BAK network=10.0.1.220
add address=10.0.1.225/30 interface=SEVENTH network=10.0.1.224
add address=10.0.1.229/30 interface=SEVENTH_BAK network=10.0.1.228

/ip dns
set servers=8.8.4.4
/ip firewall filter
add action=drop chain=input comment="Drop Invalid" connection-state=invalid
add action=drop chain=forward connection-state=invalid 
add chain=input comment=Established connection-state=established
add chain=input comment=Tunnels protocol=gre
add chain=input comment=WinBox dst-port=8291 protocol=tcp
add chain=input comment=NTP dst-port=123 protocol=udp
add chain=input comment="From Local" src-address=192.168.0.0/16
add chain=input comment=Ping protocol=icmp
add action=drop chain=input comment="DONT MOVE - DROP" in-interface=    ISP2
add action=drop chain=input comment="DONT MOVE - DROP" in-interface=    ISP1
/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu protocol=tcp     tcp-flags=syn tcp-mss=1460-65535
/ip firewall nat
add action=masquerade chain=srcnat out-interface=    ISP2
add action=masquerade chain=srcnat out-interface=ISP1
/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set irc disabled=yes
set h323 disabled=yes
set sip disabled=yes
set pptp disabled=yes
/ip route
add check-gateway=ping distance=1 gateway=8.8.8.8
add distance=2 gateway=10.10.20.1
add check-gateway=ping distance=1 dst-address=8.8.8.8/32 gateway=10.10.10.1 scope=10
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh disabled=yes 
set api disabled=yes
/routing ospf interface
add interface=FIRST network-type=point-to-point
add interface=FIRST_BAK network-type=point-to-point
add interface=SECOND network-type=point-to-point
add interface=SECOND_BAK network-type=point-to-point
add interface=THIRD network-type=point-to-point
add interface=THIRD_BAK network-type=point-to-point
add interface=FOURTH network-type=point-to-point
add interface=FOURTH_BAK network-type=point-to-point
add interface=FIFTH network-type=point-to-point
add interface=FIFTH_BAK network-type=point-to-point
add interface=SIX network-type=point-to-point
add interface=SIX_BAK network-type=point-to-point
add interface=SEVENTH network-type=point-to-point
add interface=SEVENTH_BAK network-type=point-to-point
add interface=ether1 network-type=broadcast passive=yes
/routing ospf network
add area=backbone network=10.0.0.0/22
add area=FIRST network=192.168.0.0/24
/system clock
set time-zone-autodetect=no time-zone-name=Europe/Kiev
/system identity
set name=MikroTik
/system resource irq rps
set ether1 disabled=yes
set ether2 disabled=yes
set ether3 disabled=yes
set ether4 disabled=yes
set ether5 disabled=yes
set ether6 disabled=yes
set ether7 disabled=yes
set ether8 disabled=yes
set ISP1 disabled=yes
set ISP2 disabled=yes
set ether11 disabled=yes
/system scheduler
add interval=6h name=schedule1 on-event=BackupToMail policy=    ftp,reboot,read,write,policy,test,password,sniff,sensitive start-date=    oct/28/2014 start-time=01:00:00
add interval=6h name=schedule2 on-event=BackupToFTP policy=    ftp,reboot,read,write,policy,test,password,sniff,sensitive start-date=    oct/28/2014 start-time=01:00:00
/system script
add name=BackupToMail owner=root policy=    ftp,reboot,read,write,policy,test,password,sniff,sensitive source="{\r    \n:log info \"Starting Backup Script...\";\r    \n:local sysname [/system identity get name];\r    \n:local sysver [/system package get system version];\r    \n:log info \"Flushing DNS cache...\";\r    \n/ip dns cache flush;\r    \n:delay 2;\r    \n:log info \"Deleting last Backups...\";\r    \n:foreach i in=[/file find] do={:if ([:typeof [:find [/file get \$i name]    \_\\\r    \n\"\$sysname-backup-\"]]!=\"nil\") do={/file remove \$i}};\r    \n:delay 2;\r    \n:local smtpserv [:resolve \"smtp.gmail.com\"];\r    \n:local Eaccount \"xxxxxx@gmail.com\";\r    \n:local TOaccount \"xxxxxx@gmail.com\";\r    \n:local pass \"xxxxxx\";\r    \n:local backupfile (\"\$sysname-backup-\" . \\\r    \n[:pick [/system clock get date] 7 11] . [:pick [/system \\\r    \nclock get date] 0 3] . [:pick [/system clock get date] 4 6] . \".backup    \");\r    \n:log info \"Creating new Full Backup file...\";\r    \n/system backup save name=\$backupfile;\r    \n:delay 2;\r    \n:log info \"Sending Full Backup file via E-mail...\";\r    \n/tool e-mail send from=\"<\$Eaccount>\" to=\$TOaccount server=\$smtpserv    \_\\\r    \nport=587 user=\$Eaccount password=\$pass tls=yes file=\$backupfile \\\r    \nsubject=(\"\$sysname Full Backup (\" . [/system clock get date] . \")\")    \_\\\r    \nbody=(\"\$sysname full Backup file see in attachment.\\nRouterOS version    : \\\r    \n\$sysver\\nTime and Date stamp: \" . [/system clock get time] . \" \" .     \\\r    \n[/system clock get date]);\r    \n:delay 5;\r    \n:local exportfile (\"\$sysname-backup-\" . \\\r    \n[:pick [/system clock get date] 7 11] . [:pick [/system \\\r    \nclock get date] 0 3] . [:pick [/system clock get date] 4 6] . \".rsc\");    \r    \n:log info \"Creating new Setup Script file...\";\r    \n/export file=\$exportfile;\r    \n:delay 2;\r    \n:log info \"Sending Setup Script file via E-mail...\";\r    \n/tool e-mail send from=\"<\$Eaccount>\" to=\$TOaccount server=\$smtpserv    \_\\\r    \nport=587 user=\$Eaccount password=\$pass tls=yes file=\$exportfile \\\r    \nsubject=(\"\$sysname Setup Script Backup (\" . [/system clock get date]     . \\\r    \n\")\") body=(\"\$sysname Setup Script file see in attachment.\\nRouterOS    \_\\\r    \nversion: \$sysver\\nTime and Date stamp: \" . [/system clock get time] .    \_\" \\\r    \n\" . [/system clock get date]);\r    \n:delay 5;\r    \n:log info \"All System Backups emailed successfully.\\nBackuping complet    ed.\";\r    \n}"
add name=BackupToFTP owner=antony policy=    ftp,reboot,read,write,policy,test,password,sniff,sensitive source="# Set l    ocal variables. Change the value in \"\" to reflect your environment.\r    \n\r    \n:local hostname  [/system identity get name];\r    \n:local password \"xxxxxx\"\r    \n:local username \"xxxxxx\"\r    \n:local ftpserver \"xxx.xxx.xxx.xxx\"\r    \n\r    \n# Set Filename variables. Do not change this unless you want to edit the    \_format of the filename.\r    \n\r    \n:local time [/system clock get time];\r    \n:local date ([:pick [/system clock get date] 0 3]  \\\r    \n. [:pick [/system clock get date] 4 6] \\\r    \n. [:pick [/system clock get date] 7 11]);\r    \n:local filename \"\$hostname-\$date-\$time\";\r    \n\r    \n# Create backup file and export the config.\r    \n\r    \nexport compact file=\"\$filename\"\r    \n/system backup save name=\"\$filename\"\r    \n\r    \n:log info \"Backup Created Successfully\"\r    \n\r    \n# Upload config file to FTP server.\r    \n\r    \n/tool fetch address=\$ftpserver src-path=\"\$filename.rsc\" \\\r    \nuser=\$username mode=ftp password=\$password \\\r    \ndst-path=\"\$filename.rsc\" upload=yes\r    \n\r    \n# Upload backup file to FTP server.\r    \n\r    \n/tool fetch address=\$ftpserver src-path=\"\$filename.backup\" \\\r    \nuser=\$username mode=ftp password=\$password \\\r    \ndst-path=\"\$filename.backup\" upload=yes\r    \n\r    \n:log info \"Backup Uploaded Successfully\"\r    \n\r    \n# Delete created backup files once they have been uploaded\r    \n# so they don't accumulate and fill up storage space on the router.\r    \n\r    \n/file remove \"\$filename.rsc\"\r    \n/file remove \"\$filename.backup\"\r    \n\r    \n:log info \"Local Backup Files Deleted Successfully\""
/system watchdog
set automatic-supout=no watchdog-timer=no
/tool e-mail
set address=64.233.161.109 from=<mikrotik> password=xxxxxx port=587     user=xxxxxx@gmail.com



UPD: данный конфиг слит с тестовой лабы, а не с прода. С момента написания данной статьи в проде от данной схемы успели отказаться в пользу L2VPN от провайдеров с OSPF для маршрутизации.
Поделиться с друзьями
-->

Комментарии (67)


  1. icCE
    12.11.2016 20:14

    Не смущает, что EoIP не шифруется в данном случае?


    1. merlin-vrn
      12.11.2016 20:36

      а шифрование в данном случае добавляется элементарно. IPSec с политиками, реагирующими на EoIP.


      1. icCE
        12.11.2016 21:13

        Не надо там этого, если внимательно читать доку.
        В 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 мы их не увидем.


        1. merlin-vrn
          13.11.2016 00:11

          У меня в голове "общее" решение. Возможно, попытавшись настроить EoIP в условиях автора, я бы заметил и настроил встроенную поддержку, просто я аналогичную задачу всегда решал с помощью GRE.


          Принципиально мой ответ означает, что проблема добавки шифрования здесь выеденного яйца не стоит, даже если бы специальной конфигурации не было — можно было бы реализовать стандартными средствами.


  1. merlin-vrn
    12.11.2016 20:38

    Да-а, это хорошо, конечно, но когда точек пять и везде по два интернета, это начинает раздражать. (Я знаю по себе, строил и эксплуатирую такую сеть, только у нас GRE и зашифровано IPSec)

    DMVPN не хватает. Ну или хотя бы умел бы микротик статический multipoint GRE, хотя бы статически настроено было бы — ну один или два тоннеля с каждой стороны, но не столько


    1. Kliba
      13.11.2016 12:28

      Да, раздражает, но тем не менее на восьми точках вполне работало на момент написания. С тех пор все сильно поменялось и фирма таки арендовала L2VPN между всеми офисами, так что теперь там все гораздо скучнее — просто IPSec с OSPF.


      1. ksg222
        13.11.2016 21:49

        Не совсем понял, почему стало скучнее. Предполагаю, что L2VPN у вас всё-таки резервируется.
        Возможно, из-за незнания особенностей данного оборудования я что-то упускаю, но разве удобно использовать чистый IPSec и OSPF? Ведь в настройках политик IPSec приходится жёстко прописывать, трафик который будет шифроваться. А это самым отрицательным образом начинает сказываться на гибкости в работе сети (добавление новых подсетей, передачи интернет трафика через туннели, например, при NAT публикациях и пр.).


        1. Kliba
          14.11.2016 09:47

          Резервируется. Еще одним L2VPN. Насчет удобства — да, вполне. В рамках этой сети нет нужды гонять интернет трафик через внутреннюю сеть между локациями, там гуляет исключительно локальный трафик. Соответственно и политики настроены на шифрование всего идущего в приватную сеть.


          1. ksg222
            14.11.2016 09:57

            В таком случае, почему изначально стоили туннели EoIP? Почему было не достаточно чистого IPSec и OSPF?


            1. merlin-vrn
              14.11.2016 10:52

              чистый ipsec — tunnel mode имеете ввиду?


              1. ksg222
                14.11.2016 11:05

                Да


                1. Kliba
                  14.11.2016 11:34
                  +1

                  Ниже в комментах есть ответ на этот вопрос — изначально по историческим причинам оставили EoIP, а позже при первой возможности перешли на L2VPN + на момент написания статьи наши микротики как-то странно криво работали с tunnel mode IPSec — при увеличении количества туннелей до 5 и выше начинали дропать часть трафика. Разбираться было некогда, так что построили на базе имевшегося, а позже уже сделали нормально.


                  1. ksg222
                    14.11.2016 11:42

                    Спасибо за ответы.


    1. neumeika
      13.11.2016 12:38
      +1

      скрипты решают, когда филиалов/бранчей более 3-ёх, ибо на 20 роутеров добавить ещё 1 тоннель, заоспефить его и не облажаться, нужно быть магом.


  1. ikormachev
    12.11.2016 21:28
    +4

    В целом направление выбрано верное, я лишь отмечу несколько недочетов:

    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. neumeika
      12.11.2016 23:04

      1) ccr ipsec 1,8 гигабита
      rb1100ahx2 до 1 гигабита (c тюнингом) чуток не хватало
      Но есть нюанс, 1 тоннель = 1 ядро, я так понял
      2) Тоннели на разные провайдеры, если верить разным буковкам вместо ip. Балансирует у автора OSPF (ECMP), правильнее делать бонд из тоннелей тогда уж, но равноценных линков я ещё не встречал, а траблешутить дропы ему, видимо, ещё придётся.
      3) тогда уж BGP
      4) GRE медленней (нагрузка cpu)
      7) оспф поломать просто, он у него беспарольный, и скорей всего, по дефолту, анонсится на все интерфейсы, network-то описан.
      Ну и bfd не в ethernet всё-таки чересчур, имхо


      1. ikormachev
        13.11.2016 00:21

        2) Тоннели на разные провайдеры, если верить разным буковкам вместо ip. Балансирует у автора OSPF (ECMP), правильнее делать бонд из тоннелей тогда уж, но равноценных линков я ещё не встречал, а траблешутить дропы ему, видимо, ещё придётся.

        Да, тоннели у него на разные провайдеры. Вот только если у маршрутизатора шлюз по умолчанию через интерфейс 1, то он все пакеты во вне по умолчанию будет слать через этот интерфейс, вне зависимости от того, какой в пакете будет стоят source IP. В итоге исходящий трафик в тоннеле 2, который, теоретически, должен уходить через интерфейс 2, уходит во вне через интерфейс 1.


        1. neumeika
          13.11.2016 00:32

          lookup решает, я вас понял. Автор много не учёл. Но, в принципе, вариант рабочий, хоть и с кучей оговорок :)


          1. Kliba
            13.11.2016 12:53

            Автор учел многое, но вот конфиг из прода автору выложить не дали, даже на конфиге из лабы сильно попросили потереть все адреса и все, что могло указать на фирму. По сути, выложенный мануал и конфиг показывают как это настроить чтобы вообще заработало, а вот доп. мелочи типа правил mangle для корректной работы обоих провайдеров вместе, маршрутов на внешние IP точек, шифрования трафика и т.д. можно настроить по надобности.


    1. dmitry_ch
      12.11.2016 23:48
      +1

      Вот про ядра вопрос интересный: по доке http://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Hardware_encryption поддержка и там, и там сделана «на ядрах», а не на одном ядре. Вот как уже балансировка работает, если туннелей несколько — вопрос интересный, сам Mikrotik обычно неохотно рассказывает.

      А вы откуда уверены, что CCR использует только 1 ядро?


      1. ikormachev
        13.11.2016 00:30

        А вы откуда уверены, что CCR использует только 1 ядро?

        В интернете полно информации по тестированию ipsec на CCR и отзывов недоуменных владельцев. Некоторые факт о использовании одного ядра узнают от поддержки микротика, другие — из наблюдения за загрузкой ядер во время тестирования.


        1. dmitry_ch
          13.11.2016 00:42

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

          Ну и настройки крипто тоже важны. Я тестировал на тех настройках, что рекомендованы (читаем: делай так — не ошибешься), но подозреваю, что с какими-то настройками крипто будет аппаратное, с какими-то — программное, но многоядерное, а с какими-то вообще бы просто завелось, и ладно.

          Уже не говоря, что версия от версии отличаются заметно, в т.ч. и по тому, что работает как надо, а что — нет.

          Свежие (недавно анонсированные) недорогие машинки стали очень дружить с IPSec, например. http://wiki.mikrotik.com/wiki/Manual:IP/IPsec#HEXv3_.28mmips.29_Config_Optimizations у них немного свои оговорки, как и что надо настраивать, и рекомендации кажутся разумными.

          AHx2 https://routerboard.com/RB1100AHx2 вообще интереная железка. Долгожитель, с кулерами, с PPC, грузится долго (на фоне CCR), второго БП в нем нет (тоже на фоше CCR), но при этом продается, используется часто, и сравнительно многими.


          1. ikormachev
            13.11.2016 01:07

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

            Вполне может быть так, что один туннель может занять не более одного ядра, но много туннелей могут занять все ядра. В этом случае действительно CCR покажет большую производительность. Я почему-то по своей наивности предпологала, что одно ядро процессора в принципе отвечает за процессинг на одном из портов — возможно, мое предлоложение было ошибочным.


    1. bibliary
      12.11.2016 23:58
      -2

      А за что расстреливать в пункте 5? По вашему нужно из 10ой подсети строить?


      1. merlin-vrn
        13.11.2016 00:09
        +1

        За использование 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, интернет и всё на свете.


        А поскольку задача возникает всегда, то использовав такие сети вы с этой проблемой столкнётесь всегда. И придётся сеть в офисе — упс — перенумеровывать. Это очень больно.


        1. bibliary
          13.11.2016 13:50

          Спасибо. В общем то я так и думал что вы об этом скажете.


      1. neumeika
        13.11.2016 00:36

        ну, и по моему опыту, проще линки делать из абсолютно левой сетки, например, 172.16.0.0/12


    1. merlin-vrn
      13.11.2016 00:05

      1) Не стоит использовать CCR в корпоративных сетях. Да, в нем больше процессорных ядер, но для обработки IPsec и туннелей он использует одно ядро. В 1100 AHx2 работают оба ядра и каждый из них быстрее ядер в CCR. Купив CCR вы заплатили лишнего и только ухудшили инфраструктуру.
      Откуда это?

      Про ядра: CCR1036 — 1.2 GHz Tile, AH1100x2 — 1GHz PPC. Напрямую сравнить Tile с PPC не удастся, но по крайней мере частота в CCR больше.


      А про то, как там IPsec и тоннели по ядрам распределяются — хочется подробностей — ссылок там, и так далее. Когда мы заводили на CCR1009 подобную штуку, на синтетических тестах (вроде flood-ping через тоннель) ядра нагружались равномерно. Жаль, что я сейчас туда посмотреть не могу.


      1. neumeika
        13.11.2016 00:46
        +1

        1 полиси на cpu вроде, т.е. пачка тоннелей 100% может грузить кучу процов, но 1 тоннель может грузить максимум 1 проц


    1. Kliba
      13.11.2016 12:44

      1) Пробовали ставить на место CCR 1100AHx2 — не тянул, там по факту кроме туннелей еще и OVPN, DHCP,DNS, куча правил firewall.
      2,3,4) С тех пор уже не надо стало — арендовали L2VPN от разных провайдеров, обернули в IPSec и радуемся
      5) Естественно нет)) Хотя когда-то были.
      6) Возможно, но пока работает — трогать смысла не вижу.
      7) OSPF запароленный в проде. Уж извините, но конфиг сюда я копировал с тестового стенда, а не с прода, что, впрочем, не отменяет его работоспособности.
      8) Естественно. В проде туннели называются согласно именам локаций в которые собственно они ведут.


  1. dimsoft
    12.11.2016 22:09

    IMHO можно для IP туннелей использовать /32 маску, в микротике /31 не работает, а /32 работает нормально


    1. merlin-vrn
      12.11.2016 23:56

      Для peer-to-peer использовать приватные подсети /30 — нормальное решение, потому, что проблем с совместимостью нет и не надо думать, чего там где поддерживается и работает.


      Там 18 миллионов адресов и они бесплатны, чего их экономить?


  1. x86128
    12.11.2016 22:10

    Рисовать схему удобно и красиво можно через draw.io (и онлайн и как приложение хром)
    А вот гонять в открытом виде трафик через интернет как-то совсем не айс.
    Если у вас есть основная площадка то почему там только один роутер.
    Как мониторите такой FullMesh?


    1. neumeika
      12.11.2016 22:22

      я не автор, но 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


    1. Kliba
      13.11.2016 12:47

      Как я говорил выше — в проде на всех площадках не один роутер по факту, но к теме это отношения имеет мало. За draw.io спасибо, буду иметь ввиду. Мониторим заббиксом по SNMP.


  1. neumeika
    12.11.2016 22:10

    ipsec полиси можно навесить, но вот использовать л2 тоннели вместо «нормальных» — оригинально. Отчего выбрано столь «оригинальное» туннелирование?
    при включении bfd не смущает большое количество служебных пакетов (в вашем случае вроде получается 64 пакета за 0.2 секунды )?


  1. nkusnetsov
    13.11.2016 08:21

    Таким образом нас перестали пугать технические работы у провайдера, а также периодические проблемы с проходимостью GRE пакетов по определенным направлениям

    Тут автор сам себе противоречит. Протокол EoIP работает на основе инкапсуляции L2-трафика внутрь GRE-пакетов. Достаточно внимательно посмотреть с помощью torch либо сделать tcpdump на транзитном маршрутизаторе.


    1. Kliba
      13.11.2016 12:49
      -2

      Не противоречу. Я знаю, что EoIP работает внутри GRE, но перестали данные проблемы пугать за счет большого количества других маршрутов — даже если по какому-либо направлению такие проблемы всплывали — на них просто падал OSPF и по данному туннелю трафик не шел до восстановления корректной работы.


      1. nkusnetsov
        13.11.2016 15:25

        Немного странный выбор pseudo-wire технологии туннелирования, когда для этого есть IPIP/GRE/L2TP и прочие протоколы точка-точка? Были какие-то проблемы с реализацией OSPF/BGP на линках? Изначально EoIP совсем не для этого предназначен.
        Так любят строить туннели наши «азиатские партнеры» из Индонезии и близлежащих к ней стран. Там некоторые вообще как дети — набриджуют EoIP туннелей в огромный broadcast-домен и чего-то с ним шаманят, извращаются…


        1. neumeika
          13.11.2016 15:28
          +1

          автор должен отписать, что в проде у него не так, это конфиг лабораторный :)


        1. Kliba
          13.11.2016 17:57

          EoIP в данном случае был оставлен по историческим причинам — EoIP туннели между основным офисом и каждым из других уже существовали, так что просто достроили недостающие и настроили маршрутизацию. При первой же возможности от этого отказались в пользу L2VPN от провайдеров между всеми локациями.


      1. epicf4il
        13.11.2016 20:52
        +1

        Классное «просто падал OSPF». А то что при падении одного интерфейса в OSPF, в вашей фул меш топологии, в рамках одной area начинался флудинг по всем n(n-1) линкам (без деления на 2, т.к по два провайдера на каждой ноде), вас видимо не сильно волновало.


        1. neumeika
          13.11.2016 21:11

          флуд-то ещё куда ни шло, хотя выглядит занятно, а вот перестроение маршрутов в area, где link state поменялся…
          если не грамотно подойти к разделению на арии, эффект, при количестве маршрутизаторов от 20, будет весьма интересен :)


          1. epicf4il
            13.11.2016 21:25

            Флуд выглядит куда занятнее, когда в такой топологии (фул меш с кучей провайдеров) один из провайдеров начинает биться в конвульсиях, прыгая из up в down каждые несколько секунд.


            1. neumeika
              13.11.2016 21:32

              давно не видел
              на микротах не видел противодействий данному, есть там по количеству отправляемого-принимаемого?


              1. epicf4il
                13.11.2016 21:38

                Про микротики как то не в курсе


                1. neumeika
                  13.11.2016 22:02

                  блин, на цисках сие просто, но я с такими проблемами только на них и сталкивался, когда провайдеры дурили
                  а вот на микротах придумал только фаерволом канал резать для ospf, но это топорно и л3, а хотелось бы повыше уровнем
                  либо чуть ли не на каждый тоннель арию делать и передать маршруты уже выше lsa3 :)


                  1. ksg222
                    13.11.2016 22:29
                    +1

                    чуть ли не на каждый тоннель арию делать и передать маршруты уже выше lsa3

                    Маршруты между разными area передаются как раз в рамках LSA 3.


                    1. neumeika
                      13.11.2016 22:38

                      сорри, глупо написал, надо было включительно добавить, я знаю что такое «межобластные» маршруты :)
                      вариант был в качестве бреда, естественно надо делать всё по реалиям железок (а в микроте эту путь проб), либо на основе чужих стандартов, не более 50 маршрутов на одну арию и всё такое.


                      1. merlin-vrn
                        14.11.2016 09:19

                        А меж тем тут сравнительно недавно пробегало, что микротики с более чем одной арией глючат. Эьо было в теме сравнения коммутаторов и поиска подходящего отечественного гигабитного L2. Искать ссылку влом.


                        ЗЫ да вон чуть ниже комментарий про это же :)


  1. NiTr0_ua
    13.11.2016 17:55

    а в чем здесь смысл использования л2 туннелей? какой от них профит? чисто чтобы оспф мультикаст мог слать? так это делается куда проще — ptp, и никакого мультикаста. и никаких туннелей к слову не нужно. и нет завязки на проприетарную технологию, которая ни с чем больше не совместима.

    к слову, с оспф у микротика все очень печально по части реализации — вплоть до закольцовывания маршрутов, поймете как только появится более одной area…


    1. Kliba
      13.11.2016 17:59

      EoIP исключительно по историческим причинам, а насчет OSPF на микротике — возможно и печально, но работает нормально в наших условиях.


    1. nkusnetsov
      13.11.2016 18:50

      Прямо заинтриговали. В системе несколько областей. В том числе не тупиковых. ASBR взаимодействует с quagga. Всё живет нормально. Возможно дело в правильной настройке ABR, инстансов и Area Ranges?
      За исключением глюка, когда сразу после интенсивной настройки/переконфигурации, требуется рестартовать инстанс, других не попадалось.
      Поделитесь примерами топологии и конфигов при закольцовывании. Можно в личку, поскольку чуть оффтоп.


      1. neumeika
        13.11.2016 19:17

        около 20 area, около 300 сетей, началась война и немцы, из того, что я смог натраблешутить в bird/quagga — с неправильным подсчётом костов, Маршруты в микротик выбирались неоптимально и не симметрично, пришлось лепить кучу рулесов в микроте, делать кучу инстансов. Тупиковые-то как раз нормально работают :)


      1. neumeika
        13.11.2016 19:21

        И это я ещё суммаризацию отключил. Ладно хоть в новых прошивках применение умных рулесов излечили, раньше (с год назад) надо было ребутить роутер, моргание демоном не помогало :)


      1. NiTr0_ua
        14.11.2016 00:35

        коротко — примерно в такой топологии маршруты начинают весело кольцеваться:
        A1 - A2
        | .. |
        A3 - A4

        где A1..A4 — разные area
        где-то было описание этого случая на наге, но что-то с ходу найти не могу.


  1. DoMoVoY
    13.11.2016 22:34

    Классический подход администраторов miktorik. На форуме сетевиков nag.ru есть пара фанатов Mikrotik, которые предлагают использовать mikrotik в любых местах, где спрашивают помощи. Так и здесь: для L3 сети не нужны L2 технологии вроде EOIP. Нужны ipip или OpenVPN в режиме L3. А для обмена маршрутами BGP. Как минимум сэкономить на L2 заголовках, которые для конечных устройств не нужны, как максимум управлять анонсами более оптимально. Я не говорю, что EOIP и OSPF плохи, но они для других ситуаций предназначены.
    А передавать по арендуемым L2-каналам OSPF опасно — никто не даст вам 100% гарантии прохождения multicast. Когда-нибудь оно сломается может и не по Вашей вине. С BGP unicast такого точно не произойдет.


    1. neumeika
      13.11.2016 22:43

      bgp дольше сходимость, и чё-то все мои знакомые, любящие микрот, бгп крутят на кошках с джунами :)
      openvpn не советую вообще, мало того, что rtt добавляет, да ещё и рандомно при нагрузке большой, дык ещё и тормозной, без сжатия и в TCP


      1. DoMoVoY
        13.11.2016 23:52

        объясните в чем дольше сходимость BGP? В первом установлении TCP-сессии? Пусть Ваши знакомы продолжают крутить — я не об это говорил. OpenVPN с шифрованием работает быстрее чем EoIP, завернутый в ipsec. OpenVPN можно гонять и через UDP. Еще плюсом является кроссплатформенность и возможность пройти через NAT в отличии от GRE, но здесь это возможно не существенно.


        1. neumeika
          14.11.2016 00:19

          блин, ну наверно в значениях таймеров по умолчанию, RFC 4271 (30 секунд) х (3 кипалива) = 90, причём в разном оборудовании значение периода от 30 до 180 может быть.
          для оспф 10х4
          в данном случае рассматриваем ibgp или ebgp? там разные периоды рассылки изменений
          на микротах нет UDP
          по моим тестам openvpn медленнее ipip, и даже без разницы что на другой стороне: микрот, линукса, винда, всё зависит от количества пакетов, при моих нагрузках больше 80мегабит в одном канале я не смог родить.
          Цифры для EOIP должны отличаться на 10% максимум, т.к. с eoip я тоже жил, ибо по-другому л2 не прокинуть, а мплс на мини микротах очень медленный
          про eoip я вообще не говорил, его использование для меня — дикость


          1. epicf4il
            14.11.2016 00:54

            Оффтоп по времени сходимости. Очень наглядный пример — это одновременное использование и bgp и igp. Тот самый случай, когда мы получаем black hole из-за того что, к примеру, ospf уже поднялся, а bgp ещё нет. Не зря придумали overload механизмы для «запрета» прохождения транзитного трафика: overload bit (is-is), max-metric (ospf). Помимо стандартных таймеров там есть опция «жди меня», а точнее «жди его» — дождаться пока поднимется братюня bgp и только потом возвращать работу igp в штатный режим. Eigrp в этом плане нервно курит в сторонке.


      1. NiTr0_ua
        14.11.2016 00:42

        бгп на микротике убого и ущербно от рождения. мало того что разрабы не отличают 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…


        1. neumeika
          14.11.2016 01:25

          про bfd и так ясно
          А с RR вообще возможно как-то на микроте?
          у меня ни сделать, ни пообщаться не получилось, только руками/скриптами, только хардкор, но в продакшен я это не пихнул, оно как бы есть и заявлено, но ожидаемый результат получается как-то не так, как хотелось бы. Такое чувство, что микротом можно только натить/чуток_фаерволить (исключительно cisco ASA style). Как только начинаешь изображать что-то умное, выскакивает куча ограничений, многотунелье не любит, динамику не понимает, над фулвьюшечкой думает, роутинг с блокируемой коммутацией получается, VRRP не выгоден, куча правил в фаере тож с трудом переваривается. Такой он, для очень вялого энтерпрайза, дешёвый pps спасает. Ну нет у них желания влезать в нормальные сети.


          1. NiTr0_ua
            14.11.2016 12:31

            микротик ни разу не для энтерпрайза. обычная сохо поделка, пускай и перекачанная стероидами. ибо подход к софтописательству — типичный сохо: мы тут вам наговнякали 100500 плюшек, и они вроде как должны работать, но плюшка А вешает систему когда включена плюшка В, плюшка С работает не по стандарту т.к. индус, ее писавший, стандарт не понял (либо вообще не читал), а в плюшке D есть critical bug, допускающий remote DoS атаку — но править мы его вот прямо сейчас не будем, потому что за багфиксы деньги не платят, может, если вам повезет, лет через 5 пофиксим, а пока — пользуйтесь тем что есть. и да, никакого сервис-контракта, по которому отказавшую железку заменят в течение суток-двух, а всплывший баг исправят за адекватные сроки, тоже нет, в принципе. а сервис-контракт — основное требование энтерпрайза.

            ИМХО микротик — скорее для тех, кто не осилил *nix и не любит думать — т.к. есть 100500 гайдов, как сконфигурить что-то, с расписанным порядком куда ткнуть мышкой для получения результата.

            а с RR — пообщаться получится только если напихать микротику маршруты к аплинкам статикой через RR. возможно — еще получится если маршруты будут получаться не статикой а через ospf/rip, но не пробовал.


            1. merlin-vrn
              14.11.2016 15:54

              а сервис-контракт — основное требование энтерпрайза.

              ну, в случае с микротиком дешевле купить ящик резервных железок


              1. NiTr0_ua
                14.11.2016 16:21
                +1

                каким образом ящик резервных железок позволит бороться с багами в софте/особенностями используемых сохо компонентов (свиччипы, эзернет чипы и т.п.)? вы вообще с энтерпрайзом и их требованиями сталкивались? там, где час простоя обходится суммой с 3-4 и более нулями, ессно мертвых президентов?

                а багов таки имеется. к примеру, вис микротика наглухо при частых ssh коннектах (порядка нескольких коннектов в секунду) — эту багу фиксили более 3 лет (!). или из относительно свеженького (вроде еще непофиксенного) — вис при переполнении коннтрака… и по железу там часто все печально — тот же встроенный свич в rb2011 к примеру при наличии в л2 сегменте более 50-70 маков превращается в хаб из-за колизий хешей (спасибо дешевому AR8337), начинает рассылать трафик во все свои порты, и бороться можно только свичуя (бриджуя) все на и так чахлом проце; на тех же CCR с гигабитными портами распаяны сетевые адаптеры atheros которые на 500-600 мбитах реального трафика с мелкими пакетами начинают превращаться в тыкву, и т.п.

                ну и да, микротики по цене не дешевле б/у циски/джунипера сравнительной производительности.


    1. merlin-vrn
      14.11.2016 09:23

      Опенвпн на микротике? Лучше бы его там совсем не было, чем этот огрызок.


      А передавать по арендуемым L2-каналам OSPF опасно — никто не даст вам 100% гарантии прохождения multicast.

      Вот с этим вынужден согласиться. Сам наелся, и на цисках, а не на микротиках. Уже не помню, к чему там в итоге пришли, к nbma или что-то ещё изобретали.