Просмотрев большинство тематических постов на хабре был безмерно удивлён тому факту, что крайне скудно освещена тема использования ОС Unix/Linux на службе интернет провайдеров (Internet service provider). Данной статьёй я частично попытаюсь восполнить данный пробел.

Почему в сети интернет наблюдается полное отсутствие таких статей догадаться не сложно — всех кто использует Linux/FreeBSD в ISP сразу же обвиняют в нищебродстве и советуют купить Cisco или уж на совсем крайний случай Juniper. Именно поэтому вторая цель данной статьи показать читателю, что некоторые технические решения на базе ОС Linux по многим показателям на порядки превосходят брэндовые решения от самых известных вендоров.

Шейпинг

Наш первый опыт «нестандартного» использования Linux появился сразу после начала предоставления услуг широкополосного доступа для физических лиц. Необходимо было чем-то «порезать» внешний канал каждого из наших пользователей. Здесь ввиду отсутствия собственных наработок на данную тему пришлось изобретать свой собственный велосипед применяя cbq и собственной обвязки к нему. Данная схема проработала пару месяцев пока мы не осознали всех ее минусов и не упёрлись в производительность машины.

Все дело в том, что система начала «съедать» слишком много soft interrupts даже при не большом трафике, на вскидку при транзитном трафике в 300 мегабит и 30 kpps при 1000 линейных правил cbq (по 2 правила вход/выход на пользователя) на каждом интерфейсе в top si достигал 100%.

Если бы в данный момент перед нами бы встала та же самая задача при тех де самых технических средствах мы бы решали ее с помошью Linux htb tc + хэш фильтры.

NAT

Так как на тот момент мы являлись небольшим местячковым домашним провайдером, то при подключении абонентов физических лиц у нас остро встал вопрос выдавать ли клиенту «белый» маршрутизируемый ip адрес, либо ограничиться выдачей «серых» ip адресов.

Остановились на «серых» адресах, т. к. при их использовании существенно экономился столько ценных на тот момент материал как реальные адреса. Также несколько повышалась безопасность и комфортность работы наших пользователей, т. к. извне их компьютеры не были доступны всей сети интернет «напрямую».

Для NAT-а было выбрано оборудование Cisco в частности Cisco ASA 5505 — на тот момент ее мощности было достаточно чтобы покрыть потребности наших клиентов.

В то же самое время ВДРУГ появилась информация, что заказанная нами Cisco ASA несколько подзадержится, и собственно встал вопрос чем от NAT-ить 100Мбит/с поток.

«На коленке» был собран тестовый стенд из обычного офисного PC-ка с 2 сетевыми гигабитными адаптерами и выяснилось, что при небольшом тюнинге этот самый обычный «писюк» с самыми обычными реалтеками способен отнатить нужный нам поток.

После замены железа через один из наших NAT серверов в пиках проходило 1800 мбит/с (да, да это не описка, трафик почти 2 гигабита/с) при сравнительно небольшой нагрузке на систему.

NETFLOW

Столкнувшись с проблемой сбора статистики работы домашних пользователей до NAT-а т. е. c «серыми» адресами пришли к простейшей схеме получения статистики NETFLOW.

Собрали схему при которой мы «выгоняем» копию всего трафика пользователей (SPAN PORT) в нужные сетевые порты сервера с ОС Linux на борту, а далее с помощью ipt_NETFLOW формируем поток FLOWS на нужный сервер.

Более подробно вместе с конфигами схема работы приведена здесь.

P.S. Мы в курсе, что большинство оборудования Cisco может лить уже сформированный NETFLOW поток в указанный Netflow коллектор, но в нашей схеме сети на тот момент такого оборудования просто не могло быть 🙂

Терминация пользовательских сетей.

Изначально хотелось дать пользователю ip адрес, маску подсети, и шлюз и не грузить его настройками PPPoE, PPTP, VPN что в конечном итоге должно было несколько разгрузить службу технической поддержки (что и произошло на практике), так как настройка сети становилась достаточно тривиальной в любой пользовательской ОС.

Решив применить наш предыдущий опыт использования ОС Linux пришли к следующей схеме, в ключевых местах сети устанавливаются Linux сервера с парой четырех-портовых сетевых адаптеров, один линк «уходит» в сторону ядра сети остальные в сторону «кластеров». В результате на каждом интерфейсе поднимается куча VLAN-ов с несколькими сетями в каждом из них.

Всего у нас на всю сеть было 4 сервера примерно по 10k абонентов на каждом.

Пиковый трафик достигаемый каждым сервером в часы пик стремился к полутора мегапакетам в секунду. Сервера обменивались друг с другом маршрутами по протоколу ospf.

Блокирование доступа пользователям осуществлялось с помошью ipset.

Бордер

Тут бы на этой счастливой ноте и закончить, но хочется написать о еще одном «не стандартном» применении Linux — в качестве бордера. Так получилось, что у нас вышла из строя Cisco ASR выполняющая функции бордера на который приходило 2 full view от двух аплинков.

Здесь следует небольшое лирическое отступление. Компания Cisco на 100% сдержала свои обязательства и выслала замену в течении нескольких часов после заполнения необходимых документов, но как Вы понимаете клиенты не будут ждать сутки пока новое железо прилетит в наши края. Решение было спонтанным.

Со склада взяли сервер установили на него Linux + quagga и благополучно поставили вместо вышедшей из строя Cisco.

В час пик это чудо инженерной мысли «прожевало» входящий поток 1.4Гбит/c, при суммарном kpps на всех интерфейсах порядка 400.

P.S. В ходе работы нами было собрано и протестировано множество RPM пакетов для дистрибутива CentOS 5 вот лишь небольшой их список:

• ipset
• connlimit
• conntrack-tools
• ipt_netflow
• flow-tools
• quagga

Cкачать их можно из данного репозитория.