Там же тогда же. Собственно с чего начал ковырять свичик HP ProCurve: поступили жалобы на то, что криво работают после перезагрузки по броску питания. Вроде как отваливается сетка и что то тупит. В логах довольно интересные сообщения:
01/03/10 20:02:47 ports: port 39 is now off-line
01/03/10 20:02:49 ports: port 39 is Blocked by LACP
01/03/10 20:02:52 ports: port 39 is now on-line
01/03/10 20:04:28 ports: port 39 is now off-line
Это говорит нам о том, что функционал LACP отрубает порты. Сам LACP (Link Aggregation Control Protocol) это протокол обеспечивающий работу транка, то есть объединение нескольких каналов в один для увеличения пропускной способности. Агрегированные каналы LACP используют для повышения пропускной способности канала и для и повышения отказоустойчивости.
Смотрим статистику конфигурации самого LACP
Chife-0# show lacp
LACP
ORT LACP TRUNK PORT LACP LACP
NUMB ENABLED GROUP STATUS PARTNER STATUS
……………..
35 Passive 35 Down No Success
36 Passive 36 Up No Success
37 Passive 37 Down No Success
38 Passive 38 Up No Success
39 Passive 39 Up No Success
LACP исходя из статистики пребывает в passive режиме, но при этом блокирует порты. Происходит это из-за того, что когда порт поднимает линк, passive LACP запрещает его использование до тех пор пока соединение не стабилизируется и не выяснится что это активное соединение. Если утверждение верно, то создается транк, если нет, то порт освобождается.
Для решения данной проблемы есть несколько ступенчатых вариантов разрешения проблемы:
1. Обновить версию прошивки свича до последней стабильной версии.
2. Проверить чтобы на обоих окончаниях сетевого кабеля выставлена одна и та же скорость и нет конфликтов: то есть с обоих сторон должна стоять или Auto-Auto или 100FDx -100FDx, но никак не Auto-100FDx
3. Если все вышесказанное не помогло, то можно отключить LACP если мы не используем его функционал для создании транка. При отключении данного функционала ничего не теряется ибо остается еще два варианта создания транков: HP port trunking (который использую я) и FEC.
Для этого опять же заходим в консоль и далее даем команды:
Chife-0# con t
Chife-0(config)# int all
Chife-0(eth-1-48,Trk1)# no lacp
Chife-0(eth-1-48,Trk1)# write mem
После выполнения этих команд перезагрузка свича не требуется.
Вчера ковырялся со свичами HP ProCurve и возникла необходимость задать время ручками, поскольку с NTP сервера свич забирать данные по каким то причинам отказывался. Делается это следующим образом, подключаемся к свичу по telnet или через X-modem и в консоли задаем следующие команды:
switch# config
switch(config)# clock set MM/DD/YYYY HH:MM:SS
switch(config)# wr mem
Вторую неделю воюю с замечательным провайдером Горком на предмет поддержки ими зоны обратного просмотра, она же реверсивная зона. Точнее внесения в неё моего MX сервера, поскольку при отправке почты на удаленные сервера, многие почтари проверяют наличие у сайта PTR записи как таковой и в случае её отсутствия, расценивают отправителя как спамера. Хитрованы же из Горкома убеждают меня в том, что это должен делать я сам и вообще письма от меня не доходят вовсе не из-за реверса упоминаемого в коде ошибки, а потому что у меня дескать не правильно настроен ns сервер.
Разработка, появившегося с год назад, было спонсировано исследовательским центром армии США и стало результатом исследований, в области информационной безопасности, организации SRI International. Как становится понятно уже из названия приложение предназначено для поиска ботов и вредоносных программ ставящих под угрозу компьютерную безопасность. Приложение BotHunter разработано для прослушивания сетевого диалога между внутренними и внешними сегментами сетей. BotHunter состоит из коррелирующего движка написанного на базе Snort 2, который отслеживает подозрительную сетевую активность: сканирование портов, использование эксплоитов, подготовки атак, p2p трафик. Коррелятор BotHunter сопоставляет информацию о входящих алертах и исходящей активности, на основе чего делает заключение о зараженности хоста. Если уровень вероятности заражения хоста, с точки зрения сетевого диалога BotHunter, приближается к критической точке, то программа начинает прослушивать и регистрировать все подобные события вычисляя их значение в процессе заражения.
Приложение доступно для FreeBSD (тестировано для 7.2 версии), Linux (тестировано для RHEL, SuSe, Debian и Fedore), Windows XP/Vista/2003,а также для Mac OS X (10.4 и 10.5).
Встала проблема у клиентов, прямо таки шариковская: есть канал интернета, нужно “взять все и поделить”, на несколько контор. В связи с чем, имея отмашку на некоторую сумму денег, озадачился поиском аппаратного шейпера, т.е. устройства ограничения полосы пропускания канала.
Первое, что пришло в голову это воспользоваться стандартной функцией управляемого свича Bandwidth Control , то есть ограничение скорости по порту- наиболее дешево и сердито, но как оказалось, например для имеющихся у клиентов HP ProCurve 2ХХХ серии данный функционал оказался недоступен, после чего погрузился в интернет с ключевым словом шейпер и bandwidth control . Варианты типо checkpoint не рассматривались, поскольку в первом приближении нужен был недорогой и простой аппаратный шейпер, хотя они и присутствуют начиная с safe@office в составе QoS, но устройства начального уровня мне не подходят, поскольку safe@office держит до 50-70 пользователей, а остальные начинаются от трешки зелени.
В результате нарыл некоторое количество моделек:
Для начала россыпью идут устройства от Planet: управляемый свич FGSW-2624SF и 8ми портовые гигабитники GSD-802PS / GSD-802S
почти в этом же ключе, хотя мне нравятся меньше, маршрутизаторы D-Link DGS-3610-26 / DI-1137C-1TP
какой то не понятный, но близкий сердцу названием маршрутизатор TP-Link TL-R480T
вроде как поддерживают большинство маршрутизаторов и рутеров от Linksys WRT310N / EZXS55W / EZXS88W / EZXS16W / WET610N / WRT160N / WRT610N / WRT110 но надо вчитываться в каждое дополнительно
как более дорогой аналог: Cisco Catalyst 3500 (команда Rate Limiting)
ну и наколенные варианты Zyxel P-334WT EE которые я не очень лю, поскольку уже имел опыт неприятной работы с их оборудованием
Вариант с Planet мне понравился больше всего, поскольку пользовался ими длительное время и никаких нареканий на их оборудование не имею, кроме разве что слишком низкой цены но пораскинув немного мозгами, пришел к тому что не плохо было бы иметь на внешнем шейпере и ips с доступом к нефильтрованному трафику, поэтому вероятнее всего в ближайшее время буду настраивать шейпер под freebsd с прикрученным туда же snort’ом
Математику я никогда особо не любил, и поэтому все вычисления из разряда двоичной-шестнадцатеричной математики для меня являются головняком. В этой связи, задача посчитать бинарную маску, отличную от кратных 8, повергает меня в ментальный ступор, при том что теория мне ясна и понятна.
В этой связи выискал в инете приятственную картинку, прикрепив которую на стенку, можно радостно забить на всю теорию. (more…)
Tcpdump чрезвычайно удобный сетевой анализатор, очень помогающий в работе как сетевым администраторам, так и безопасникам. Естественно что для получения максимальной информации при работе с tcpdump, просто необходимо иметь представления о стеке протоколов TCP/IP. Для удобства можно использовать более удобные и интеллектуальные программы, например , но часто возникают ситуации когда на тестируемую машину не представляется возможным установить дополнительные сервисы, и тогда tcpdump просто незаменим, не будит же админ, ради анализа пакетов, ставить на unix’овый сервак X-Windows тем более что в большинстве unix’овых систем, утилита tcpdump идет по умолчанию.
Понимание протокола TCP/IP дает широкое пространство для использование анализатора и устранения неисправностей и неполадок в работе сети, за счет разбора пакетов. Поскольку оптимальное использование данной утилиты требует хорошего понимания сетевых протоколов и их работы, то получается забавная ситуация, в которой инженеру в любом случае необходимо знать и понимать механизмы передачи данных в сети. т.ч. tcpdump полезна во все отношениях: как устранения неисправностей, так и самообразования. (more…)