MikroTik — несколько адресов и несколько разных MAC на одном интерфейсе

[@onegreyonewhite]

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

[@nkusnetsov]

Конечно, процессор всегда нагружается при дополнительной обработке пакетов. Но иногда приходится с этим смириться, если нет другого варианта.
Кстати, вот пример вопроса на соседнем ресурсе: toster.ru/q/276217
Альтернатива — в разрыв линка установить отдельный свитч и два патч-корда в два разных порта МТ, или в один порт на два VLAN опять же, через внешний «умный» свитч.

[@onegreyonewhite]

Лучшее решение автор вопроса сам предложил: зарегистрировать оба адреса на один mac.
Дело не в дополнительной обработке пакетов, а в том, что микротик будет ядром пакеты перерабатывать даже когда это не нужно. Если даже просто два интерфейса между собой мостом соединить, то при 100мб/с процессор только и будет заниматься пакетами этого моста.

[@nkusnetsov]

Мне кажется Вы недооцениваете мощность процессора. На неоптимизированной системе «из коробки», при наличии простого фаервола прирост нагрузки CPU составил в среднем +2%, в редких пиках подскакивал до +10%. См. результат теста в конце статьи.

[@Dobrumir]

>RouterOS command
>/interface bridge nat add action=src-nat chain=srcnat mac-protocol=ip src->address=192.168.10.111/32 src-mac-address=D4:CA:6D:C7:11:11/FF:FF:FF:FF:FF:FF to-src-mac->address=D4:CA:6D:C7:22:22
Точно 192.168.10.111/32?

[@nkusnetsov]

Спасибо, вкралась опечатка. Исправил.

[@native]

а что делать, если ip-адреса нужно получить по dhcp?

[@nkusnetsov]

В данном случае с dhcp не всё получится, т.к. в arp-reply идет работа с заранее известным IP-адресом. Нормально dhcp-client отработает только на основном интерфейсе «bridge-local»

[@ElvenSailor]

А можно хоть один пример из практики, когда поодобное реально может понадобиться?

[@nkusnetsov]

1) Когда провайдер даёт два IP с привязкой к разным макам на одном физическом порту.
2) Имитировать физическое присутствие некоего оборудования на площадке, фактически висящего в другой отдаленной сети — не зависит от удаленного маршрутизатора, т.к. не требует L2 туннелирования через EoIP или VPLS.

[@sigmatik]

А такое бывает? Я про провайдера… и главное зачем?

[@pr0l]

когда необходимо поднять 2 и более ПППоЕ до провайдера например

[@nkusnetsov]

Наблюдал одного провайдера, у которого долгое время было жесткое правило «Один IP = один MAC». Потом узнал, что ограничение было связано как-то с их биллингом. То ли самописный он был, то ли просто специалистов по настройке этого биллинга небыло в штате.

[@macik]

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

[@HeroFromEarth]

Коллеги, а есть ли объективные причины, по которым MikroTik не реализует функционал сабинтерфейсов?

[@pr0l]

а так не легче?
Может кому то будет интересно или пригодится, на официальном форуме микротика нашел вполне рабочий вариант использовать 3-х связок IP-MAC на одном интерфейсе (мне просто больше не нужно), способ подразумевает использование интерфейсов VRRP, вот собственно и часть конфига:

Сейчас тестирую у себя, пока всё ок.

/interface vrrp
add interface=ether1 name=vrrp1 vrid=1
add interface=ether1 name=vrrp2 vrid=2
add interface=ether1 name=vrrp3 vrid=3
# VRRP interface needs some static address to come up:
/ip address
add address=127.0.0.2/32 interface=vrrp1 network=127.0.0.2
add address=127.0.0.3/32 interface=vrrp2 network=127.0.0.3
add address=127.0.0.4/32 interface=vrrp3 network=127.0.0.4
/ip dhcp-client
add default-route-distance=0 dhcp-options=hostname,clientid disabled=no \
interface=ether1
add add-default-route=no dhcp-options=hostname,clientid disabled=no interface=\
vrrp1 use-peer-dns=no use-peer-ntp=no
add add-default-route=no dhcp-options=hostname,clientid disabled=no interface=\
vrrp2 use-peer-dns=no use-peer-ntp=no
add add-default-route=no dhcp-options=hostname,clientid disabled=no interface=\
vrrp3 use-peer-dns=no use-peer-ntp=no

It's definitely not a proper solution and I'm not sure about all possible side effects. But at the first sight, it works:
ros code

Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK INTERFACE
0 127.0.0.2/32 127.0.0.2 vrrp1
1 127.0.0.3/32 127.0.0.3 vrrp2
2 127.0.0.4/32 127.0.0.4 vrrp3
3 D 192.168.80.50/24 192.168.80.0 ether1
4 D 192.168.80.48/24 192.168.80.0 vrrp2
5 D 192.168.80.47/24 192.168.80.0 vrrp3
6 D 192.168.80.49/24 192.168.80.0 vrrp1

[@nkusnetsov]

Интересный способ. Главное, относительно простой.
Но к сожалению, для vrrp-интерфейса невозможно задать произвольный MAC-адрес, т.к. он определен стандартом «0000:5E00:01xx, где xx — номер группы VRRP».
Из других моментов: vrrp пытается искать соседа по мультикасту и трафик может быть перехвачен с последующим захватом роли master. Версия VRRP v3 включаемая по-умолчанию не поддерживает аутентификацию, что настораживает.
Если делать это на том же роутере, где на основном интерфейсе поднят DHCP-сервер то, dhcp-client не получает IP.

[@Chupaka]

Если делать это на том же роутере, где на основном интерфейсе поднят DHCP-сервер то, dhcp-client не получает IP.

У меня связка "dhcp-клиент на ethernet + dhcp-клиент на vrrp поверх этого ethernet" работает нормально. Касательно MAC-адресов — можно попробовать поиграться справилами Bridge NAT, как в этой статье.

[@AEP]

А теперь, пожалуйста, то же самое, но для IPv6.