Базовая конфигурация D-Link DGS-3620 ( Базовая конфигурация управляемого стекируемого, с поддержкой функциональности Layer3, коммутатора D-Link DGS-3620. )
Задача: базовая настройка управляемого коммутатора, с использованием "интерфейса командной строки" (CLI). Под "базовой" я понимаю настройку минимально необходимого функционала с попутным явным отключением всего не задействованного и могущего внести смущение в умах.
На свежеиспечённый коммутатор можно зайти как минимум тремя способами:
Мне ближе последний вариант, подключение к "консольному" порту - он работает вне зависимости от текущей сетевой конфигурации устройства.
Рекомендованные производителем параметры подключения к "консольному" порту следующие:
Запускаем программу "терминального" клиента:
DGS-3620-28TC Gigabit Ethernet Switch Command Line Interface
Firmware: Build 1.00.040 Copyright(C) 2011 D-Link Corporation. All rights reserved.
Просто нажимаем пару раз "Enter", проходя этапы ввода логина и пароля, и вот, мы можем просмотреть текущую конфигурацию устройства:
Приступим к конфигурированию как таковому.
На всякий случай явно отключаем автоматическую настройку с помощью DHCP и получение конфигурации с TFPD-сервера:
Назначим свой IP-адрес:
Отключим ненужный нам пока функционал поддержки протокола IPv6:
Удостоверимся в том, что изменения приняты:
IP Interface : SystemVLAN Name : defaultInterface Admin State : EnabledDHCPv6 Client State : DisabledIPv4 Address : 192.168.1.2/24 (Manual) PrimaryProxy ARP : Disabled (Local : Disabled)IP Directed Broadcast : DisabledIPv4 State : EnabledIPv6 State : DisabledIP MTU : 1500
IP Interface : mgmt_ipifStatus : EnabledIP Address : 192.168.0.1Subnet Mask : 255.255.255.0Gateway : 0.0.0.0Link Status : Link Down
Total Entries: 2
Обратите внимание на то, что "shell" устройства регистро-чувствительный, в частности, имя интерфейса "System" так и вводится, с большой буквы, в то время как другие операнды и операторы - с маленькой.
Задаём маршрут по умолчанию, необходимый для обеспечения доступности управляющего функционала коммутатора:
Удостоверимся, что маршрут верно задан:
Проверим, достижим ли с коммутатора какой-нибудь удалённый ресурс:
И так, теперь, когда железка доступна для подключения не только локального, но и удалённого, вынесем работу из гудящей и холодной серверной в кресло администратора, приняв меры, в то-же время, к обеспечению безопасности соединения. А точнее: дополним сетевую конфигурацию, заведём на коммутаторе административный аккаунт, инициируем SSH-сервер и предпишем работать через него.
Отключаем расширенную систему авторизации на устройстве, оставляя локальную базу:
Задаём пароль для повышения уровня привилегий, перехода "enable":
Создаём парочку административных аккаунтов:
# create account admin superadmin# create account admin trivialadmin
Enter a case-sensitive new password:********Enter the new password again for confirmation:********Success.
Когда придёт в голову сменить пароль, делаем это так:
Удостоверимся, что аккаунты созданы в том виде, как нам было угодно:
Велим коммутатору шифровать сохранённые в энергонезависимой памяти пароли:
Включаем поддержку доступа к устройству по протоколу SSH:
Отключаем поддержку небезопасного протокола доступа к устройству Telnet:
Явно указываем, каким образом мы будем проходить проверку подлинности:
Задаём параметры подключения клиента SSH к серверу:
Вводим заранее созданных пользователей в список допущенных для работы с SSH:
Отдельно явно разрешаем использование протокола шифрования трафика SSH:
Сохраняем всё, и настройки и журнал событий, в энергонезависимую память:
Теперь идём на своё рабочее место и подключаемся к устройству используя для этого протокол SSH.
Первым делом стоит подкорректировать настройки портов. Такие "железки", как стекируемые гигибитные коммутаторы обычно не на тривиальный клиентский доступ берутся. Например, у нас они применяются на связке пула серверов виртуализации и пачки серверов распределённой сетевой файловой системы оптической магистралью в 20Gbps. Подключаемое оборудование оснащено сетевыми интерфейсами поддерживающими всё и даже гораздо более того, на что способны эти коммутаторы; потому конфигурация портов фиксировано задаётся пиковой. Например таким образом:
# config ports 1-24 medium_type copper speed 1000_full slave flow_control enable state enable
# config ports 25-28 medium_type fiber speed auto state enable
Здесь мы предписали портам навязывать свою конфигурацию клиенту, задав скоростные характеристики в 1Gbps с полным дуплексом, предлагая аппаратный контроль потока передаваемых данных и выделили четыре "оптических" SFP-порта для связи с другими коммутаторами.
Очень желательно явно выставлять параметры интерфейсов, предназначенных для связи между коммутаторами и маршрутизаторами. На моей практике неоднократно наблюдались огромные, до 30%-40% потери пакетов из-за того, что оборудование не могло договорится о режимах работы в автоматической конфигурации.
Следует иметь в виду, что у D-Link при конфигурировании "гигабитных" "медных" портов нужно явно указывать, какая сторона ведущая, а какая ведомая. В частности, если этот коммутатор "ведущий" (master), что на втором "гигабитные" порты должны быть инициированы как "ведомые" (slave), например:
Устройство мощное, энергии потребляет немало и разработчики добавили ему функционал энергосбережения. Явно задаём режимы энергосбережения коммутатора, позволяя ему отключать питание неиспользуемых портов (раз в секунду проверяя их активность) и деактивируем функцию корректировки мощности сигнала на порту в зависимости от длинны кабеля до партнёра (опасаюсь потенциальных проблем с калибровкой):
Далее следует чуть подкорректировать общие настройки, имеющие отношение к обеспечению условий коммутации.
Иногда бывает полезно огорчить любителей повесить на порт нашего коммутатора свой коммутатор и нацеплять за ним кучу незарегистрированного оборудования. Можно явно указать не принимать запросы на порту более чем с одного MAC:
В нашем случае такие ограничения не имеют смысла, так что будет полезнее явно их отключить:
Для отлова "петель" в сети коммутации используем специализированный функционал коммутатора, регулярно посылающий тестовый пакет обнаружения "loopback" (это работает независимо от протокола STP):
В качестве дополнительной меры обеспечения доступности сервисов, представляемых коммутатором, включим поддержку "Safeguard engine", режима, в котором отбрасываются или отправляются в конец очереди (с пониженным приоритетом) все ARP и "широковещательные" пакеты тогда, когда загрузка процессора возрастёт выше установленного порога:
Считаю полезным воспользоваться функциональностью отслеживания и обхода состояния HOL (Head-of-line blocking), блокировки FIFO буфера исходящей очереди интерфейса пакетами входящей очереди "медленного" или просто сбоящего интерфейса при том, что в ту же исходящую очередь направляются пакеты входящей очереди гораздо более "быстрого" интерфейса. Активируем механизм, справляющийся с проблемами HOL:
Далее - общесистемные мелочи.
Велим коммутатору отправлять на удалённый сервер данные своего журнала событий:
Научим наш коммутатор выспрашивать точное время у соответствующих серверов.
Задаём "часовой пояс":
Отключим перевод на "летнее время":
Укажем наши сервера точного времени:
Отключим поддержку протокола PTP (Precision Time Protocol), протокола сверхточной синхронизации времени для промышленных сетей:
Далее отключим то, что не подпадает под понятие базовой настройки.
Отключаем перенаправление DHCP запросов на целевой сервер и функционал встроенного DHCP-сервера как такового:
Отключаем подсистему разрешения доменных имён DNS, как невостребованную на уровне коммутации:
Отключаем систему уведомления SNMP сервера о изменении MAC клиента на портах:
Отключим поддержку рассылки "самопроизвольного ARP" (Gratuitous ARP) (применяется для определения конфликтов IP-адресов в сегменте сети: как только интерфейс инициирует адрес, рассылается ARP-ответ без запроса):
Отключим функционал IMPB (IP-MAC-Port Binding), позволяющий контролировать доступ в сеть на основе связки IP, MAC и порта подключения:
Явно отключим поддержку контроля трафика на основе MAC-адресов (MAC-based ACL):
Отключаем поддержку протокола STP и вспомогательного протокола PDU (Bridge Protocol Data Unit) управления сетевыми мостами:
Отключаем поддержку протокола ERPS (Ethernet Ring Protection Switching), использующегося для исключения образования колец в топологии (может применяться как замена семейству протоколов STP):
Отключаем протокол оповещения и сбора информации о соседнем оборудовании LLDP (Link Layer Discovery Protocol) (свободная замена таким протоколам, как: Cisco Discovery Protocol, Extreme Discovery Protocol, Foundry Discovery Protocol или Nortel Discovery Protocol). Вещь полезная, но не особо нужная до понимания целесообразности применения:
Отключаем богатый и полезный, но не нужным нам пока, функционал CFM (Connectivity Fault Management, 802.1ag) предоставляющий возможности наблюдения, поиска и устранения неисправностей в сетях Ethernet, позволяя контролировать соединение, изолировать проблемные участки сети и идентифицировать клиентов, к которым применялись ограничения в сети:
Отключаем функционал единого адреса для стека коммутаторов:
Отключаем функционал объединения нескольких коммутаторов в "стек" (Stacking):
Отключаем авторизацию клиентов на портах:
Отключаем инкапсуляцию тегов VLAN в теги VLAN второго уровня:
Если к коммутатору не подключены VoIP-телефоны Cisco со встроенным мини-свичём, изолирующим VoIP-трафик путём тегирования с помощью 802.1q, то отключим функционал распознавания вторичного VoiceVLAN на портах:
Явно отключаем управление "мульткастом", если он не используется:
Отключаем поддержку "независимого от протокола мультикаста" PIM (Protocol Independent Multicast) (называется протоколо-независимым, потому что базируется на традиционных маршрутных протоколах, вроде BGP, вместо того, чтобы создавать собственную сетевую топологию):
Отключаем поддержку ещё одного специфичного протокола "мультикаста" DVMRP (Distance Vector Multicast Routing Protocol - протокол дистанционно-векторной многоадресной маршрутизации):
Раз уж мы занялись искоренением ненужной нам функциональности маршрутизации - погасим поддержку динамической маршрутизации и для "Layer 3".
Отключим поддержку BGP (Border Gateway Protocol):
Отключим поддержку OSPF (Open Shortest Path First):
Отключим поддержку RIP (Routing Information Protocol):
Отключаем поддержку протокола ECMP (Equal-Cost Multi-Path). ECMP работает совместно с протоколами маршрутизации, такими как RIP и OSPF, и позволяет установить несколько равноценных маршрутов для передачи данных:
Отключаем поддержку VRRP (Virtual Router Redundancy Protocol) - сетевого протокола, предназначенного для увеличения доступности маршрутизаторов выполняющих роль шлюза по умолчанию путём объединения группы маршрутизаторов в один виртуальный маршрутизатор:
Если коммутатор только коммутирует, а не занимается туннелированием, то отключаем поддержку L2PT (Layer 2 Protocol Tunneling). L2PT позволяет передавать инкапсулированные блоки данных протокола (PDU) "Layer 2", таких, как STP (Spanning Tree Protocol), CDP (Cisco Discovery Protocol), VTP (VLAN Trunking Protocol), PAgP (Port Aggregation Protocol), LACP или UDLD (UniDirectional Link Detection):
Отключаем зеркалирование портов (применяется для мониторинга и сбора статистики). Различают две технологии SPAN (Switch Port Analyzer в терминологии Cisco). SPAN работает в пределах одного коммутатора, а RSPAN (Remote Switch Port Analyzer) может зеркалировать и передавать трафик между коммутаторами. Если я верно понял, D-Link называет SPAN как "mirror";
Отключаем поддержку sFlow (стандарт для мониторинга компьютерных сетей). Насколько я понял, sFlow является открытым отраслевым стандартом и продвигается в качестве замены "цисковского" NetFlow:
Явно отключаем поддержку "Jumbo Frame", "сверхдлинных Ethernet-кадров", до понимания сферы применения:
Напоследок рекомендую отключить "web"-интерфейс и связанные с ним подсистемы контроля доступа WAC (Web-based Access Control):
CLI предоставляет достаточно инструментария для контроля и мониторинга устройства, например:
Поблагодарить автора ( сделайте свой денежный вклад в хорошее настроение )