Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Интернет уперся в очередные 512К 14.08.14 13:39
Publisher: dl <Dmitry Leonov>
|
Интернет уперся в очередные 512К
ZDNet http://www.zdnet.com/internet-hiccups-today-youre-not-alone-heres-why-7000032566/
На днях полные таблицы маршрутизации протокола BGP [ http://bugtraq.ru/rsn/archive/2008/08/15.html ] у ряда крупных провайдеров преодолели рубеж в 512 тысяч записей, что начало приводить к проблемам связности, а некоторые хостинговые компании (например, LiquidWeb) просто полностью упали.
Суть проблемы заключается в следующем. Таблицы маршрутизации обычно хранятся в специализированной памяти TCAM (Tertiary Content Addressable Memory). В широко распространенных маршрутизаторах класса Cisco 7600/Catalyst 6500 объем этой памяти не менялся годами и рассчитан на миллион записей (на самом деле 1024К). Эти 1024К в стандартной конфигурации поделены на 512К для IPv4 и 256К для IPv6 (который требует удвоенного объема памяти). Превышение этих порогов может привести к самым разным эффектам от выпадения маршрутов до полного краха маршрутизаторов.
Первые предупреждения начали раздаваться уже пару...
Полный текст
|
|
А нефиг было вводить IPv6! 14.08.14 14:57
Автор: Den <Денис Т.> Статус: The Elderman
|
Чего проще было сделать какой-нибудь IPv5.1, в котором первая часть заголовка в точности совпадала с IPv4, но поля адресов хранили бы старшие значения адресов отправителя и получателя, а младшие значения адресов указывались в расширенной части заголовка?
Скольких проблем можно было избежать...
|
| |
и что бы это изменило? 14.08.14 15:57
Автор: dl <Dmitry Leonov>
|
|
Для полной информации о маршрутизации в этом случае все равно было бы необходимо хранить весь этот составной адрес. Если, конечно, не считать, что раздаются только блоки, основанные на старшей части адреса.
|
| | |
Именно! 15.08.14 15:06
Автор: Den <Денис Т.> Статус: The Elderman
Отредактировано 15.08.14 15:06 Количество правок: 2
|
> Для полной информации о маршрутизации в этом случае все
> равно было бы необходимо хранить весь этот составной адрес.
> Если, конечно, не считать, что раздаются только блоки,
> основанные на старшей части адреса.
Именно!
Можно было оставить глобальную IPv4 адресацию без изменений, условившись, что IANA раздает IP адреса исключительно для узлов поддержки сетей провайдеров (маршрутизаторов, DNS серверов и т.д.). А провайдеры, в свою очередь, раздавали бы клиентам адреса из диапазона младших адресов (расширенная часть заголовка). Тогда не пришлось бы ничего переделывать, маршрутизаторы обрабатывали бы заголовок так же, как заголовок IPv4 и не держали бы почти неиспользуемую область памяти для маршрутов IPv6. Потребовалось бы лишь добавить небольшой дополнительный функционал для хранения маршрутов к клиентским хостам внутри сети провайдера.
|
| | | |
проблема в том, что старшие адреса уже заканчиваются 15.08.14 23:13
Автор: dl <Dmitry Leonov>
|
|
А отобрать распределенные и перетасовать заново, устроив аккуратную сегментацию, уже не получится.
|
| | | | |
Сейчас проблема заключается в том, что провайдеры и домашние... 19.08.14 09:42
Автор: Den <Денис Т.> Статус: The Elderman
|
|
Сейчас проблема заключается в том, что провайдеры и домашние сети динамически раздают физ. лицам IANA IP адреса. Т.е. провайдеры и домашние сети держат у себя огромные пулы адресов "белых" IP, тогда как как каждый из них, в случае расширения протокола IPv4 до упомянутого функционала, мог бы обойтись лишь одним IPv4 адресом. Между тем, IP адреса выкупаются не на вечно, а сдаются в аренду на год, так что проблемы с перераспределением IP адресов как бы и нет.
|
| | | | |
Проблема, имхо, не столько алгоритмическая, сколько реализационная. 16.08.14 08:58
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
