Обратная маска

[jov]

На Linux не работает(

ip route add 10.0.0.0/0.0.0.254 via gretunnel

Error: an inet prefix is expected rather than "10.0.0.0/0.0.0.254".
route реагирует примерно также.

[Megakazbek]

Это потому что автор не слишком разъясняет тот момент, что маска подсети (то есть, определение того, какая часть адреса — это номер сети, а какая — номер хоста) всегда бывает только обычной, в которой сначала идёт непрерывная последовательность единиц, а потом — нулей, а то, про что рассказывается в статье — это не маски подсетей, а способ выделения нужных нам адресов из какого-то их множества.

[Busla]

В RFC1519 про непрерывность нигде явно не говорится, просто он устарел, поэтому поддерживается частично.

[Megakazbek]

Вот именно, что он устарел и заменён на RFC4632, в котором вообще понятие маски подсети выводится из употребления и заменяется на длину префикса.

[Loiqig]

Описанные маски точно работают на маршрутизаторах и L3 коммутаторах Cisco и Brocade(Foundry), конкретно про soft-router не могу сказать потому что ни разу не работал с ними в продакшн.

[fortyseven]

Честно говоря, не могу себе представить РЕАЛЬНОГО сценария применения рваных масок. Если вы до этого докатились, значит допустили ошибку еще раньше на стадии проектирования сети =)

[Rastler]

а если рассмотреть вариант — так уже было и осталось по наследству? :)

[fortyseven]

В свое время вопрос наследия решился плавной миграцией с выпиливанием того, что было)

[dmitryfedoseev]

Обслуживать приходится сети реального, а не идеального мира.

Я использовал рваные маски для рандомизации NATа вручную — нескольких тысяч внутренних адресов транслировал на 64 внешних адреса. Внутренние адреса распределялись неравномерно:
в 172.17.0.0/16 использовалось ~200 начальных,
в 172.18.0.0/16 ~1000,
в 172.19.0.0/16 ~2000,
в 172.20.0.0/16 ~500,
и тд без какой-то закономерности.

NAT делал так:
0.0.0.0/0.0.0.252 -> IP0
0.0.0.4/0.0.0.252 -> IP1
0.0.0.8/0.0.0.252 -> IP2
…
0.0.0.252/0.0.0.252 -> IP63
Вроде не напутал…

Вся конструкция помещалась в цепочку-контейнер для выделения транслируемого диапазона 172.16.0.0/12. Исполнялось на iptables без малейших сложностей.

[fortyseven]

Мощно) подозреваю, что есть способ автоматической рандомизации ;)

[dmitryfedoseev]

вот его и чинил ломал

[Breaker]

Реально я так распределяю юзеров на 2 НАТ-сервера: на один всех четных, на второй — не четных.

[Loiqig]

Например, реальный используемый сценарий: абоненту выделяется сеть на 8 адресов (чтобы он мог использовать дома не роутер, а простой коммутатор и подключать несколько устройств, соответственно). Если баланс в плюсе, то выделяется сеть с 1 по 7, если не в плюсе то 9 до 15. То есть подсети с 3 битом равным 1, должны иметь доступ только к сайту статистике, и возможно каким-то внутренним ресурсам.
Сеть 192.168.0.0/16 бьём на 2-е части следующим образом: 192.168.0.8/0.0.255.247 — 11110111 в последнем октете.

[fortyseven]

Почему в случае неуплаты не выделить ему совсем другую подсеть? (я так понимаю, настройки он получает по DHCP?)

[Loiqig]

Если выделяем другую сеть, мы теряем возможность привязки к пользователю его личной, неизменной, сети в одну строчку с более короткой маской /28, где половинки /29 характеризуют его как безденежного и денежного. На одном L3 интерфейсе находится множество пользователей и применение способа комментарием выше позволяет определить сразу всех разрешённых или запрещённых пользователей, сохраняя при этом свойство описанное в первом предложении.
Но вообще конечно вы правы, насчёт прямоты архитектуры, вот только чтобы мигрировать плавно и безболезненно иногда приходится придумывать странные решения.

[Harkonnen]

Зачем было инвертировать маску, когда можно было изначально вместо упакованной /n нотации для маски применять развёрную a.b.c.d нотацию с её исходной интерпретацией 0/1 бит? (1 — сеть, 0 — хост) Т.е. не раскрыт смысл инверсии, все эти танцы с пропусканием чётных хостов реализуемы и без XOR'ов

[Harkonnen]

имеется в виду без XOR'ов по битам неинверсной маски

[Loiqig]

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

[Harkonnen]

Речь не про ваш способ, а про способ реализованный в этих самых устройствах. Непонятно, зачем было в них городить огород с заменой 0 и 1 битов. А ваше повествование просто очень наглядно демонстрирует странность этой замены — сначала мы делаем вывод, что a.b.c.d запись избыточна по отношению к /n записи, т.к. в маске вначале только биты1, а в конце только биты0. Потом рассматривается инверсия, у которой биты ведут себя наоборот, и в классической /n форме она непредставима (правда представима в гибридной /-n форме). А потом вместо того чтобы забить болт и на ненужную инверсию вместе с неуниверсальной /n нотацией, мы зачем-то юзаем a.b.c.d на инверсной форме, а не на прямой.

[Loiqig]

Очень много поправили и сделали лучше в IPv6, там более последовательное определение, на ошибках учатся. Такая непоследовательность ведь во многих отраслях присутствует…
… про обратную маску для IPv6, пока ничего не знаю — не приходилось.

[qmax]

«ненормальное системное администрирование»