Поделюсь одним случаем из телекоммуникационной практики.
У нас стоит циска 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. Если интересуют технические подробности реализации новой схемы или какие-то вопросы, я добавлю их в топик.
У нас стоит циска 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. Если интересуют технические подробности реализации новой схемы или какие-то вопросы, я добавлю их в топик.
