Pull to refresh

Comments 15

Это костыль, для работы которого необходимы статические маршруты. Суть ip unnumbered в Cisco в том, что она сама умеет их создавать (например, на основании dhcp обмена) и redistribute-ить дальше.
Разумеется костыль, но ведь и Mikrotik — не Cisco. Но на счет «сама умеет их создавать» — не вполне уверен, можете объяснить как? В случае с DHCP всё понятно, это и на Mikrotik'е можно сделать. Но если вам в cisco надо чётко указать что такому-то vlan назначается такой-то ip, как это делается, если не статическими маршрутами?
Нет, на микротике это сделать нельзя.
Поясню. Я не фанат cisco, потому могу ошибаться в терминологии, но постараюсь донести мысль.
Возьмем сеть 1.0.0.0/24.
На loopback вешаем 1.0.0.1/24.
На пачку vlan-ов вешаем ip unnumbered. Запускаем там же dhcp relay.

Дальше получается такой процесс:
1) Клиент пытается получить по dhcp адрес. Cisco пересылает запрос на сервер.
2) Сервер отвечает на запрос, выдавая, например, адрес 1.0.0.173.
3) DHCP-ответ улетает клиенту, клиент получает адрес.
4) Тут включается магия: Cisco всё это время слушала обмен DHCP-пакетами и сама создает маршрут на 1.0.0.173 через нужный VLAN. Этот же маршрут автоматически удаляется из таблицы после окончания времени DHCP lease-ы (и, естественно, продлевается, когда клиент продлевает lease).

Таким образом отпадает необходимость вручную (статикой) прибивать IP-адреса пользователей к vlan-ам.

Из аналогом реальным на сегодняшний день есть только accel-ppp под Linux, но он заточен под ISP (я не говорю, что это плохо :) ).
Да, в этом случае магия Cisco побеждает )
А есть какие-то особенности применения, если нет DHCP?
Не знаю, я не пользуюсь Cisco. Я только собирал стенд для ознакомления.
И все-таки на микротике это сделать можно, правда в виде скрипта, срабатывающего при выдаче DHCP адреса.
Так же вместо статических маршрутов можно использовать такую конструкцию:
1.1.1.1 — адрес шлюза
1.1.1.2 -адрес клиента 1
1.1.1.3 -адрес клиента 2
/interface vlan
add arp=proxy-arp disabled=no interface=ether1 l2mtu=9010 mtu=1500 name=Client1 use-service-tag=no vlan-id=100
add arp=proxy-arp disabled=no interface=ether1 l2mtu=9010 mtu=1500 name=Client2 use-service-tag=no vlan-id=101
/ip address
add address=1.1.1.1/32 disabled=no interface=Client1 network=1.1.1.2
add address=1.1.1.1/32 disabled=no interface=Client2 network=1.1.1.3
Не подходит для RouterOS 3.x (хотя сомневаюсь что у кого-то такие динозавры остались). Там нельзя назначить двум разным интерфейсам одинаковый IP адрес. Но, безусловно, решение красивое.
Это больше выглядит как заметка во внутренней вики конторы, но никак не статья. Сложно въехать, для чего оно вообще.
Это и не статья. Это заметка-рецепт для небольших и небогатых интернет-провайдеров, которые используют Mikrotik и хотят экономить публичные IP-адреса, выделяемые клиентам. Что именно вам не понятно?
Вместо arp proxy можно делать статический маршрут на другой стороне. Можно даже раздавать этот маршрут по DHCP.

Одна беда — не все клиенты нормально воспримут ip-адрес в подсети /0.
Не получится. Вернее получится, но когда клиентов будет, допустим, 50, то и маршрутов столько же. Не подходит. К тому же я специально не затрагивал DHCP, поскольку область применения описанного способа чуть другая, чем там где DHCP нужен.
В смысле — маршрутов столько же? Они же все, которые от клиента, прекрасно агрегируются в один.
Допустим, есть три клиента. Одному выдали 123.45.60.100, другому 123.45.60.105, третьему 123.45.60.107. Как они смогут сагрегироваться?
Sign up to leave a comment.

Articles