Планирование подсетей - часть вторая.

Рассмотрим часто встречающуюся схему подключения: N клиентов, у которых внешние интерфейсы маршрутизаторов находятся в одной подсети, и на эти интерфейсы маршрутизируются блоки /56 (в соответствии с рекомендациями RIPE).

Количество клиентов (интерфейсов) в одной подсети вряд ли превзойдет 254, то есть одной подсети /64 на «внешние» интерфейсы хватит. А вот количество бит, необходимых для выбора делегируемых префиксов, необходимо вычислить. Далее исходим из предположения, что границы делегируемых участков формируем строго по границе «ниблов», то есть длину префикса выбираем кратной 4, чтобы повысить наглядность и упростить работу с реверсными зонами.

Количество подсетей для N клиентов, составляет (разумеется) N, а количество бит k определяем исходя из соотношения

2k > N (1)

причем должно иметь место строгое неравенство, чтобы зарезервировать блок адресов для служебных нужд (например, для тех же внешних клиентских интефейсов). Кстати, такой выбор целесообразен и с точки зрения оптимизации таблицы маршрутизации.

Из (1) следует, что минимальное значение опредляется как

k=log2N, или точнее k=int(log2N)+1 (2)

так как количество бит — величина целочисленная.

Аналогично вычисляется ближайшее число бит, кратное 4, то есть определяется количество ниблов:

k= int((int(log2N)+1)/4) + 1 (3)

Выражение (3) несложно реализовать даже в Excel, поскольку там есть встроенные функции и для натурального логарифма, и для логарифма по произвольному основанию.

Вот несколько примеров (во второй колонке фактически показано требуемое число ниблов):

    NN ниблов бит
    6      1    4
    15     1    4
    17     2    8
    63     2    8
    255    2    8
    257    3    12
    4095   3    12
    4097   4    16
    65535  4    16

Есть естественные ограничения: в вашем распоряжении вовсе не 128 бит, а:

… и получаем, что в вашем распоряжении остается всего 24 бита, то есть более 16 миллионов подсетей /56, что совсем не мало.

А можно обойтись и без вычислений, поскольку видно, что:

.. и остается совсем немного бит..

Так, если у вас есть статус LIR, то есть блок /32, и вы делегируете клиентам /56, то в самых «ходовых» подсетях

до 255 клиентов — у вас остается 56-32-8=16 бит, то есть более 65,000 подсетей, до 4096 клиентов — у вас остается 56-32-12=12 бит, то есть 4096 подсетей.

Остановимся на «универсальном» варианте с количеством клиентов до 255. При этом у вас остается 16 свободных бит, половину из этого пространства можно использовать как метку сайта (района, региона, площадки и т.д.). Адрес при этом будет иметь вид:

2001:db8:NNNN:xx00::/56,

где 2001:0db8 — ваш префикс, NNNN — код сайта (обьекта), xx — номер подсети /56 на сайте (до 256 подсетей)

Итак, получается такая раскладка:

.. и не забываем выделить 2001:db8:x000::/56 для служебных нужд.

Если вы хотите использовать в подсети до 4095 клиентов с делегированием /56 каждому, то расклад будет такой:

2001:db8:NNNx:yz00::/56,

где xyz — идентификатор подсети /56, маршрутизируемой клиенту

.. и у вас остается всего 12 бит для обозначения сайтов. С другой стороны, 4096 крупных подразделений, в котором до 4095 пользователей — не так уж и мало.

То есть: на идентификацию сайта и на делегирование подсети /56 клиенту остается 56-32=24 бита, которые вы делите на 2 части: на идентификатор сайта и на идентификатор подсети. Если поделить поровну, по 12 бит, то получим по 4096 подсетей и 4096 сайтов, что тоже неплохо. Другое дело, что такое количество клиентов в одной подсети создает серьезные проблемы с обеспечением безопасности (arp-шторм, RA-флуд и проч. ND-подмены).

Вариантов разбиения по границе ниблов не так уж много: 4+20, 8+16, 12+12, 16+8 и 20+4.

Практический пример разбиения LIR-блока на подсети с числом клиентов до 255 и с делегированием /56 каждому клиенту.

Случай 1: внешние интерфейсы клиентского оборудования находятся в общей разделяемой подсети.

Предположим, речь идет об обьекте 007. Тогда:

Вообще-то тут получается 254 подсети, но в случае появлени 255го клиента можно использовать зарезервированный блок 2001:db8:7:ff00:/5.

Случай 2: на обьекте снова до 255 клиентов, но используется ррр-соединение или «vlan-per-client». Тогда планируем пространство так:

Случай 3: у провайдера 5 обьектов, на каждом до 5000 клиентов. Очевидно, на маркировку обьекта хватит 1 нибла, а 5000 клиентов разбиваем на сегменты по 256. Итого, 20 сегментов, на их нумерацию нужно 5 бит, округляем до 8 (ближайшее превосходящее число, кратное 4). Вывод: на служебные цели нужно 1+2=3 нибла (12 бит).

Получаем структуру:

2001:db8:00NM:MM00:: где N — код обьекта, а MMM — код сегмента. Остальное — по аналогии со случаем №1 или №2.

Все просто..

Итак, в большинстве случаев для LIR категории small подойдет такая структура адреса:

2001:db8:pqrs:mnxx::

где pqrs (16 бит) — код или номер крупного формата (филиал, город, район), причем можно смело писать p=0 q=0 и резервировать 8 бит на будущее

mn — маршрутизируемая клиенту подсеть /56 (разумеется, при этом хх="00")

и остается только зарезервировать первый и последний сегменты для своих целей.

То есть (для ясности использована полная форма записи адреса):

2001:0db8:01[0-f][0-f]:[0-f][0-f][0-f][0-f]:: — подсети на обьекте (в том числе и /56 для клиентов)

Подробнее: обьект 01 и его подсети:

Первая подсеть:

Тот же обьект 01, вторая подсеть (тоже до 254 клиентов)

это — диапазон от 2001:db8:102::/64 до 2001:db8:102:ffff::/64

где

Ваш IP

Этот адрес отвечает на пинги

ASN в России