Комментарии 22
Как-то неэффективно используются адреса, даже на вашей картинке это видно. Если вместо 127.0.0.80/29 и 127.0.0.104/29 использовать 127.0.0.8/29 и 127.0.0.16/29, а вместо 127.0.0.160/27 — 127.0.0.32/27, то у вас освободится 127.0.0.128/25 и 127.0.0.64/26.
На первый взгляд, для подобных задач должно хорошо подойди нечто типа SLAB аллокатора, на 5 арен для этой картинки (/28, /27, /26, /25, /24). Допустим, надо выделить блок /28, тогда алгоритм примерно такой:
1. Смотрим, есть ли в арене /28 свободные блоки. Если есть — берём один блок и помечаем его как занятый.
2. Если нету — то идём в арену /27 и берём оттуда свободный блок. Если есть — то изымаем его из этой арены, а в арену /28 помещаем две его половинки. Если нету — то рекурсивно идём наверх. Если в самой крупной арене (/24, в данном случае) ничего нету, то извиняемся перед клиентом.
При освобождении блока возвращаем его в арену соответствующего размера. Если есть 2 блока, которые можно склеить и вернуть в вышестоящую арену — делаем это рекурсивно.
Иногда можно делать дефрагментацию, если договоры с клиентами позволяют менять адреса по запросу хостера.
Плюс данной схемы с в том, что она старается размещать блоки как можно компактнее. Минус в том, что фрагментация всё равно будет. С учётом того, что вам надо /32 адреса клиентам выдавать, придётся делать арены вплоть до /31.
На первый взгляд, для подобных задач должно хорошо подойди нечто типа SLAB аллокатора, на 5 арен для этой картинки (/28, /27, /26, /25, /24). Допустим, надо выделить блок /28, тогда алгоритм примерно такой:
1. Смотрим, есть ли в арене /28 свободные блоки. Если есть — берём один блок и помечаем его как занятый.
2. Если нету — то идём в арену /27 и берём оттуда свободный блок. Если есть — то изымаем его из этой арены, а в арену /28 помещаем две его половинки. Если нету — то рекурсивно идём наверх. Если в самой крупной арене (/24, в данном случае) ничего нету, то извиняемся перед клиентом.
При освобождении блока возвращаем его в арену соответствующего размера. Если есть 2 блока, которые можно склеить и вернуть в вышестоящую арену — делаем это рекурсивно.
Иногда можно делать дефрагментацию, если договоры с клиентами позволяют менять адреса по запросу хостера.
Плюс данной схемы с в том, что она старается размещать блоки как можно компактнее. Минус в том, что фрагментация всё равно будет. С учётом того, что вам надо /32 адреса клиентам выдавать, придётся делать арены вплоть до /31.
А у нас вот такие экселевские таблички. По листу на каждую /24.
До сих пор не знаю кто это придумал, но по-моему гениально по своей простоте.
Скрытый текст
До сих пор не знаю кто это придумал, но по-моему гениально по своей простоте.
все правильно. мы так тоже делали.
это самый удачный способ представления подсетей на бумаге.
это самый удачный способ представления подсетей на бумаге.
Вопрос, а вы не пробовали выдавать не подсети, а отдельные IPшники?
Как делает 1&1 немецкий. Каждый сервер получает конкретный IP, при этом роутер всегда 10.0.0.1
нет лишних потерь вообще, жесткий роутинг, выделять можно по сколько угодно IP за раз кому угодно.
Как делает 1&1 немецкий. Каждый сервер получает конкретный IP, при этом роутер всегда 10.0.0.1
нет лишних потерь вообще, жесткий роутинг, выделять можно по сколько угодно IP за раз кому угодно.
У нас так сделано в Технодоме. В Селектеле этот принцип не используется, иначе придется запретить «миграцию» адресов между серверами, так как при выделении одного адреса он биндится на MAC сервера.
И дальше рутинг по чему? По mac?
Знаю Hetzner так делает.
Знаю Hetzner так делает.
Это еще и самый экономичный способ. Так как выдавать сеть /29 только из-за того что абоненту требуется два IP адреса уже непозволительная роскошь.
а еще можно воспользоваться готовым софтом: racktables.org/
опенсурс. очень удобно.
можно даже прибить IP не к клиенту, а к железу в стойке и влану.
опенсурс. очень удобно.
можно даже прибить IP не к клиенту, а к железу в стойке и влану.
Есть еще продукт попроще iptrack.sourceforge.net — автоматом можно экспортировать из него данные, создавать записи для обратной зоны DNS
Мы используем Netdot — замечательный инструмент для ведения документации сети, в том числе и управления адресным пространством.
Я писал обзорную статью про него здесь на хабре.
Я писал обзорную статью про него здесь на хабре.
У NOC Project очень удобный механизм IPAM
На практике многие до сих транжирят IP-шники.
У меня кабельный провайдер делает совсем смешно: всем кто хочет получить один (!) постоянный IP-адрес, выделяется /30.
У меня кабельный провайдер делает совсем смешно: всем кто хочет получить один (!) постоянный IP-адрес, выделяется /30.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Система учета IP-адресов