Система Orphus
Показаны сообщения с ярлыком сеть. Показать все сообщения
Показаны сообщения с ярлыком сеть. Показать все сообщения
[]

четверг, 19 февраля 2009 г.

port-check - чекаем порты без проблем или скрипт для проверки доступности портов


Нам, админам, довольно часто, точнее постоянно, приходится мониторить различные ресурсы своей сети и не редко удаленной. Если нет возможности поставить на хост средства мониторинга, то приходится проверить по портам. Раньше я это делал так:
netcat -w3 -z host port && echo OK
А что если нужно проверять несколько хостов и/или портов? Вот для этих целей и был написан скрипт.


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

Ниже приведена справка по использованию скрипта port-check.
$ port-check --help

Скрипт port-check проверяет на доступность указанные порты на указанных хостах.
Возвращает количество закрытых портов.

Использование:
port-check [-q|-v] host port
port-check [-q|-v] host "port1 .. portN"
port-check [-q|-v] "host1 .. hostN" port
port-check [-q|-v] "host1 .. hostN" "port1 .. portN"



-q, --quiet
Ничего не выводить

-v, --verbose
Выводить т.ж. открытые порты, иначе только закрытые и не доступные хосты

-V, --version
Показать версию

-h, --help
Показать эту справку
Все проще некуда =)

А вот несколько примеров работы скрипта:
$ port-check -v "mail.ru google.com 10.0.0.1 192.168.0.1" "80 443 ssh 21"
mail.ru:80 open
mail.ru:443 CLOSE!!!
mail.ru:ssh CLOSE!!!
mail.ru:21 CLOSE!!!
google.com:80 open
google.com:443 open
google.com:ssh CLOSE!!!
google.com:21 CLOSE!!!
Host 10.0.0.1 unreachable!!!
192.168.0.1:80 open
192.168.0.1:443 CLOSE!!!
192.168.0.1:ssh CLOSE!!!
192.168.0.1:21 open


$ port-check -v "mail.ru google.com 10.0.0.1 192.168.0.1" 80
mail.ru:80 open
google.com:80 open
Host 10.0.0.1 unreachable!!!
192.168.0.1:80 open


$ port-check -v mail.ru "80 443 ssh 21"
mail.ru:80 open
mail.ru:443 CLOSE!!!
mail.ru:ssh CLOSE!!!
mail.ru:21 CLOSE!!!


$ port-check -v 10.0.0.1 "80 443 ssh 21"
Host 10.0.0.1 unreachable!!!


$ port-check -q 10.0.0.1 "80 443 ssh 21"


$ port-check "mail.ru google.com 10.0.0.1 192.168.0.1" "80 443 ssh 21"
mail.ru:443 CLOSE!!!
mail.ru:ssh CLOSE!!!
mail.ru:21 CLOSE!!!
google.com:ssh CLOSE!!!
google.com:21 CLOSE!!!
Host 10.0.0.1 unreachable!!!
192.168.0.1:443 CLOSE!!!
192.168.0.1:ssh CLOSE!!!
Вот и все. Надеюсь все понятно и наглядно.

Скачать port-check можно по этой ссылке. Пользуйтесь на здоровье.

Почти каждая строка в скрипте прокомментирована. Уверен, что даже новичок сможет разобраться, как работает скрипт.
Скрипт писал довольно долго, много тестировал, поэтому версия сразу 1.0 и, скорее всего, финальная. Даже не представляю, что еще в него можно добавить...


Критика/комментарии/мнения/etc с радостью принимаются :)))


[]

вторник, 11 ноября 2008 г.

Выводим VirtualBox в локальную сеть

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


Я использовал VirtualBox OSE 1.5.6 из репозитория на Ubuntu 8.04.1 Desktop.

Для начала запусти сам VirtualBox, выбери из списка нужную тебе виртуальную машину и открой ее свойства. В левой части окна свойств выбери пункт "Сеть". В правой части выбирает "Хост-интерфейс" в поле "Присоединен к". А ниже в поле "Имя интерфейса" пишем "vbox0" (естественно, без кавычек ;) ). В общем как на скриншоте ниже.




Далее ставим пакет bridge-utils:
sudo apt-get install bridge-utils


И добавляем в /etc/network/interfaces:
auto eth0
iface eth0 inet manual

auto br0
iface br0 inet dhcp
bridge_ports eth0 vbox0


Теперь редактируем /etc/vbox/interfaces:
vbox0 ИмяЮзера br0
тут ИмяЮзера - пользователь, под которым ты работаешь в системе.

Т.ж. нужно настроить права для /dev/net/tun, чтобы VirtualBox не ругался при запуске гостевой ОС:
sudo chown root:vboxusers /dev/net/tun
sudo chmod g+rw /dev/net/tun


Чтобы не выполнять это каждый раз при запуске Ubuntu открываем файл /etc/udev/rules.d/20-names.rules и ищем строчку (у меня она была в самом низу файла)
KERNEL=="tun", NAME="net/%k"
и дописываем в ее конец
, GROUP="vboxusers", MODE="0660"
т.е. должна получиться такая строчка
KERNEL=="tun", NAME="net/%k", GROUP="vboxusers", MODE="0660"


Теперь настало время перезапустить сеть и демон виртуалбокса:
sudo /etc/init.d/networking restart
sudo /etc/init.d/virtualbox-ose restart

Все готово. Осталось только запустить гостевую систему в VirtualBox'е и убедиться, что все работает. :)

Т.к. IP мы получаем динамически, то надо в гостевой системе сделать соответствующие сетевые настройки, чтобы она получала IP от DHCP сервера из нашей локальной сети.
Если же ты не хочешь или не можешь по какой-то причине использовать DHCP сервер, то измени файл /etc/network/interfaces след. образом:
auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
address 192.168.0.100
netmask 255.255.255.0
gateway 192.168.0.1
bridge_ports eth0 vbox0

Теперь твоя гостевая система будет иметь IP 192.168.0.100. Т.ж. не забудь соответствующим образом изменить сетевые настройки гостевой системы.


И... никогда не забывай делать резервные копии, перед внесением изменений в какие-либо конфигурационные файлы!!! ;)


ЗЫ: Можешь на свой страх и риск заюзать нижеприведенный скрипт. Но тебе все равно придется вручную изменить настройки в свойствах виртуальной машины (как это описывалось выше).
Скрипт нужно запускать от root'a. Если ты изменишь значение переменной $ISDHCP на 1, то тебе нужно будет изменить значение следующих трех переменных на свой вкус, хотя можешь и ничего не менять, а оставить как есть.
Еще раз предупрежу: используй этот скрипт исключительно на свой страх и риск, я не несу никакой ответственности если ты запустишь этот скрипт на своей системе.


#!/bin/sh

# Запускать от root'а

ISDHCP=0 # 1 = Использовать DHCP | 0 = Не оспользовать DHCP

ADDRESS=192.168.0.100
NETMASK=255.255.255.0
GATEWAY=192.168.0.1

USER=`whoami`


# Устанавливаем пакет bridge-utils
apt-get install bridge-utils

NODHCP="auto eth0"
NODHCP+="iface eth0 inet manual"
NODHCP+=""
NODHCP+="auto br0"
NODHCP+="iface br0 inet dhcp"
NODHCP+=" bridge_ports eth0 vbox0"

YESDHCP="auto eth0"
YESDHCP+="iface eth0 inet manual"
YESDHCP+=""
YESDHCP+="auto br0"
YESDHCP+="iface br0 inet static"
YESDHCP+=" address $ADDRESS"
YESDHCP+=" netmask $NETMASK"
YESDHCP+=" gateway $GATEWAY"
YESDHCP+=" bridge_ports eth0 vbox0"

# Делаем бэкап /etc/network/interfaces
cp /etc/network/interfaces /etc/network/interfaces_`date +%Y%m%d`

# Настраиваем /etc/network/interfaces
if [ $ISDHCP=0 ] ; then
echo "$NODHCP" > /etc/network/interfaces
else
echo "$YESDHCP" > /etc/network/interfaces
fi

# Настраиваем /etc/vbox/interfaces
echo "vbox0 $USER br0" >> /etc/vbox/interfaces

# Настраиваем права для /dev/net/tun
chown root:vboxusers /dev/net/tun
chmod g+rw /dev/net/tun

# Делаем бэкап /etc/udev/rules.d/20-names.rules
cp /etc/udev/rules.d/20-names.rules /etc/udev/rules.d/20-names.rules_`date +%Y%m%d`

# Заменяем нужную строчку
grep -v 'KERNEL=="tun"' /etc/udev/rules.d/20-names.rules > /etc/udev/rules.d/20-names.rules
echo 'KERNEL=="tun", NAME="net/%k", GROUP="vboxusers", MODE="0660"' >> /etc/udev/rules.d/20-names.rules

# Перезапускаем демон виртуалбокса
sudo /etc/init.d/virtualbox-ose restart

# Перезапускаем сеть
sudo /etc/init.d/networking restart


четверг, 28 августа 2008 г.

Регуляторы трафика


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




Конкуренция трафика: возможен ли компромисс?

В настоящее время все больше решений в области коммуникаций самого разного масштаба используют IP-протокол и локальные сети Ethernet. При этом есть возможность минимизировать затраты благодаря использованию уже имеющегося оборудования, существующим программным решениям и даже приобретенным знаниям и опыту местных специалистов. Упрощает работу включение в общий проект уже имеющихся коммуникаций. IP-трафик, обеспечивающий работу программ, будет передаваться по каналам LAN и шлюзам, соединяющим сетевые сегменты. В качестве примера можно привести вариант организации информационного сообщения между разнесенными офисами путем реализации VPN.

Одна из проблем IP-сетей – это эффективный контроль трафика. Методы решения этой проблемы основываются на применении политики, позволяющей гармонично распределить информационный поток. Ведущие разработчики сетевого оборудования пытаются воплотить идею использования политики контроля трафика в технические решения. Как правило, реализуются методы QoS (Quality of Service) и CoS (Class of Service), которые, впрочем, связаны между собой.

Но в каких же случаях проблема управления трафиком является действительно критичной? И может ли достаточно широкий канал, соединяющий сети, решить все вопросы?

Необходимо учитывать, что протокол IP, созданный для передачи данных в интернете, не гарантирует доставку данных. Этот же протокол, работая в локальной сети Ethernet, не приобрел дополнительного качества, также полагаясь на принцип best effort service (негарантированная доставка данных). Если сеть компании используется только для обмена данными, то, наверное, заметного постоянного наростания трафика в ней не наблюдается, а возможные задержки при работе в сети или незаметны пользователям, или малозначимы. Даже в случае добавления новых пользователей в группу необходимо только пропорционально увеличить пропускную способность каналов, чтобы обеспечить необходимое качество сетевых сервисов.

Совершенно другая ситуация складывается при использовании приложений, для работы которых критичны задержки и скорость потока данных. Расширение пропускного канала сети сделает скорость обмена данными только более высокой, но не предотвратит внезапного увеличения до критического значения потока пакетов. При этом может наблюдаться переполнение буфера роутера или коммутатора. В такой ситуации происходит разрушение части сетевых пакетов. Также есть возможность потери пакетов второстепенных программ, а не приложений межсетевого обмена, например e-mail. Чтобы обеспечить эффективную работу всех приложений, следует изменить логику функционирования сети. Необходимо отказаться от негарантированной доставки данных, не дающей никаких привилегий программам. В тех случаях, когда объем трафика или задержки в локальной сети могут возрастать в пределах 10–30%, разумно будет задействовать QoS/CoS-политику как способ контроля трафика. Если организация планирует использовать видеоконференцию или систему групповой работы, в локальной сети обязательно нужно закрепить необходимый ресурс за определенными приложениями. Кстати, разработчики предлагают несколько схем, позволяющих эффективно применить схему QoS/CoS в локальной сети.

Проще всего использовать схему приоритезации сетевого трафика. IEEE и Internet Engineering Task Force поддерживают восемь одинаковых уровней приоритета IEEE в спецификации 802.1p(802.1d), а IETF использует специальные биты в IP-заголовке. Компания 3COM одной из первых реализовала поддержку данной спецификации в своих коммутаторах и роутерах под фирменным названием 3Com Transcend Policy Manager. Важно, что ведущие производители сетевого оборудования, в частности 3COM и Cisco, сотрудничали с разработчиками основных ОС для достижения совместимости обработки битов приоритета в заголовках IP-пакета.

Политика приоритетов создает что-то наподобие дорожных развязок. Она, например, может определить, что пакеты, относящиеся к приложениям CRM, имеют превосходство по доставке перед пакетами других типов – обмена файлов или интернет-пейджеров. Если же возникнет ситуация, когда часть пакетов в результате перегрузки будет отброшена, то в первую очередь это случится с пакетами с низким приоритетом. Надо сказать, что наряду с обеспечением достаточной полосы пропускания схема приоритетов позволяет осуществить доставку необходимого трафика в пункт назначения.

В рабочих группах, где необходимо обеспечить определенный уровень задержек сетевых передач, оптимальным будет использование схемы QoS, реализованной в стандарте ATM и RSVP (Resource Reservation Protocol). Данная схема позволяет получить контроль над пропускной способностью, задержками и точностью соблюдения приоритетов (над тем, какие пакеты будут отброшены в ситуации переполнения очереди).

Так, RSVP способен гарантировать то, что задержка сетевой передачи не превысит определенного максимума, а ATM к тому же предлагает контроль за дрожанием – колебанием задержек и временем движения пакетов от одной критичной точки LAN до другой.

Даже если компания не нуждается в системе управления трафиком сегодня, вполне возможно, что такая необходимость возникнет в будущем. Необходимо обращать внимание на то, чтобы приобретаемое сетевое оборудование, например коммутаторы, устанавливаемые на границе сети, поддерживали второй уровень и могли использовать схему приоритезации по стандарту 802.1p(802.1d).

Механизм дифференцированных услуг

С целью формализации описанных проблем и решений в 1998 году IETF создала рабочую группу по созданию дифференцированных услуг (DiffServ). Основная задача дифференцированных услуг – совместить требования по качеству обслуживания данных с принципом негарантированной доставки пакетов. В этой модели происходит разделение трафика путем его разбивки на классы с различным приоритетом.

Принцип приоритезации трафика прост: преимущества в сети отдаются более важным данным. При этом возникает несколько вопросов: какой трафик может быть дифференцирован? Кто и как наделяет данные приоритетом?

Приоритезация, называемая также CoS, разделяет трафик по нескольким категориям: высокая, средняя и низкая, а также самая низкая, пакеты которой могут быть отброшены. E-mail и вэб-трафик зачастую относят к самой низкой категории, и в случае полной загрузки сети они будут отброшены в первую очередь.

Сервисы, ориентированные на доставку пакетов, работают по аналогии с CoS, то есть можно отметить те пакеты, которые нужно доставить в первую очередь, во вторую и т.д. Такая схожесть не случайна, ведь CoS можно рассматривать как подкласс QoS. Но в отличие от нее, приоритезация трафика не гарантирует того, что данные будут доставлены в определенное время.

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

Сегодня только ATM имеет все механизмы поддержки QoS. Для локальных сетей существует RSVP. Он является IETF-стратегией поддержки QoS в сетях TCP/IP и есть нечто большее, чем приоритезация и CoS. RSVP предусматривает распределение полосы пропускания и ее резервирование под определенный вид трафика. Это достаточно сложный для реализации протокол. Существует и другой механизм реализации QoS в IP – MPLS (Multiprotocol Label Switching).

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

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

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

Приоритезация может быть задействована также в мультипротокольных маршрутизаторах и коммутаторах, когда классификация будет проводиться по типу протокола. Например, данные, относящиеся к SNMP-протоколу, будут отнесены к классу с наивысшим приоритетом. Существуют и другие схемы маркировки CoS:

  • приоритезация на основе MAC-адреса;
  • VLAN-метки и 802.1p. IEEE 802.1Q – стандарт, который описывает способ, позволяющий вставлять метку в IEEE MAC-кадр. Эта метка служит для определения принадлежности к той или иной VLAN. Три бита такой метки могут нумеровать восемь определенных уровней приоритета. Подобное сочетание битов будет воспринято сетевыми устройствами как предписание отнести пакет к какому-либо классу обслуживания;
  • TOS. Заголовок IP-пакета имеет поле, которое называется TOS (Type Of Service). Это поле в настоящее время переопределено для использования в контексте IETF-дифференцирования услуг (Differentiated Services – Diff-Serv). Diff-Serv классифицирует и маркирует пакеты таким образом, что за ними закрепляется определенный маршрут в цепочке сетевых устройств. Установка бита TOS происходит на основе определенной политики контроля и в дальнейшем будет считываться сетевыми устройствами. Разработанный для интернета протокол IP воспринимается в различных сетях, а значит, Diff-Serv может обеспечить CoS в LAN, extranet или intranet.

Сегодня делаются попытки стандартизировать описание классов обслуживания и постепенно избавиться от использования поля TOS в пользу DSCP (Diff-Serve Code Point). Фактически поле DSCP представляет собой расширение поля IP-приоритета за счет использования битов, определяющих типы обслуживания. Схематически трансляция заголовка выглядит так:

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

Практический пример использования коммутатора 2/3 уровня для регулирования трафика Далее будет показано, как можно рационально организовать обмен сетевым трафиком, задействовав интеллектуальные функции коммутатора 3COM SuperStack 3 Switch 4400. Следует сказать, что рассматриваемое устройство поддерживает стандарт 802.1d (расширяющий 802.1p) и реализует как приоритезацию трафика, так и схему QoS. В основе механизма управления TCP/IP-пакетами 3COM SuperStack 3 Switch 4400 лежит использование нескольких очередей, обрабатываемых с различными привилегиями.


Коммутатор 3COM SuperStack 3 Switch 4400,
помимо реализации схем CoS/QoS,
предлагает различные дополнительные функции

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

Но, пожалуй, самым показательным остается использование командной строки – аскетичный интерфейс позволяет сконцентрироваться на принципах управления устройством. Получить доступ к встроенной командной оболочке коммутатора можно различными способами:

  • непосредственно соединившись по последовательному кабелю и используя терминальные программы (minicom, TerraTerm);
  • используя сетевую сессию telnet;
  • используя сетевую сессию SSH (3COM в качестве клиентов рекомендует OpenSSH или PuTTY).

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

Рисунок ниже демонстрирует, как командами оболочки создается определенный классификатор. Представим себе, что необходимо подавить весь ftp-трафик. Можно классифицировать данный сервис по принадлежности к 21 и 20 порту, после чего отнести его к нужному типу обслуживания.

Создается новый классификатор командой cre, после чего предлагается выбрать его номер и название. Теперь предстоит указать механизм, по которому коммутатор будет отбирать нужные нам пакеты.


Создание классификации для ftp-трафика

Как видно из рисунка, есть несколько вариантов выбора. Итак:

  • pAddr обозначает пакеты исходящие и принадлежащие определенному сетевому адресу;
  • ipProtocol может быть TCP или UDP. Некоторые важные сервисы, например разрешение имен, работают по UDP-протоколу;
  • IpPort. С помощью этой опции можно пометить пакеты, относящиеся к тем или иным TCP-сервисам (HTTP-порт 80, SSH-порт 22 и т.д);
  • dscp позволяет анализировать установленную в пакете метку Diff-Serve Code Point.

Как уже говорилось, отличительной чертой ftp-трафика является принадлежность к некоторым портам (20, 21). Это нужно указать опцией ippo, а затем конкретизировать tcp-порт, №21. Подобным образом нужно закрыть и порт данных (20) для ftp-протокола. На рисунке это также представлено. Таким образом, классификация создана. Следующим шагом будет создание правила.


В новый профайл включается классификатор
с соответствующим сервисным уровнем

Собственно правило – это сопоставление классификатора и сервисного уровня (service level). На рисунке ниже изображено, как создается новый профайл с №11 и именем ftp. Затем в него добавляется правило, связывающее классификатор ftp с сервисным уровнем 1 (drop). Можно использовать 1-6 значения сервисных уровней, которые связаны с уровнем приоритета, описанным в стандарте 802.1D (802.1p). Теперь остается только применить данный профайл командой assign ко всем или только к определенному порту коммутатора.

Текущее состояние настроек и правил в устройстве можно проанализировать с помощью команды detail. На рисунке справа проиллюстрирован пример ее работы. В результате мы получили запрет на весь ftp-трафик, который будет циркулировать через любой порт коммутатора.

Кроме простого определения приоритета обработки пакета в очереди на основе сетевых параметров, коммутатор 3COM SuperStack 3 Switch 4400 способен анализировать поле дифференциального обслуживания в IP-заголовке. К сожалению, не все сетевые агенты используют такой механизм приоритезации трафика. Поэтому данный коммутатор наделен способностью транслировать уровни приоритета из стандарта IEEE 802.1p в DSCP и обратно.


Текущее состояние профайла

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

  • значения маркера CoS по стандарту 802.1p;
  • значения DSCP (Diff-Serve code point);
  • порты назначения протоколов TCP и UDP;
  • приоритет по умолчанию для порта (в том смысле, что можно регулировать приоритет всего трафика определенного физического порта коммутатора);
  • IP-адрес и протокол.

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

Таким образом, можно просто зарезервировать полосу пропускания определенному хосту. Для порта в 100 Mбит устанавливать скорость можно с шагом 1 Mбит, а для гигабитного интерфейса шаг увеличивается до 8 Mбит.

Как уже упоминалось, вся конфигурация правил управления трафиком в устройстве 3COM SuperStack 3 Switch 4400 сохраняется в профайле. Данное устройство может взаимодействовать с TFTP-сервером для сохранения, загрузки и выгрузки этого профайла. Такая возможность является очень полезной, если нужно организовать периодическую смену конфигураций, например для рабочего и внеурочного времени суток.

Графические средства управления

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

Например, на рисунках слева видно, как можно произвести необходимые действия для ограничения трафика. Для этого достаточно запустить программу, найти нужный хост и добавить (можно выбрать из стандартных) классификатор трафика.


Получить наглядную статистику работы сетевого устройства
можно из любой точки сети

А вот ознакомиться с текущей статистикой работы коммутатора можно практически из любого места сети, ведь в 3COM SuperStack 3 Switch 4400 встроен вэб-интерфейс. Результат демонстрирует верхний рисунок.

На основе простоты и надежности

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

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



Источник: http://citforum.ru/nets/lvs/traffic/
Первоисточник: Николай Ткаченко, 2004, СЕТИ и Телекоммуникации