Comments 19
Интересное решение. Однако при большой передаче процессор будет напрягать все свои ресурсы из-за использования моста.
Мне всегда казалось, что это какая-то архитектурная ошибка такое городить. Может кто-нибудь подскажет когда подобный подход будет единственным верным решением?
Мне всегда казалось, что это какая-то архитектурная ошибка такое городить. Может кто-нибудь подскажет когда подобный подход будет единственным верным решением?
Конечно, процессор всегда нагружается при дополнительной обработке пакетов. Но иногда приходится с этим смириться, если нет другого варианта.
Кстати, вот пример вопроса на соседнем ресурсе: toster.ru/q/276217
Альтернатива — в разрыв линка установить отдельный свитч и два патч-корда в два разных порта МТ, или в один порт на два VLAN опять же, через внешний «умный» свитч.
Кстати, вот пример вопроса на соседнем ресурсе: toster.ru/q/276217
Альтернатива — в разрыв линка установить отдельный свитч и два патч-корда в два разных порта МТ, или в один порт на два VLAN опять же, через внешний «умный» свитч.
Лучшее решение автор вопроса сам предложил: зарегистрировать оба адреса на один mac.
Дело не в дополнительной обработке пакетов, а в том, что микротик будет ядром пакеты перерабатывать даже когда это не нужно. Если даже просто два интерфейса между собой мостом соединить, то при 100мб/с процессор только и будет заниматься пакетами этого моста.
Дело не в дополнительной обработке пакетов, а в том, что микротик будет ядром пакеты перерабатывать даже когда это не нужно. Если даже просто два интерфейса между собой мостом соединить, то при 100мб/с процессор только и будет заниматься пакетами этого моста.
>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?
>/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?
а что делать, если ip-адреса нужно получить по dhcp?
А можно хоть один пример из практики, когда поодобное реально может понадобиться?
1) Когда провайдер даёт два IP с привязкой к разным макам на одном физическом порту.
2) Имитировать физическое присутствие некоего оборудования на площадке, фактически висящего в другой отдаленной сети — не зависит от удаленного маршрутизатора, т.к. не требует L2 туннелирования через EoIP или VPLS.
2) Имитировать физическое присутствие некоего оборудования на площадке, фактически висящего в другой отдаленной сети — не зависит от удаленного маршрутизатора, т.к. не требует L2 туннелирования через EoIP или VPLS.
А такое бывает? Я про провайдера… и главное зачем?
когда необходимо поднять 2 и более ПППоЕ до провайдера например
Наблюдал одного провайдера, у которого долгое время было жесткое правило «Один IP = один MAC». Потом узнал, что ограничение было связано как-то с их биллингом. То ли самописный он был, то ли просто специалистов по настройке этого биллинга небыло в штате.
Коллеги, а есть ли объективные причины, по которым MikroTik не реализует функционал сабинтерфейсов?
а так не легче?
Может кому то будет интересно или пригодится, на официальном форуме микротика нашел вполне рабочий вариант использовать 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Интересный способ. Главное, относительно простой.
Но к сожалению, для vrrp-интерфейса невозможно задать произвольный MAC-адрес, т.к. он определен стандартом «0000:5E00:01xx, где xx — номер группы VRRP».
Из других моментов: vrrp пытается искать соседа по мультикасту и трафик может быть перехвачен с последующим захватом роли master. Версия VRRP v3 включаемая по-умолчанию не поддерживает аутентификацию, что настораживает.
Если делать это на том же роутере, где на основном интерфейсе поднят DHCP-сервер то, dhcp-client не получает IP.
Но к сожалению, для vrrp-интерфейса невозможно задать произвольный MAC-адрес, т.к. он определен стандартом «0000:5E00:01xx, где xx — номер группы VRRP».
Из других моментов: vrrp пытается искать соседа по мультикасту и трафик может быть перехвачен с последующим захватом роли master. Версия VRRP v3 включаемая по-умолчанию не поддерживает аутентификацию, что настораживает.
Если делать это на том же роутере, где на основном интерфейсе поднят DHCP-сервер то, dhcp-client не получает IP.
Если делать это на том же роутере, где на основном интерфейсе поднят DHCP-сервер то, dhcp-client не получает IP.
У меня связка "dhcp-клиент на ethernet + dhcp-клиент на vrrp поверх этого ethernet" работает нормально. Касательно MAC-адресов — можно попробовать поиграться справилами Bridge NAT, как в этой статье.
А теперь, пожалуйста, то же самое, но для IPv6.
Sign up to leave a comment.
MikroTik — несколько адресов и несколько разных MAC на одном интерфейсе