Запрос на добавление функции /31 подсеть

Назначьте /32 на интерфейс, для «другого» IP /32 сделайте статический маршрут с gateway=интерфейс. Например, 192.0.2.176/31 — это провайдер, 192.0.2.177/31 — вы. Попробуйте так:
/ip address add address=192.0.2.177/32 interface=ether1
/ip route add dst=192.0.2.176/32 gateway=ether1
/ip route add dst=0.0.0.0/0 gateway=192.0.2.176 Конечно, настоящая поддержка распространённого RFC лучше любого костыля — всегда и дважды в воскресенье.

Поддерживаю эту просьбу о добавлении функции и хочу добавить, что любые упоминания про /32 хак, как противоречащие RFC и принадлежащие исключительно программному обеспечению Mikrotik, следует считать вредоносными и явно указывать в документации как нежелательные.

Конечно. Ты прав. Просто хочу сказать, что я пользовался этим и не вижу никаких проблем. Пока что нет ничего лучше и работающего.

Плюс один.

Хмм, mrz, хорошо, префикс 32 бита не является фирменной разработкой Mikrotik и не нарушает RFC. Но всё же /31 полезно использовать на точка-точка каналах, чтобы экономить IP-адреса в адресном пространстве. Некоторые провайдеры, с которыми мне доводилось иметь дело, тоже назначают /31. Кроме того, /31 уменьшает размер таблицы маршрутизации, что удобно при использовании любых протоколов маршрутизации — вместо двух /32 в таблице будет один /31. Так что, на мой взгляд, это плюс два.

/31 действительно работает на Mikrotik, если Mikrotik — это хост с нечетным номером. Я проверял это на RoS v6.28 с маршрутизатором Cisco в роли хоста с четным номером, и всё отлично работает. OSPF формирует соседство, как и должно быть. Но если Mikrotik — это «сетевая» сторона, тогда не работает. Для такой стороны можно использовать /32 как локальный адрес и добавить статический маршрут /31 с gateway=etherX, чтобы маршрут попал в таблицу. (разумеется, так он корректно не попадёт в OSPF).  

Причина, по которой я вообще ответил — есть способ, который сэкономит вдвое больше IP при назначении адресов клиентским каналам:  
1. Добавьте «черную дыру» на некий мастер-префикс сети, например 192.0.2.0/24 → black hole.  
2. Назначьте 192.0.2.1/32 и 192.0.2.255/32 как IP на «loopback» мостовом интерфейсе на ВСЕХ маршрутизаторах.  
3. Включите arp-type=proxy-arp на всех интерфейсах, которые должны участвовать в этом /24.  
4. Используйте обычные /30 адреса на активных OSPF интерфейсах — можно брать приватные IP, если хотите максимально оптимизировать.  
5. Для каждого подключенного клиента создайте /32 маршрут с gateway=etherX (или vlanX — интерфейс, уникальный для клиента) и pref-source=192.0.2.1.

Заметьте, что каждый маршрутизатор хранит anycast-адреса .1 и .255, так что «широковещательный» трафик не летит по всей сети, а пинги до default GW от клиентов отвечаются их реальным шлюзом по умолчанию.  

*ИЗМЕНЕНИЕ: Это работает, но у Mikrotik есть чуть проще способ того же самого. Вместо маршрута «черная дыра» для 192.0.2.1/32 назначайте IP интерфейса клиента как 192.0.2.1/32 и задавайте network=192.0.2.X (где X — IP клиента). Статический маршрут /32 с gateway=etherX/vlanX уже не нужен. Этот метод автоматически создаст «подключённый» маршрут для /32 клиента, и OSPF «увидит» его как естественный маршрут, так что не придётся его перераспределять в OSPF. При этом arp=proxy-arp нужен, чтобы клиент мог общаться с другими участниками /24.  

В нашей компании это решение прозвали «секретным соусом», и у него много преимуществ:  
- Не создаёт дополнительных записей в таблице маршрутизации по сравнению с /31, но при этом позволяет упаковать целых 253 клиента в один /24.  
- Каждый клиент находится в своём приватном слой 2 широковещательном домене, так что клиенты никак не смогут атаковать друг друга через WAN-интерфейсы с помощью broadcast-атак вроде netcut, rogue DHCP, rogue RA (IPv6-аналог) и прочего.  
- IPv6 можно назначать любым способом, который выберете (/127, /64, только link-local и т.д.).  
- Адреса из этого диапазона можно назначать на любом маршрутизаторе, хотя разумно держать их сгруппированными.  
- Клиент не сможет сам назначать произвольные адреса из /24 — будет работать только тот, для которого создан /32 маршрут.  
- Если клиенту нужны дополнительные IP, можно назначать их ровно столько, сколько нужно, без потерь на подсети (добавлять адреса с помощью дополнительных /32 маршрутов на интерфейс или маршрутизировать их через существующий /32 как next hop).  

Таким образом, единственное место, где остаётся «потерянное» адресное пространство /31 — это магистральные каналы внутри собственной инфраструктуры, их гораздо меньше, так что отсутствие /31 на каналах клиентов не будет большой проблемой, если использовать этот «секретный соус».

Я использую указанные выше обходные пути с маршрутом /32 PtP, чтобы запустить мой WAN с назначенным провайдером адресом /31. Однако L2TP не работает из-за отсутствия маршрута WAN/31. Так что есть веские причины для правильной поддержки маршрутов /31 в RouterOS, ведь отсутствие этих маршрутов ломает любые сервисы, которые зависят от маршрутизации (BGP, L2TP, скорее всего IPsec тоже).

Нам это очень нужно, так как у нас мало IPv4, а мы используем много /32.

+1 Все хаки не работают с BGP. IP-адрес, назначенный провайдером, заканчивается на .255/31, я получаю маршруты BGP, но они отмечены как неактивные. Есть решение?