2013-06-21 3 views
1

Предположим, я хочу назначить адреса IPv6 людям из диапазона 2001: 0DB8 ::/32. Большинство из них выдаются последовательно, но некоторые из них не являются последовательными. Эта таблица DB показывает, какие адреса уже были назначены.Вычисление расстояния до следующего доступного IP-адреса

+-----------------------------------------+ 
|     Address     | 
+-----------------------------------------+ 
| 2001:0DB8:0000:0000:0000:0000:0000:0001 | 
| 2001:0DB8:0000:0000:0000:0000:0000:0002 | 
| 2001:0DB8:0000:0000:0000:0000:0000:0003 | 
| 2001:0DB8:0000:0000:0000:0000:0000:0009 | 
| 2001:0DB8:0000:0000:0000:0000:0F00:0001 | 
| 2001:0DB8:0000:0000:0000:0000:0F00:0002 | 
+-----------------------------------------+ 

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

Что я хочу сделать, это назначить пользователям следующий доступный адрес, начиная с начала подсети. В этом случае было бы легко начать с самого начала, обнаружите, что в 2001 году нет записи: 0DB8 :: 4 и использовать ее. Но в конечном итоге следующий доступный адрес может быть в тысячах или миллионах шагов от начала подсети. Прогулка по базе данных по одному адресу за раз была бы плохой идеей.

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

+-----------------------------------------+--------------------+ 
|     Address     | Steps to next addr | 
+-----------------------------------------+--------------------+ 
| 2001:0DB8:0000:0000:0000:0000:0000:0001 |     1 | 
| 2001:0DB8:0000:0000:0000:0000:0000:0002 |     1 | 
| 2001:0DB8:0000:0000:0000:0000:0000:0003 |     6 | 
| 2001:0DB8:0000:0000:0000:0000:0000:0009 |   15728632 | 
| 2001:0DB8:0000:0000:0000:0000:0F00:0001 |     2 | 
| 2001:0DB8:0000:0000:0000:0000:0F00:0003 |     | 
+-----------------------------------------+--------------------+ 

, но я не уверен, что мне помогает , Если IP-адрес назначается где-то посередине разреженной секции, мне все равно придется рассчитать, сколько шагов от этого адреса до следующего в последовательности, а затем вернуться к назначенному адресу шкафа перед новым и исправить свои «шаги к следующему addr». Все еще кажется медленным процессом.

Есть ли лучший способ сделать это?

+2

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

+0

@MichaelHampton Я искренне заинтересован в том, как вы лучше всего придумаете алгоритм назначения адресов. Вероятно, вне темы в качестве ответа на этот вопрос (поскольку он касается увеличения уже существующей базы данных IPAM), но с нетерпением ждем, чтобы это стало ответом на совершенно новый вопрос. –

+0

@JeremyVisser Вот что такое DHCP для ... –

ответ

1

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

Сохраните исходный стол, но отдельно храните поле next_address (скажем, в таблице Settings). При первом развертывании кода next_address начнется с 2001:db8::1.

Ваш get_next_address() функция будет выглядеть примерно так:

def initialise_settings(): 
    if not Settings.exists('next_address'): 
     Settings.set('next_address', IPv6('2001:db8::1')) 

def get_next_address(): 

    next = Settings.get('next_address') 

    # Check for already filled rows -- breaks loop upon finding gap 
    while Database.row_exists({'Address': next}): 
     next += 1 

    Settings.set('next_address', next + 1) 
    return next 

get_next_address() # 2001:db8::4 
get_next_address() # 2001:db8::5 
get_next_address() # 2001:db8::6 
# ... 
get_next_address() # 2001:db8::f00:0 
get_next_address() # 2001:db8::f00:2 
get_next_address() # 2001:db8::f00:4 
get_next_address() # 2001:db8::f00:5 
+0

Да, я унаследовал БД, где стратегия назначения варьируется. Чаще всего следующий доступный IP-адрес - это то, что нужно, но хороший кусок адресов уже назначен на основе таких факторов, как MAC-адрес устройства и т. Д. Я думаю, что я понимаю ваше решение - вы скорее сохраняете фактический следующий доступный адрес чем шаги к следующему адресу - но не будет ли следующий расчет по-прежнему иметь значительное замедление, если есть пробел в несколько миллионов адресов между двумя назначенными адресами? Но, возможно, это неизбежно, по крайней мере, для первоначального запуска. –

+0

Если есть большой блок уже выделенных адресов, на которые вы столкнулись, тогда да, потребуется время для повторения этого.Но я думаю, что простота алгоритма перевешивает недостатки. В конце концов, вам гарантировано, и это относительно легко понять. Простота понимания несет в себе внутреннюю надежность. :-) –