Eoip tunnel mikrotik настройка

Настройка GRE

Первым шагом рассмотрим простую настройку gre туннеля. Вся она будет одинакова на обоих роутерах. Подключившись к нажим железкам через Winbox и перейдем в Interfaces – GRE Tunnel.

Создадим по интерфейсу. Укажем следующие параметры:

• Name – понятное имя;
• Remote Address – адрес соседа по туннелю. Основной принцип — направляем роутеры друг на друга;

Keepalive – тот самый параметр отслеживания состояния. Можно ничего не менять. Он означает следующее – если в течении 10 попыток по 10 секунд не отвечает удаленная сторона, считать туннель не активным.

Сохраняем настройки и смотрим на состояние.

Как мы видим, интерфейс в состоянии running. Назначим адреса. Переходим в IP – Addresses.

Зададим адрес 172.16.25.1 для московского роутера и 172.16.26.2 для питерского.

Для проверки связи запустим ping запросы.

Пинги идут – все хорошо. Далее пропишем маршруты в локальные сети. Открываем IP – Routes на московском.

Добавляем новый маршрут:

• Dst. Address – 192.168.10.0/24;
• Gateway – 172.16.25.2.

Сохраняем и проделываем аналогичную операцию только на питерском роутере.

Основной принцип – прописать маршруты в сети через адреса в туннелях. Проверим ping до адреса бриджа Mikrotik в Москве.

Все отлично – значит мы правильно сделали. В целях демонстрации я отключу интерфейс в Москве, выжду интервал в 100 секунд и посмотрим на состояние туннеля.

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

Пингов нет, а туннель активен. Спустя какое-то время, Mikrotik в Питере понимает, что связи через gre туннель нет и меняют статус на интерфейсе.

Тут-то и помогла доработка Mikrotik с keepalive. К чему этот эксперимент спросите вы? Во-первых – для демонстрации, во-вторых – если есть те, кто еще используют данный протокол для своих задач, имейте ввиду, что маршруты в routes буду активны то время, которое вы указали в keepalive. Только по истечении этого времени маршруты и адрес станут не активны.

Bonding EoIP tunnels over two wireless links

This is an example of aggregating multiple network interfaces into a single pipe. In particular, it is shown how to aggregate multiple virtual (EoIP) interfaces to get maximum throughput (MT) with emphasis on availability.

Network Diagram

Two routers R1 and R2 are interconnected via multihop wireless links. Wireless interfaces on both sides have assigned IP addresses.

Getting started

Bonding could be used only on OSI layer 2 (Ethernet level) connections. Thus we need to create EoIP interfaces on each of the wireless links. This is done as follows:

on router R1:

 > /interface eoip add remote-address=10.0.1.1/24 tunnel-id=1
 > /interface eoip add remote-address=10.0.2.1/24 tunnel-id=2

and on router R2

 > /interface eoip add remote-address=10.1.1.1/24 tunnel-id=1
 > /interface eoip add remote-address=10.2.2.1/24 tunnel-id=2

The second step is to add bonding interface and specify EoIP interfaces as slaves:

R1:

 > / interface bonding add slaves=eoip-tunnel1,eoip-tunnel2 mode=balance-rr 

R2

 > / interface bonding add slaves=eoip-tunnel1,eoip-tunnel2 mode=balance-rr 

The last step is to add IP addresses to the bonding interfaces:

R1:

 > / ip address add address 192.168.0.1/24 interface=bonding1

R2

 > / ip address add address 192.168.0.2/24 interface=bonding1 

Test the configuration

Now two routers are able to reach each other using addresses from the 192.168.0.0/24 network. To verify bonding interface functionality, do the following:

R1:

 > /interface monitor-traffic eoip-tunnel1,eoip-tunnel2

R2

 > /tool bandwidth-test 192.168.0.1 direction=transmit

You should see that traffic is distributed equally across both EoIP interfaces:

 > /int monitor-traffic eoip-tunnel1,eoip-tunnel2              
    received-packets-per-second: 685      685                                  
       received-bits-per-second: 8.0Mbps  8.0Mbps                              
        sent-packets-per-second: 21       20                                   
           sent-bits-per-second: 11.9kbps 11.0kbps                             
    received-packets-per-second: 898      899                                  
       received-bits-per-second: 10.6Mbps 10.6Mbps                             
        sent-packets-per-second: 20       21                                   
           sent-bits-per-second: 11.0kbps 11.9kbps                             
    received-packets-per-second: 975      975                                  
       received-bits-per-second: 11.5Mbps 11.5Mbps                             
        sent-packets-per-second: 22       22                                   
           sent-bits-per-second: 12.4kbps 12.3kbps                             
    received-packets-per-second: 980      980                                  
       received-bits-per-second: 11.6Mbps 11.6Mbps                             
        sent-packets-per-second: 21       21                                   
           sent-bits-per-second: 11.9kbps 11.8kbps                             
    received-packets-per-second: 977      977                                  
       received-bits-per-second: 11.6Mbps 11.5Mbps                             
        sent-packets-per-second: 21       21                                   
           sent-bits-per-second: 11.9kbps 11.8kbps                             
-- 
 >

Link Monitoring

It is easy to notice that with the configuration above as soon as any of individual link fails, the bonding interface throughput collapses. That’s because no link monitoring is performed, consequently, the bonding driver is unaware of problems with the underlying links. Enabling link monitoring is a must in most bonding configurations. To enable ARP link monitoring, do the following:

R1:

 > / interface bonding set bonding1 link-monitoring=arp arp-ip-targets=192.168.0.2

R2

 > / interface bonding set bonding1 link-monitoring=arp arp-ip-targets=192.168.0.1

Specifications

Internal Database

The ProLinx module contains an internal database that consists of areas for application data, status information, and configuration information.

The internal database is shared between all ports on the module and is used as a conduit to pass information from a device on one network to one or more devices on another network.

Application Data Area

The data area is used to store and retrieve data by the protocol drivers and for data exchange between protocols. The database is used as a source for write commands to remote devices and holds data collected from the remote devices. Commands defined in the configuration file (stored in the configuration data area) control how the data is to be handled in the database.

Настройка VLAN между двумя роутерами\коммутаторами MikroTik(L3), схема trunk и access портов

Приведенная схема также является популярной связкой, когда маршрутизатор(роутер) MikroTik раздает VLAN через коммутатор(или другой роутер MikroTik), на котором установлена RouterOS. Такие коммутаторы относятся к категории устройств L3 и схематически подключение будет выглядеть так:

Если описать словами схему, то:

• 5-ый порт роутера тегированный(trunk);
• 9-ый порт коммутатора L3 тегированный(trunk);
• 11-ий и 18-ый порт коммутатора L3 нетегированные(access).

За основу настроек будет взята настройка VLAN-ов со стороны центрального маршрутизатора(роутера), описанная . Эта настройка включает:

1. ;
2. ;
3. ;
4. ;
5. .

А далее эта конфигурация будет адаптирована.

/interface bridge port add bridge=Bridge interface=ether5 pvid=1

/interface bridge vlan 
add bridge=Bridge tagged=Bridge untagged=ether5 vlan-ids=10
add bridge=Bridge tagged=Bridge untagged=ether5 vlan-ids=20

Со стороны MikroTik коммутатора L3

Настройка находится Bridge→Bridge

Необходимо определить Bridge интерфейс, настройки которого содержат параметр Ether. type = 0x8100. Это параметр указывает на том, что на данном интерфейсе будет использоваться тег VLAN-а.

/interface bridge
add admin-mac=AA:B3:B9:A4:DE:D1 auto-mac=no name=Bridge-VLAN vlan-filtering=yes

Настройка находится Interfaces→VLAN

В созданном VLAN-е нужно определить VLAN ID, а также указать интерфейс, на котором он будет присваиваться. В схеме, где отсутствует центральный Bridge, VLAN нужно назначить на Bridge интерфейс

По аналогии создаются все необходимые интерфейсы.

/interface vlan
add interface=Bridge-VLAN name=vlan10 vlan-id=10
add interface=Bridge-VLAN name=vlan10 vlan-id=20

Настройка находится Bridge→Ports

/interface bridge port
add bridge=Bridge-LAN interface=ether9 pvid=1
add bridge=Bridge-LAN interface=ether11 pvid=10
add bridge=Bridge-LAN interface=ether18 pvid=20

• ether9 – тегированный(trunk) порт;
• ether11 и ether18 нетегированные(access) порты под VLAN ID=10 и VLAN ID=20 соответственно.

Настройка находится Bridge→VLANs

/interface bridge vlan
add bridge=Bridge-LAN tagged=ether9 untagged=ether11 vlan-ids=10
add bridge=Bridge-LAN tagged=ether9 untagged=ether18 vlan-ids=20

Протокол IPoE – максимальный комфорт для пользователя (и не только для него)

На фоне PPPoE, протокол IPoE предпочтительнее, ведь предоставляемые им возможности заинтересуют любого пользователя:

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

минимальные задержки на сервере провайдера позволяют получать высокую скорость соединения при снижении значений jitter и ping. Эта особенность высоко цениться геймерами, участвующими в онлайн-баталиях, а так же при организации качественной видеосвязи.

IPoE позволяет подключать без дополнительных настроек множество различных устройств и создавать с ними локальную сеть. Однако для этого потребуется приобретение коммутирующего роутера.

Не хотелось бы заканчивать анализ разницы между PPPoE и IPoE на минорной ноте, но считаю необходимым отметить некоторые серьезные недостатки последнего способа подключения. В силу того, что они проявляют себя крайне редко, называть их существенными я не буду, но возможность возникновения неприятной ситуации обрисую. Если в PPPoE у нас реальный АйПи и качественно защищенной канал связи с системой идентификации оборудования пользователя, то в IPoE по этим показателям совсем все плохо.

Потенциальная уязвимость канала заключается в том, что имея, например, роутер и инструмент для обжима витой пары можно запросто «врезаться» в кабель, идущий к пользователю с IPoE протоколом. Чисто гипотетически злоумышленник сможет не только пользоваться оплаченной кем-то услугой, но и спокойно перехватывать чужую информацию, содержащую пароли к финансовым или почтовым сервисам. Так же он может от имени IP ничего не ведающего клиента осуществлять активный веб-серфинг с распространением контента, содержимое которого может идти в разрез с действующим законодательством.

Вот вы и узнали в чём разница ipoe и pppoe. Делайте свои выводы, что безопаснее, а что удобнее. И если ведущие к вам коммуникации надежно защищены или находятся в контролируемой зоне, то спокойно пользуйтесь протоколом IPoE, получая удовольствие от предоставляемого им комфорта.

А в целом PPPoE и IPoE прекрасно справляются с задачей передачи данных в Интернете. И как многое в нашей жизни, каждый из них лучше всего приспособлен для решения каких-то конкретных задач. Обо всех этих особенностях вы сегодня уже узнали и наверняка сможете сделать правильный выбор. На этом я с вами прощаюсь и желаю успехов и везения.

Notes

tunnel-id is method of identifying tunnel. It must be unique for each EoIP tunnel.
mtu should be set to 1500 to eliminate packet refragmentation inside the tunnel (that allows transparent bridging of Ethernet-like networks, so that it would be possible to transport full-sized Ethernet frame over the tunnel).

When bridging EoIP tunnels, it is highly recommended to set unique MAC addresses for each tunnel for the bridge algorithms to work correctly. For EoIP interfaces you can use MAC addresses that are in the range from 00:00:5E:80:00:00 — 00:00:5E:FF:FF:FF , which IANA has reserved for such cases. Alternatively, you can set the second bit of the first byte to modify the auto-assigned address into a ‘locally administered address’, assigned by the network administrator and thus use any MAC address, you just need to ensure they are unique between the hosts connected to one bridge.

Note: EoIP tunnel adds at least 42 byte overhead (8byte GRE + 14 byte Ethernet + 20 byte IP)

Summary

Virtual Private Lan Service (VPLS) interface can be considered tunnel interface just like EoIP interface. To achieve transparent ethernet segment forwarding between customer sites.

MikroTik RouterOS implements following VPLS features:

• LDP signaling (RFC 4762), see
• pseudowire fragmentation and reassembly (RFC 4623)
• MP-BGP based autodiscovery and signaling (RFC 4761), see BGP based VPLS

Since version 3.17:

• Cisco style static VPLS pseudowires (RFC 4447 FEC type 0x80), see
• Cisco VPLS BGP-based auto-discovery (draft-ietf-l2vpn-signaling-08), see
• support for multiple import/export route target extended communities for BGP based VPLS (both, RFC 4761 and draft-ietf-l2vpn-signaling-08)

Связь через PPPoE – чистый IP и надежная защита вашей информации

Теперь, ознакомившись с теорией, нам будет проще оценить возможности и отличия IPoE и PPPoE протоколов в условиях их практического использования. Начнем, как обычно, с PPPoE и его достоинств:

• Наличие полноценного IP адреса. Если вы не знаете, для чего он нужен, то я напомню. Это организация удаленного доступа к вашему ПК, возможность подключения домашних камер видеонаблюдения, участие в файлообменных проектах в качестве сервера, создание собственного VPN канала, а так же автоматическая авторизация для серьезных банковских сервисов.
• Автоматическое шифрование пакетов данных имеет огромное значение для обеспечения безопасности, особенно в контексте только что перечисленных функций компьютера. Добавьте сюда стабильность информационного канала, и вы получите в лице PPPoE идеальный инструмент для надежной связи и решения ответственных задач.
• Туннельный протокол маршрутизации между точками сети обеспечивает выделение линии на период сеанса и ее минимальную загрузку.

Теперь о недостатках такого способа соединения:

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

General

Sub-menu:

List of all VPLS interfaces. This menu shows also dynamically created BGP based VPLS interfaces.

Properties

Read-only properties

Monitoring

Command will display current VPLS interface status

For example:

 /interface vpls> monitor vpls2
       remote-label: 800000
        local-label: 43
      remote-status: 
          transport: 10.255.11.201/32
  transport-nexthop: 10.0.11.201
     imposed-labels: 800000

Available read only properties: