» » » О построении провайдерской сети в небольшом городе. Часть 3

 

О построении провайдерской сети в небольшом городе. Часть 3

Автор: admin от 21-02-2014, 11:49, посмотрело: 509

Предыдущие статьи серии:
О построении провайдерской сети в небольшом городе. Часть 2
О построении провайдерской сети в небольшом городе. Часть 1

Прошло более полугода с момента размещения первых двух постов. Был наработан некоторый, хоть и небольшой, опыт эксплуатации при возрастании нагрузки (абонентская база постепенно растет). Внесены некоторые корректировки в настройки оборудования. Также в предыдущих постах я обещал дать оставшуюся часть информации, которую еще не публиковал.

О построении провайдерской сети в небольшом городе. Часть 3

Снова Cisco

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

Применив прокачанный навык «гугление», был найден рецепт — ограничить число соединений с одного внутреннего IP. Опытным путем было установлено, что 500 соединений на одного абонента вполне достаточно. Для организаций же пришлось поднять лимит до 10000 соединений, поскольку количество компьютеров в организациях, находящихся за NAT их бытовых маршрутизаторов, может быть более десяти. Впрочем лимит соединений на организации можно сделать и больше, поскольку работают они в дневное время, когда нагрузка на сеть редко превышает средние значения, а вечером в моменты пиковых нагрузок их активность минимальна.

Установка ограничения для всех:
ip nat translation max-entries all-host 500

Если же требуется установить для какого то IP другое ограничение (например, для организаций):
ip nat translation max-entries host 10.1.0.100 10000

Для просмотра статистики уже установленным ограничениям:
sh ip nat statistics

Ксати, без ввода команды, ограничивающей количество трансляций, невозможно посмотреть статистику по конкретным адресам.

При необходимости узнать настройку на конкретный адрес:
sh ip nat statistics | i 10.1.0.100


Выборка по максимальному количеству трансляций:
sh ip nat statistics | i max allowed N

N — количество трансляций

Также весьма желательно прописать таймауты на отдельные протоколы и порты, чтобы абоненты не жаловались на отсутствие доступа:


Далее спустя месяц наступило время Ч, поскольку у меня был лишь один внешний IP, то общее количество соединений от абонентов превысило максимальное количество трансляций на один внешний адрес. Обеспокоенные клиенты выражали свое обоснованное негодование вечерними «затыками», а я усиленно прокачивал скилл «гугление».

Все делал по инструкции, прописал пул адресов для двух имеющихся Vlan.
ip nat pool vlan2 XX.XX.XX.2 XX.XX.XX.3 prefix-length 24
ip nat pool vlan3 XX.XX.XX.4 XX.XX.XX.5 prefix-length 24

Затем прописал access-list'ы
ip access-list extended NAT1
 permit ip 10.1.0.0 0.0.255.255 any
ip access-list extended NAT2
 permit ip 10.2.0.0 0.0.255.255 any

Ну, и привязал первое ко второму:
ip nat inside source list NAT1 pool vlan2 overload
ip nat inside source list NAT2 pool vlan3 overload

А также удалил из старого access-list'та:
ip access-list extended NAT
 permit ip 10.2.0.0 0.0.255.255 any
 permit ip 10.1.0.0 0.0.255.255 any

И что я получил? А шиш! Дальше я пару дней провел в периодических попытках менять настройки и запустить, но ничего не помогало. Исчерпав все свои варианты, я решил связаться с техподдержкой вышестоящего магистрального провайдера и поинтересоваться — «А прописали ли вы, друзья мои любезные, указанный в договоре пул адресов с маской /24, у себя в маршрутизаторе?» Далее я узнаю — «А этот пул мы отдали другим»… приехали. А на маршрутизатор вообще не прописывали. Вот и верь после этого людям!

В общем история закончилась тем, что мне выдали другой пул адресов с маской /24. Хотя вначале их технический специалист даже пытался брыкаться по принципу «Мы сейчас так щедро пулы не раздаем», но, ладно, ситуация утряслась и все заработало. Абоненты разбежаться не успели и то хорошо.

О построении провайдерской сети в небольшом городе. Часть 3

Настройка UTM5

Настройка самого биллинга подробно описана в поставляющемся «Руководстве администратора», которое идет как в бумажном виде, так и электроном на диске с самим биллингом UTM5. Также руководства можно просмотреть на официальном сайте в разделе «Документация».

Из нестандартного — пришлось прописывать отсутствующие зависимости пакетов, создавая линки с существующих версий пакетов, на уже несуществующие. Эти линки, с большой долей вероятности, придется восстанавливать после каждого обновления пакетной базы используемого дистрибутива. Программисты биллинга почему то не придумали грамотного решения для обхода этого неудобства.

На один из серверов я установил сам биллинг (UTM5 Core — ядро системы), а на шейпер был водружен демон исполнения команд поступающих от ядра (UTM5 RFW). Демон запускает скрипт и передает данные к утилите tc из пакета iproute2, которая и режет трафик.

У этого демона есть одна нехорошая особенность — иногда при перезагрузке системы он запускается криво и не выполняется. Происходит такое один раз на 10-15 перезагрузок системы. Побороть это я не смог, вероятно радиус кривизны у разработчиков был не совсем точно выставлен при разработке. Приходится вручную завершать сервис и перезапускать его или просто еще раз перезагружать систему.

Также в работе шейпера под высокой нагрузкой наблюдается накопление некоторой энтропии (не знаю как это назвать по другому) и деградация пропускной способности. Я эту проблему пока «решил» только перезапуском раз в сутки всего сервера, в ночное время.

Все необходимые настройки системы также описаны в руководстве, я лишь приведу скрипт. В руководстве приведен текст скрипта, для запуска шейпера в режиме NAT, однако у меня шейпер работает в режима Bridge и потому на первых порах пришлось попотеть, сочиняя и отлаживая скрипт. Настройку сервера в режим Bridge я описывал во втором посте. Приведенный в руководстве к биллингу скрипт является упрощенной версией и не учитывает возникновение некоторых конфликтных ситуаций, чего лишен мой доработанный скрипт.



Полезные инструменты

О построении провайдерской сети в небольшом городе. Часть 3

Насколько мне известно на Хабре не много любителей Perl. Не раз встречал отрицательные высказывания в комментариях. Не являясь специалистом в этом языке, не могу знать глубинные причины нелюбви посетителей ресурса к именно этому языку. Мой коллега по бывшей работе, однако, во всю его использовал и весьма успешно. В частности разработал скрипт опроса коммутаторов, который я использую по сегодняшний день. Приведу его текст — вдруг кому то понадобится.


К сожалению у меня пока руки не дошли сделать полноценную систему мониторинга, да и под это дело нужен отдельный сервер, а бюджеты по прежнему ограничены. По этой причине выкручиваюсь как умею.


Настройка NUT — Network UPS Tools

Изначально, руководством, мне был выдан б/у стоечный UPS фирмы небезызвестной APC. Может быть в свои лучшие времена он и обеспечивал хоть какое то время автономной работы, но аккумуляторы на нем были явно на исходе.
О построении провайдерской сети в небольшом городе. Часть 3

После трех историй с отключением серверов при достаточно кратковременном пропадании питающей сети, бешенством негодующих абонентов, и парой тысяч моих нервных клеток павших смертью храбрых, руководство таки решилось на смену аккумуляторов. Однако цена новых аккумуляторов была едва ли не выше половины стоимости нового UPS этой же фирмы. По этой причине были приобретены новые UPS, но уже другой фирмы — Ippon Smart Power Pro 1400. Емкость их достаточна, чтобы выключить сервера при пропадании питания, а при коммутации между двумя резервными линиями не будет пропадания питания.

Настройка NUT достаточно простая операция, а необходимые пакеты присутствуют в репозиториях дистрибутива ALT Linux, который используется для работы биллинга и шейпера.

У меня получились такие настройки для NUT:
ups.conf
[ippon]
	driver = blazer_usb
	port = auto
	desc = "Ippon Smart Power Pro 1400"


upsd.conf
ACL all 0.0.0.0/0
ACL localhost 127.0.0.1/32
ACL lan 10.1.0.0/16
ACCEPT localhost
ACCEPT lan
REJECT all


upsmon.conf
MONITOR  ippon@localhost 1 monitor ippon master


Собственно остается только запустить сервисы, как описано в altlinux.org/nut

Источник: Хабрахабр

Категория: Системное администрирование, Linux, Сетевые технологии

Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

Добавление комментария

Имя:*
E-Mail:
Комментарий:
Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
Введите два слова, показанных на изображении: *