Интернет уперся в очередные 512К dl // 14.08.14 13:39
На днях полные таблицы маршрутизации протокола BGP у ряда крупных провайдеров преодолели рубеж в 512 тысяч записей, что начало приводить к проблемам связности, а некоторые хостинговые компании (например, LiquidWeb) просто полностью упали.
[Не забывайте при копировании материала указывать полный адрес источника: //bugtraq.ru/rsn/archive/2014/08/06.html]
Суть проблемы заключается в следующем. Таблицы маршрутизации обычно хранятся в специализированной памяти TCAM (Tertiary Content Addressable Memory). В широко распространенных маршрутизаторах класса Cisco 7600/Catalyst 6500 объем этой памяти не менялся годами и рассчитан на миллион записей (на самом деле 1024К). Эти 1024К в стандартной конфигурации поделены на 512К для IPv4 и 256К для IPv6 (который требует удвоенного объема памяти). Превышение этих порогов может привести к самым разным эффектам от выпадения маршрутов до полного краха маршрутизаторов.
Первые предупреждения начали раздаваться уже пару лет назад, когда размер таблиц превысил 450К (увеличившись за год на 50К), в мае этого года о надвигающемся коллапсе своих покупателей предупредила и Cisco.
Существует два выхода: потратить деньги и срочно обновить маршрутизаторы на более свежие, в которых убраны эти ограничения, либо отложить решение на потом и перенастроить лимиты, увеличив таблицу для IPv4 за счет IPv6 (полная таблица которого сейчас все равно не превышает 20 тысяч записей).
Чего проще было сделать какой-нибудь IPv5.1, в котором первая часть заголовка в точности совпадала с IPv4, но поля адресов хранили бы старшие значения адресов отправителя и получателя, а младшие значения адресов указывались в расширенной части заголовка?
Скольких проблем можно было избежать...
и что бы это изменило?14.08.14 15:57 Автор: dl <Dmitry Leonov>
Для полной информации о маршрутизации в этом случае все равно было бы необходимо хранить весь этот составной адрес. Если, конечно, не считать, что раздаются только блоки, основанные на старшей части адреса.
Именно!15.08.14 15:06 Автор: Den <Denis> Статус: The Elderman Отредактировано 15.08.14 15:06 Количество правок: 2
> Для полной информации о маршрутизации в этом случае все > равно было бы необходимо хранить весь этот составной адрес. > Если, конечно, не считать, что раздаются только блоки, > основанные на старшей части адреса. Именно!
Можно было оставить глобальную IPv4 адресацию без изменений, условившись, что IANA раздает IP адреса исключительно для узлов поддержки сетей провайдеров (маршрутизаторов, DNS серверов и т.д.). А провайдеры, в свою очередь, раздавали бы клиентам адреса из диапазона младших адресов (расширенная часть заголовка). Тогда не пришлось бы ничего переделывать, маршрутизаторы обрабатывали бы заголовок так же, как заголовок IPv4 и не держали бы почти неиспользуемую область памяти для маршрутов IPv6. Потребовалось бы лишь добавить небольшой дополнительный функционал для хранения маршрутов к клиентским хостам внутри сети провайдера.
проблема в том, что старшие адреса уже заканчиваются15.08.14 23:13 Автор: dl <Dmitry Leonov>
Сейчас проблема заключается в том, что провайдеры и домашние сети динамически раздают физ. лицам IANA IP адреса. Т.е. провайдеры и домашние сети держат у себя огромные пулы адресов "белых" IP, тогда как как каждый из них, в случае расширения протокола IPv4 до упомянутого функционала, мог бы обойтись лишь одним IPv4 адресом. Между тем, IP адреса выкупаются не на вечно, а сдаются в аренду на год, так что проблемы с перераспределением IP адресов как бы и нет.
Проблема, имхо, не столько алгоритмическая, сколько реализационная.16.08.14 08:58 Автор: kstati <Евгений Борисов> Статус: Elderman
подробно о проекте
Анализ криптографических сетевых...
