Когда маршрутизатор не справляется с нагрузкой
Поделюсь одним случаем из телекоммуникационной практики.
У нас стоит циска 26-й серии (2620XM). На ней заведено около четырёх десятков сабинтерфейсов. Большинство для локальных абонентов, расположенных в том же здании, и есть несколько линков на дальние точки. Среди них аэропорт, кирпичный завод, горнолыжный комплекс, совхоз. «Да это ж старьё непотребное» — скажете вы и будете правы, но так исторически сложилось. Однако суть не в этом.
И вот некоторое время назад оказалось что нагрузка слишком высока. Сначала это проявлялось в некоторых задержках при работе в консоли. Типа набираешь команду, а буквы появляются не сразу а немного с задержкой. Потом периодически стал увеличиваться пинг до циски с удалённых точек. Следующий симптом — иногда отваливающийся канал в интернет (при этом маршрутизация внутри локальной сети работала безупречно и потерь не было). А в логах тем временем жуткая картина о сильно активном использовании CPU. Загрузка процессора не опускается ниже 80%, а большую часть времени 95-99%. Теперь пинг стал теряться даже если ты находишься в той же подсети. Интернет захромал на обе ноги.
Проблемы было две: эта циска выполняла функции NAT’а, который очень нехило нагружает маршрутизатор, и наличие всего одного интерфейса на борту. Такая схема подключения называется маршрутизатор на палочке, потому что от свитча идёт всего один линк до него, а все подсети заводятся на сабинтерфейсах. Получается, что весь трафик — даже локальный в рамках одного здания проходит через один порт и через него же идёт весь трафик, исходящий вовне. Кроме того циска также передавала голос от одной АТС к другой.
Так дальше продолжаться не могло. И настал один прекрасный момент, когда сеть большую часть дня просто лежала. Практически перестал ходить даже локальный трафик. До кучи это совпало с важной телефонной конференцией одного из абонентов (больше половины звонков отбрасывалась из-за высокой нагрузки) и не менее важной презентацией другого. Меры нужны были экстренные — если на следующий день всё повторится, то последствия будут просто непоправимыми — подошёл срок сдачи бухгалтерской отчётности. Еле ворочается не только интернет, но и связь с серверами 1С и Галактики.
Покупку нового более производительного маршрутизатора скорее всего бы не одобрили, тем более, что на полке лежала 48-портовая каталиста и ещё одна 26-ая циска. Да и придти он физически не успеет. Каталист 3550 — это L3-коммутатор и вполне справляется с маршрутизацией. Кроме того на нем можно настраивать L3-интерфейсы, то есть не привязывать их ВЛАН’ам, а назначать на них IP.
Вторая циска 26-й серии с двумя портами, что позволит не пускать весь трафик через одну дырку: локальных абонентов подключить к одному порту, а второй выделить под аплинк к удаленному бордеру.
Решение в общем-то простое:
1)Выносим NAT на отдельный маршрутизатор. (Он будет заниматься исключительно NAT’ом и маршрутизацией белых IP)
2)Выносим все сабинтерфейсы на каталисту (это облегчит передачу данных по локальной сети и разгрузит восходящий канал)
3)Старая циска остаётся только для телефонного транзита.
На схеме это можно выразить примерно так:
Розовым отображён маршрут пакета, отправленного в интернет, сиреневым путём следует внутренний пакет с адресатом из сети 172.16.0.0/16. Зелёный — путь телефонного вызова.
То есть, если пакет отправляется в сетку 172.16.0.0, то каталиста маршрутизирует его в соответствии со своей таблицей, а шлюзом по умолчанию является маршрутизатор, который проивзодит натинг и если пакет отправлен не в 172-ую сеть, то он натится на белый IP и отправляется по другому логическому каналу прямиком на бордер. При этом второй маршрутизатор просто выполняет функцию едва ли не голосового шлюза — принимает по E1 данные от АТС и по Ethernet вместе с остальным локальным трафиком отправляет на другую циску.
Схема не очень рациональная в плане использования железа. Но как временная всё же сгодится.
Это сильно снизило нагрузку на оборудование — средняя загруженность процессора маршрутизатора для NAT’а составляет 20-30%, у каталисты и того меньше. Проблемы прекратились.
У такого подхода есть один существенный недостаток — каталиста всё-таки не маршрутизатор в полном смысле этого слова. Например, на ней нельзя вешать rate-limit на логический интерфейс, да и с физическим всё сложно. В лучшем случае получится ограничить скорость входящего на интерфейс трафика для конкретного acl, но кому оно надо?
Следовательно, как красиво бы мы не выкрутились из ситуации, нужно покупать нормальный производительный маршрутизатор и строить классическую схему.
P.S. Если интересуют технические подробности реализации новой схемы или какие-то вопросы, я добавлю их в топик.
Снижение нагрузки на маршрутизаторы
Одной из основных целей изменения формата заголовка протокола IPv6 было снижение накладных расходов, то есть уменьшение объема служебной информации, передаваемой с каждым пакетом. Для этого в новом протоколе IP были введены понятия основного и дополнительных заголовков. Основной заголовок присутствует всегда, а необязательные дополнительные заголовки могут содержать, например, информацию о фрагментации исходного пакета, полный маршрут следования пакета при маршрутизации от источника, информацию, необходимую для защиты передаваемых данных.
Основной заголовок имеет фиксированную длину в 40 байт, его формат показан на рис. 18.22.
Рис. 18.22. Формат основного заголовка
Поле следующего заголовка соответствует по назначению полю протокола в версии IPv4 и содержит данные, определяющие тип заголовка, который следует за данным. Каждый следующий дополнительный заголовок также содержит поле следующего заголовка. Если IP-пакет не содержит дополнительных заголовков, то в этом поле будет значение, закрепленное за протоколом TCP, UDP, RIP, OSPF или другим, определенным в стандарте IPv4.
В предложениях по поводу протокола IPv6 фигурируют пока следующие типы дополнительных заголовков:
□ заголовок маршрутизации — указание полного маршрута при маршрутизации от источника;
□ заголовок фрагментации — информация, относящаяся к фрагментации IP-пакета (поле обрабатывается только в конечных узлах);
□ заголовок аутентификации — информация, необходимая для аутентификации конечных узлов и обеспечения целостности содержимого IP-пакетов;
□ заголовок системы безопасности — информация, необходимая для обеспечения конфиденциальности передаваемых данных путем шифрования и дешифрирования;
□ специальные параметры — параметры необходимые для последовательной обработки пакетов на каждом маршрутизаторе;
□ параметры получателя — дополнительная информация для узла назначения.
Таким Образом, IP-пакет может иметь, например, формат, показанный на рис. 18.23.
Рис. 18.23. Структура IРv6-пакета
Поскольку для маршрутизации пакета обязательным является лишь основной заголовок (почти все дополнительные заголовки обрабатываются только в конечных узлах), эго снижает нагрузку на маршрутизаторы. В то же время возможность использования большого количества дополнительных параметров расширяет функциональность протокола IP и делает его открытым для внедрения новых механизмов.
Для того чтобы повысить производительность маршрутизаторов Интернета в части выполнения их основной функции — продвижения пакетов, в версии IPv6 предпринят ряд мер по освобождению маршрутизаторов от некоторых вспомогательных задач.
□ Перенесение функций фрагментации с маршрутизаторов на конечные узлы. Конечные узлы в версии IPv6 обязаны найти минимальное значение MTU вдоль всего пути, соединяющего исходный узел с узлом назначения (эта техника под названием Path MTU Discovery уже используется в IPv4). Маршрутизаторы IPv6 не выполняют фрагментацию, а только посылают ICMP-сообщение о слишком длинном пакете конечному узлу, который должен уменьшить размер пакета.
□ Агрегирование адресов ведет к уменьшению размера адресных таблиц маршрутизаторов, а значит, — к сокращению времени просмотра и обновления таблиц. При этом также сокращается служебный трафик, порождаемый протоколами маршрутизации.
□ Широкое использование маршрутизации от источника. При маршрутизации от источника узел-источник задает полный маршрут прохождения пакета через сети. Такая техника освобождает маршрутизаторы от необходимости просмотра адресных таблиц при выборе следующего маршрутизатора.
□ Отказ от обработки не обязательных параметров заголовка.
□ Использование в качестве номера узла его МАС-адреса избавляет маршрутизаторы от необходимости применять протокол ARP.
Новая версия протокола IP, являющаяся составной частью проекта IPv6, предлагает встроенные средства защиты данных. Размещение средств защиты на сетевом уровне делает их прозрачными для приложений, так как между уровнем IP и приложением всегда будет работать протокол транспортного уровня. Приложения переписывать при этом не придется. Новая версия протокола IP со встроенными средствами обеспечения безопасности называется IPSec (Security Internet Protocol — защищенный протокол IP). Возможности этого протокола подробно рассматриваются в главе 24.
Воспользуйтесь поиском по сайту: