вторник, 2 октября 2012 г.

Опыт использования коммутаторов D-LINK на доступе

 

DES-3200-10 18 26 28 28F 28P 52 52P_C1_Image L(Front)

 

ПРЕДЫСТОРИЯ

Деятельность компании, в которой я работаю, в качестве оператора связи началась в далёком уже 2003 году с развёртывания сети передачи данных на основе технологии DOCSIS на существующей сети кабельного телевидения. Уже через пару лет стало ясно, что перспективы у данной технологии не столь радужны, как казалось с начала. Конечно же она позволила запустить сеть в минимальные сроки и с относительно невысокими затратами, но построенная сеть была сложна в эксплуатации и не могла обеспечивать соответствие всё возрастающим потребностям абонентов ввиду ограничений самой технологии: асимметричный канал, ограничение полосы прямого канала в 45 Мегабит при постоянно растущем числе абонентов, что требовало покупки новых головных станций и всё возрастающем использовании частотного ресурса.

Совершенно ясно было, что дальнейшее развитие сети должно пойти по пути параллельного строительства СПД на основе технологии Ethernet с использованием волоконной оптики. Встал вопрос какое оборудование использовать на доступе. Далее я расскажу какое именно оборудование и почему мы выбрали и какую схему доступа клиентов мы использовали.

ПОИСКИ ИДЕАЛЬНОГО КОММУТАТОРА

Понятно, что на доступе необходимо использовать только управляемое оборудование, но при его выборе мы исходили прежде всего из его стоимости. Для молодой телекоммуникационной компании использовать на доступе что-то вроде Cisco Catalyst или HP ProCurve — непозволительная роскошь. Среди вендоров мы рассматривали Alied Telesis, NetGear, 3Com, ZyXEL и D-Link. Необходимо было сформулировать требования к «идеальному коммутатору» и затем, протестировав по возможности образцы-кандидаты, выбрать из них самый подходящий.

Ещё со времён развёртывания сети DOCSIS мы выбрали схему доступа для клиентов посредством VPN соединения поверх «транспортной» сети с «серыми» IP адресами. Пойти на это нас заставили дефицит «белых» IP адресов и то, что мы использовали не изначально «правильную» схему «один модем — один клиент», а пошли по пути наименьшего сопротивления и реализовали схему «коллективного модема». При такой схеме обеспечить безопасность можно было только используя VPN, ведь конкретную пару IP+MAC за модемом может использовать любой из клиентов. Кроме этого мы не хотели безвозмездно предоставлять клиентам ресурсы транспортной сети, а многие к тому времени уже успели ощутить все плюсы «халявной локалки». Так мы сформировали перечень требований к коммутатору доступа:

• приемлемая цена: не выше 500 рублей на порт;

• возможность привязки IP и MAC адреса клиента к порту коммутатора;

• возможность фильтрации трафика на уровне L2 для обеспечения безопасности функционирования сети;

• предоставление безусловного доступа всем клиентам доступа к внутренней инфраструктуре;

• запрет доступа к ресурсам СПД клиентам с тарифами, не предусматривающими таковой;

• управление по telnet и snmp с удобным мониторингом различных параметров.

Изучение сайтов производителей и прайсов поставщиков несколько разочаровало. У большинства вендоров модельный ряд не блистал разнообразием, у части отсутствовала документация, позволяющая оценить функционал коммутаторов без предварительного заказа образца. На общем фоне выгодно выделялся сайт D-Link несколько похуже выглядел Planet. В итоге решено было заказать для тестирования коммутатор производства D-Link DES-3526. Стоимость данной модели у разных реcселеров, на тот момент, колебалась от 8 до 11 тысяч рублей, что вполне нас устраивало. Оставалось лишь разобраться в его функционале на тестовом стенде, определиться с реализацией нашей схемы работы в сети и, в случае положительного результата, разработать процедуры начального конфигурирования и удалённого управления работой коммутатора.

ТЕСТИРОВАНИИЕ ФУНКЦИОНАЛА И ОБКАТКА СХЕМЫ РАБОТЫ

Получив образец для тестирования, мы приступили к изучению мануалов и реализации требуемого алгоритма работы коммутатора. Итак, что нам необходимо:

• комбопорты (25 и 26) решено использовать для «магистрали». 26 — аплинк, 25 — даунлинк (при необходимости) или резервный порт;

• пары IP+MAC клиента или клиентов (ввиду экономии и упрощения перевода клиентов с DOCSIS на Ethernet предполагалось первоначально использовать схему «коллективного порта») привязываются к конкретному порту коммутатора;

• ограничиваем трафик от DHCP-сервера магистральным портом, защищаясь таким образом от «диких» DHCP серверов в сегменте;

• прикрываем весь трафик на локальные адреса транспортной сети (172.16.0.0/12), оставляя открытым доступ к биллингу, серверам VPN и внутренним сайтам в «белой сети»;

• клиентам с тарифами, предусматривающими доступ к ресурсам локальной сети разрешаем трафик на диапазон 172.16.0.0/12.

Первым делом занялись реализацией привязки пары IP+MAC к порту коммутатора. Перелопатив массу информации и перепробовав различные варианты мы так и не смогли добиться желаемого. Исчерпав все идеи решили обратиться через форум к техническим специалистам D-Link в России. На наш вопрос отреагировали неожиданно быстро, предложив использовать другую версию прошивки. Стоит сказать, что большинство проблем у коммутаторов D-Link решаются сменой ПО и это первое, что рекомендуют инженеры D-Link. Так что совет всем, кто выбирает продукцию D-Link: не стесняйтесь обращаться за помощью в саппорт производителя и пробуйте новые версии прошивок — это себя оправдывает.

В итоге мы реализовали требуемый алгоритм на прошивке 5.01.B52. Для привязки использовали комбинацию из статической записи в таблице форвардинга (FDB) для MAC-адреса клиента и пары акцесс-профилей, один из которых запрещал весь трафик с порта, а второй разрешал передачу пакетов с IP клиента в заголовке на IP адреса нашей «DMZ». При помощи ещё одного профиля мы разрешили передачу пакетов с IP клиента на любой IP адрес. Этот профиль, при добавлении в него записи для конкретного клиента давал возможность использовать ресурсы СПД. Итак, теперь рассмотрим алгоритм работы с коммутатором от его начального конфигурирования перед установкой в сети до процедур, выполняемых в процессе работы с ним.

НАЧАЛЬНАЯ КОНФИГУРАЦИЯ

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

Настройки IP

Задаем IP адрес коммутатора, маршрут по умолчанию:

config ipif System ipaddress 172.20.10.254/23

create iproute default 172.20.10.1

Настройки времени

Задаем временную зону, параметры перехода на летнее время и адрес сервера времени:

config time_zone operator + hour 3 min 0

config dst repeating s_week last s_day sun s_mth 3 s_time 2:0 e_week last e_day sun e_mth 10 e_time 3:0 offset 60

config sntp primary 91.192.32.7 secondary 91.192.32.3 poll-interval 720

enable sntp

Настройки удаленного управления

Создаем аккаунты для удаленного управления:

create account admin superadmin

create account user simpleuser

Меняем порт для telnet (в целях безопасности) и запрещаем веб-интерфейс:

enable telnet 6000

disable web

Задаем адреса станций управления:

create trusted_host 172.20.10.1

Иметь доступ с хоста, находящегося в той же сети, что и коммутатор иногда очень полезно.

create trusted_host 91.192.32.10

Задаём адрес сервера, с которого выполняются процедуры по конфигурированию коммутаторов.

Настройки для syslog сервера:

create syslog host 1 ipaddress 91.192.32.10 severity all facility local5 udp_port 514 state enable

config system_severity trap information

config system_severity log information

enable syslog

Настройки SNMP

Задаем свои коммюнити и открываем доступ к необходимым OID:

delete snmp community public

delete snmp community private

create snmp community myonlyread view CommunityView read_only

create snmp community myreadandwrite view restricted read_write

create snmp view restricted 1.3.6.1.4.1.171.12.1.2.3 view_type included

create snmp host 91.192.32.2 v2c myonlyread

create snmp host 91.192.32.2 v2c myreadandwrite

Настройки безопасности

Включаем PortSecurity на клиентских портах и ограничиваем количество изучаемых MAC-адресов на порту одним:

config port_security ports 1-24 admin_state enable max_learning_addr 1 lock_address_mode DeleteOnReset

Включаем StormControl на клиентских портах:

config traffic control 1-24 broadcast enable action shutdown threshold 1024 time_interval 5 countdown 5

config traffic control 1-24 multicast enable action shutdown threshold 1024

Включаем LoopbackPervention на всех портах кроме аплинка (26):

enable loopdetect

config loopdetect ports 1-25 state enabled

config loopdetect recover_timer 0

Включаем ARP Spoofing Pervention на всех портах кроме аплинка:

config arp_spoofing_prevention add gateway_ip 172.20.10.1 gateway_mac 6C-1E-49-93-1E-C6 ports 1-25

Настройка правил доступа

Создаём профиль для блокировки «диких» DHCP серверов:

create access_profile ip udp src_port_mask 0xFFFF profile_id 5

config access_profile profile_id 5 add access_id auto_assign ip udp src_port 67 port 1-24 deny

config access_profile profile_id 5 add access_id auto_assign ip udp src_port 67 port 26 permit

Разрешаем широковещательный трафик на всех портах:

create access_profile ethernet destination_mac FF-FF-FF-FF-FF-FF profile_id 7

config access_profile profile_id 7 add access_id auto_assign ethernet destination_mac FF-FF-FF-FF-FF-FF port 1-26 permit

Создаём профиль для ограниченного доступа:

create access_profile packet_content_mask offset_0-15 0×0 0xFFFF 0xFFFFFFFF 0×0 offset_16-31 0×0 0×0 0×0 0xFFFF offset_32-47 0xFFFFFFFF 0×0 0×0 0×0 profile_id 10

Создаём профиль для доступа к ресурсам СПД:

create access_profile packet_content_mask offset_0-15 0×0 0xFFFF 0xFFFFFFFF 0×0 offset_16-31 0×0 0×0 0×0 0xFFFF offset_32-47 0xFFFF0000 0×0 0×0 0×0 profile_id 15

И в завершение создаём запрещающий профиль полностью блокирующий весь не разрешённый трафик на клиентских портах:

create access_profile packet_content_mask offset_16-31 0xFFFF0000 0×0 0×0 0×0 profile_id 30

config access_profile profile_id 30 add access_id auto_assign packet_content_mask offset_16-31 0×8000000 0×0 0×0 0×0 port 1-24 deny

Ну и конечно не забываем сохранить конфигурацию во внутренней флеш-памяти:

save

На этом предварительная настройка коммутатора закончена и его можно передать инженерам сети для установки.

РАБОТА С КОММУТАТОРОМ

Коммутатор установлен. И мы начинаем подключать клиентов. Процедура подключения нового клиента включает определение порта, MAC-адреса оконечного устройства, занесение и в базу (IP адрес и «номер клиента» в пределах коммутатора — accessID — можно генерировать автоматом) и изменение конфигурации коммутатора в части касающейся привязки пользователя к порту. Возможны ситуации, когда порт, на который подключен клиент, заранее не известен, и для определения необходимо получить таблицу форвардинга и выяснить на каком порту «засветился» искомый MAC-адрес. Можно получить таблицу по snmp, а можно использовать команду show fdb mac_address , которая выведет искомый MAC-адрес и номер порта, на котором он «светится»:

DES-3526: admin#show fdb mac_address 00-04-61-9B-C2-4D

Command: show fdb mac_address 00-04-61-9B-C2-4D

VID VLAN Name MAC Address Port Type

—- —————- —————— —— —————-

1 default 00-04-61-9B-C2-4D 19 Del_on_Reset

Total Entries : 1

DES-3526:admin#

После того, как мы выяснили порт клиента «закрепляем результат»:

• создаём статическую запись в FDB, запрещаем «обучение» на порту:

create fdb default 00-04-61-9B-C2-4D port 19

config port_security port 19 max_learning_addr 0

config ports 19 learning disable

• взяв из базы IP, accessID и MAC клиента разрешаем ему доступ в сеть выполнив команду

config access_profile profile_id 10 add access_id $accessID packet_content_mask offset_0-15 0×0 0xXXXX 0xXXXXXXXX 0×0 offset_16-31 0×0 0×0 0×0 0xYYYY offset_32-47 0xYYYYZZZZ 0×0 0×0 0×0 port $port permit priority 7

где XXXXXXXXXXXX — MAC клиента в прямой 16-ричной записи, YYYYYYYY — IP клиента в 16-ричной записи (например ac14827a это 172.20.130.122), ZZZZ — первые два октета из сетевого адреса «DMZ» (например 5bc0 это 91.192.)

• если тарифным планом клиенту разрешено использование ресурсов СПД, нужно выполнить ещё одну команду:

config access_profile profile_id 15 add access_id $accessID packet_content_mask offset_0-15 0×0 0xXXXX 0xXXXXXXXX 0×0 offset_16-31 0×0 0×0 0×0 0xYYYY offset_32-47 0xYYYY0000 0×0 0×0 0×0 port $port permit

Если клиент «выбывает» — нужно подчистить за ним, т.к. максимальное число статических записей в FDB ограничено 256, а число вхождений для ACL ограничено 800 (По 200 правил на каждые 8 портов 10/100 и по 100 правил на каждый гигабитный порт). Кроме того, при смене MAC адреса клиентом также необходимо будет удалить статические записи и вхождения ACL для клиента и создать их заново. Для удаления используем команды:

delete fdb default

config access_profile profile_id 10 del access_id $accessID

config access_profile profile_id 15 del access_id $accessID

ОПЫТ ЭКСПЛУАТАЦИИ

Сейчас в нашей сети насчитывается более 250 коммутаторов DES-3526, пять DES-3550 и несколько десятков различных модификаций серии DES-3200 (на 28, 26 или 18 портов). За 5 лет коммутаторы производства D-Link показали себя достаточно надёжным и эффективным решением для предоставления услуг клиентам в качестве коммутаторов доступа. Правда есть некоторые моменты, на которых хочется акцентировать внимание тех, чей выбор будет аналогичен нашему. Итак — «подводные камни»:

1. Модель DES-3550 показала себя неожиданно «хрупкой». За 5 лет эксплуатации из 10 устройств полностью вышли из строя 5. Причем неисправность материнской платы ставит под сомнение целесообразность расходов на ремонт. Признаками неисправности, причиной которой, по всей видимости, послужили некачественные микросхемы стабилизаторов напряжения, являются вспухшие электролитические конденсаторы по всей плате и непрерывное срабатывание защиты блока питания.

2. Практически у всех коммутаторов модели DES-3526 в процессе эксплуатации за пару лет выходит из строя блок питания. Неисправность легко устраняется заменой трёх (два 1500мкФx16v и один 470мкФx16v), по всей видимости тоже некачественных, электролитов. Полностью вышедших из строя коммутаторов всего 2. Блоки питания этих двух в дальнейшем были использованы для «горячей замены» очередного умершего в коммутаторе блока питания. По опыту могу сказать, что проблемой с БП в большей степени обладали 3526 старых hardware-ревизий, в новых (A4G и старше) такой массовости нет. С DES-3200 такого не наблюдается вовсе.

3. Ограничение количества записей ACL на группу портов иногда приводило к их полному исчерпанию, в результате чего приходилось перераспределять клиентов по портам и переконфигурировать коммутатор. но это издержки нашей схемы подключения. И, справедливости ради, стоит отметить, что коммутаторы серии DES-3200 лишены этого недостатка и у них ограничено только суммарное число записей.

4. Очень редко (на моей памяти не более 5 случаев), когда коммутатору, что называется «сносило крышу». Он переставал обслуживать клиентов при полной видимости что всё в порядке. Есть подозрение, что проблему вызывало «кривое» сохранение конфигурации, но окончательно поставить верный диагноз мы так и не смогли поставить. Лечилось описанное поведение полным сбросом на заводские настройки с консоли с последующей конфигурацией с нуля.

5. Когда мы стали испытывать проблемы со своевременной поставкой DES-3526 наш выбор пал на коммутаторы серии DES-3200. Нужный нам функционал присутствовал в них в полном объёме, но обнаружилось что синтаксис профилей в CLI новых коммутаторов несколько изменился, что потребовало корректировки процедур изменения и создания профилей под данную модель и её разновидности (с разным числом портов). Изменения затронули 7, 10, 15 и 30-й профили:

7

create access_profile packet_content_mask destination_mac FF-FF-FF-FF-FF-FF offset1 l2 0 0×0 profile_id 7

config access_profile profile_id 7 add access_id auto_assign packet_content destination_mac FF-FF-FF-FF-FF-FF offset1 0×0 port 1-28 permit

10

create access_profile packet_content_mask source_mac FF-FF-FF-FF-FF-FF offset1 l3 12 0xFFFF offset2 l3 14 0xFFFF offset3 l3 16 0xFFFF profile_id 10

config access_profile profile_id 10 add access_id $accessID packet_content source_mac XX-XX-XX-XX-XX-XX offset1 0xYYYY offset2 0xYYYY offset3 0xZZZZ port $port permit

15

create access_profile packet_content_mask source_mac FF-FF-FF-FF-FF-FF offset1 l3 12 0xFFFF offset2 l3 14 0xFFFF profile_id 15

config access_profile profile_id 15 add access_id $accessID packet_content source_mac XX-XX-XX-XX-XX-XX offset1 0xYYYY offset2 0xYYYY port $port permit

30

create access_profile packet_content_mask offset1 l2 0 0xFFFF profile_id 30

config access_profile profile_id 30 add access_id 1 packet_content offset1 0×0800 port 1-24 deny

В целом опыт эксплуатации коммутаторов D-Link позволяет сказать, что использование их в качестве коммутаторов доступа оправдано. Приемлемая цена, невысокий процент отказов, широкий функционал — всё это можно смело записывать в плюсы продукции D-Link. Кроме того достаточно оперативная техническая поддержка официального представительства и достаточно большое количество русскоязычной документации и справочной информации на официальном российском сайте станут хорошим подспорьем сетевым специалистам, выбравшим продукцию D-Link для построения «последней мили».

ЗАКЛЮЧЕНИЕ

В статье описан один из вариантов использования на доступе коммутаторов D-Link, и это решение не претендует на звание абсолютно правильного. Мы сознательно не использовали появившуюся в последних прошивках функцию dhcp-snooping, хотя это решение более изящно. У коммутаторов широкий функционал и одну и ту же задачу можно решить несколькими способами. Используя ACL, анализирующие тело пакета, можно фильтровать различные типы трафика, решая задачи сетевой безопасности. Для примера взгляните на фильтры, защищающие коммутаторы управляемые по протоколу RRCP от несанкционированного изменения конфигурации и фильтры защищающие от «диких» PPPoE серверов.

Разрешаем PPPoE-session пакеты от клиентов к серверу + пакеты RRCP от свичей:

create access_profile ethernet destination_mac FF-FF-FF-FF-FF-FF ethernet_type profile 6

config access_profile profile_id 6 add access_id auto_assign ethernet destination $MAC_of_PPPoE_server ethernet_type 0×8863 port 1-24 permit

config access_profile profile_id 6 add access_id auto_assign ethernet destination $MAC_of_PPPoE_server ethernet_type 0×8864 port 1-24 permit

+config access_profile profile_id 6 add access_id $RRCP_device_ID ethernet destination $MAC_of_RRCP_management_server ethernet_type 0×8899 port $RRCP_device_port permit

-config access_profile profile_id 6 del access_id $RRCP_device_ID

Запрещаем PPPoE-session пакеты от других источников + пакеты RRCP на всех портах кроме аплинка:

create access_profile ethernet ethernet_type profile 8

config access_profile profile_id 8 add access_id auto_assign ethernet ethernet_type 0×8863 port 1-25 deny

config access_profile profile_id 8 add access_id auto_assign ethernet ethernet_type 0×8899 port 1-25 deny

Конечно конфигурирование таких профилей довольно сложно, по сравнению с коммутаторами, использующими cisco-like CLI, но зато более гибкое и, по заверениям представителей D-Link, данные фильтры не нагружают процессор, т.к. реализованы аппаратно, и лишь изменение вносится через CLI.

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