До недавнего времни имел очень узкое представление о MPLS как о простой коммутации на основе меток.
На Opennet.ru нашелся замечательный сборник документации по MPLS на русском: http://www.opennet.ru/docs/RUS/mpls/
Читать следует с большой осторожностью, особенно новичкам - ломота в мозге и сны с "облаками" гарантированны.
Всем новичкам MPLS советую ознакомится.
Показаны сообщения с ярлыком network. Показать все сообщения
Показаны сообщения с ярлыком network. Показать все сообщения
10 нояб. 2010 г.
9 авг. 2010 г.
8 авг. 2010 г.
Пишем анти-спуфинг ACL
Написано дабы самому не забыть и товарищам почитать.
Итак, задача укрепить защиту маршрутизатора напрямую подключенного в Интернет.
Первым делом защитимся от спуфинга - исключим из обработки (попросту отбросим) все пакеты идущие от серых (частных) сетей. Серые сети это сети предназначенные для частного использования и не маршрутизируемые в сети Интернет. Данные сети описаны в RFC1918, это префиксы 10/8, 172.16/12, 192.168/16.
В сети Интернет имеется еще несколько диапазонов адресов, появление которых на интерфейсе подключенном к сети интернет, в нормальных условиях будет по меньшей мере необычным. Данные сети описаны в RFC3330.
Следует понимать, что RFC3330 описывает сети специального назначения. Некоторые из этих сетей успели поменять свое назначение на "Reserved but subject to allocation", т.е. зарезервированы, но могут быть предоставленны в пользование. В общем случае такие сети блокировать не стоит, так как в случае передачи этих сетей в пользование, вы не сможете обмениваться с этой сетью данными.
Итак, составим список сетей которые мы будем блокировать на внешнем интерфейсе:
Также, тем кто получил собственный диапазон адресов, рекомендуется добавить собственную сеть в данный список на граничных маршрутизаторах.
На основе полученного списка сетей, составим ACL.
В данном случае я буду использовать extended acl, просто для возможности в будущем фильтровать еще и по адресу назначения.
У меня получился такой список доступа:
В данном списке доступа, кроме перечиленных выше префиксов, добавлено еще два хостовых адреса:
Также следует помнить, что на интерфейсах с настроенными туннелями IPSec, ACL повешенный на вход интерфейса проверяет сначала заголовок пакета IPSec, а затем этот же ACL проверяет заголовок шифрованного пакета. Таким образом упоминание в данном ACL частных сетей может нарушить функционирование туннеля.
После написания списка доступа, применяем его на вход на всех интерфейсах подключенных в сеть Интернет или в другие не безопасные сети:
Такая настройка внешних интерфейсов поможет избежать атаки с подделаных адресов.
Источники:
Итак, задача укрепить защиту маршрутизатора напрямую подключенного в Интернет.
Первым делом защитимся от спуфинга - исключим из обработки (попросту отбросим) все пакеты идущие от серых (частных) сетей. Серые сети это сети предназначенные для частного использования и не маршрутизируемые в сети Интернет. Данные сети описаны в RFC1918, это префиксы 10/8, 172.16/12, 192.168/16.
В сети Интернет имеется еще несколько диапазонов адресов, появление которых на интерфейсе подключенном к сети интернет, в нормальных условиях будет по меньшей мере необычным. Данные сети описаны в RFC3330.
Следует понимать, что RFC3330 описывает сети специального назначения. Некоторые из этих сетей успели поменять свое назначение на "Reserved but subject to allocation", т.е. зарезервированы, но могут быть предоставленны в пользование. В общем случае такие сети блокировать не стоит, так как в случае передачи этих сетей в пользование, вы не сможете обмениваться с этой сетью данными.
Итак, составим список сетей которые мы будем блокировать на внешнем интерфейсе:
- 10.0.0.0/8 - описана в RFC1918;
- 172.16.0.0/12 - описана в RFC1918;
- 192.168.0.0/16 - описана в RFC1918;
- 224.0.0.0/4 - RFC3330, Мультикастовые сети;
- 127.0.0.0/8 - RFC3330, Лупбэк сеть;
- 169.254.0.0/8 - RFC3330, RFC3927, Zeroconf адреса;
- 192.0.2.0/24 - RFC3330, Сеть для тестирования и использования в публикациях;
- 240.0.0.0/4 - RFC3330, Зарезервировано для будущего использования.
Также, тем кто получил собственный диапазон адресов, рекомендуется добавить собственную сеть в данный список на граничных маршрутизаторах.
На основе полученного списка сетей, составим ACL.
В данном случае я буду использовать extended acl, просто для возможности в будущем фильтровать еще и по адресу назначения.
У меня получился такой список доступа:
#sho ip access-list
Extended IP access list AntiSpoof
10 deny ip host 0.0.0.0 any
20 deny ip 10.0.0.0 0.255.255.255 any
30 deny ip 172.16.0.0 0.15.255.255 any
40 deny ip 192.168.0.0 0.0.255.255 any
50 deny ip host 255.255.255.255 any
60 deny ip 224.0.0.0 15.255.255.255 any
70 deny ip 127.0.0.0 0.255.255.255 any
80 deny ip 169.254.0.0 0.0.255.255 any
90 deny ip 192.0.2.0 0.0.0.255 any
100 deny ip 240.0.0.0 15.255.255.255 any
110 permit ip any any
В данном списке доступа, кроме перечиленных выше префиксов, добавлено еще два хостовых адреса:
- 0.0.0.0;
- 255.255.255.255;
Также следует помнить, что на интерфейсах с настроенными туннелями IPSec, ACL повешенный на вход интерфейса проверяет сначала заголовок пакета IPSec, а затем этот же ACL проверяет заголовок шифрованного пакета. Таким образом упоминание в данном ACL частных сетей может нарушить функционирование туннеля.
После написания списка доступа, применяем его на вход на всех интерфейсах подключенных в сеть Интернет или в другие не безопасные сети:
#conf t
#int f0/0
#ip access-group AntiSpoof
#end
Такая настройка внешних интерфейсов поможет избежать атаки с подделаных адресов.
Источники:
10 мая 2010 г.
L2TPv3 Ethernet Pseudowire
Отличная статья по настройке L2TPv3 Pseudowire на оборудовании Cisco: Configuring an L2TPv3 Ethernet Pseudowire
8 апр. 2010 г.
Вендел Одом про TSHOOT и его Beta
Вендел Одом опубликовал статью о сдаче TSHOOT, и отразил вней свое мение и найденые ошибки в бета-экзамене
6 апр. 2010 г.
STP/RSTP как они сходятся
Петр Лапухов на http://www.ine.com опубликовал обширный документ "Understanding STP and RSTP Convergence".
Всем готовящемся к сдаче BCMSN и всем кто администрирует сети использующие STP/RSTP.
Всем готовящемся к сдаче BCMSN и всем кто администрирует сети использующие STP/RSTP.
31 мар. 2010 г.
Краткий обзор возможностей по распростренению настроек на IP-телефоны Nortel по DHCP и TFTP
В одной из предыдущих заметок я описывал механизм передачи первичных параметров на телефоны Nortel.
В данной заметке я хочу продолжить это краткое ознакомление.
IP-телефоны Nortel могут быть конфигурированы следующими способами:
Сейчас рассмотрим конфигурирование через DHCP и TFTP.
По DHCP телефону можно передать множество различных настроек:
Еще более тонкая настройка доступна через файлы настроек на TFTP-сервере. В этих файлах могут указываться теже параметры и используется во многом схожий синтаксис.
Имеется возможность передавать настройки по следующим типам:
Таким образом, у нас есть возможность выделить в своей сети несколько зон и указывать для них раздельные настройки, например указать отдельный севрер для нашего удаленного офиса.
Полное руководство по настройке телефонов содержит Nortel CS 1000: IP Phones Fundamentals.
В данной заметке я хочу продолжить это краткое ознакомление.
IP-телефоны Nortel могут быть конфигурированы следующими способами:
- Ручной - напрямую с клавиатуры телефона;
- LLDP - телефон получает часть настроек напрямую от коммутатора (например голосовой вилан и вилан данных);
- DHCP - получение настроек вместе с другими параметрами с DHCP-сервера;
- TFTP - чтение настроек из файлов на TFTP-сервере;
- UNIStim.
Сейчас рассмотрим конфигурирование через DHCP и TFTP.
По DHCP телефону можно передать множество различных настроек:
- s1ip - Primary server IP address;
- p1 - Primary server port number;
- a1 - Primary server action code;
- r1 - Primary server retry count;
- zone - Zone ID (Character string up to 8 characters);
- menulock - Menu lock mode (f - for full lock, p - for partial,u - for unlock);
- unid - Unique network identification (Character string up to 32 characters);
- blt - Backlight timer (IP Phone 1100 series and 2007);
- ssh - Enable Secure Shell (SSH);
- sshid - SSH ID;
- sshpwd - SSH password.
Еще более тонкая настройка доступна через файлы настроек на TFTP-сервере. В этих файлах могут указываться теже параметры и используется во многом схожий синтаксис.
Имеется возможность передавать настройки по следующим типам:
- Специфичные для конкретного экземпляра устройва - файл {DEVICE}.PRV;
- Специфичные для зоны, в которой распологаются устройва - {ZONE}.PRV;
- Специфичные для конкретной модели устройв - {TYPE}.PRV, например для модели 1165E настраивается Bluetooth;
- Общесистемный настройки - SYSTEM.PRV.
Таким образом, у нас есть возможность выделить в своей сети несколько зон и указывать для них раздельные настройки, например указать отдельный севрер для нашего удаленного офиса.
Полное руководство по настройке телефонов содержит Nortel CS 1000: IP Phones Fundamentals.
21 мар. 2010 г.
Шаблон базовой настройки маршрутизатора Cisco
На Хабре опуликована замечательная заметка Шаблон базовой настройки маршрутизатора Cisco.
9 мар. 2010 г.
Бродкаст-адрес в качестве ip helper-address
В больших сетях с развитой адресацией часто DHCP-сервер находится в другой, возможно очень отдаленной, подсети от клиента которому необходимы сетевые настройки.
И в таком случае администраторы на интерфейсе клиентского вилана прописывают ip helper-address - адрес на который пересылаются udp-бродскасты (по умолчанию это порты: 37, 42, 49, 53, 67, 68, 69, 137 и 138).
В таком случае если DHCP-сервер изменяет свой адрес (например, мигрировал на другой сервер) необходимо будет изменить на всех интерфейс-виланах ip helpter-address.
В свою очередь DHCP-сервер тоже находится в отдельной подсети, и эта подсеть имеет свой бродкастовый адрес. Допустим наш DHCP-сервер расположен в подсети 10.1.1.0, его адрес 10.1.1.1, маска подсети будет 255.255.255.248 и соответственно бродкастовый адрес подсети 10.1.1.7.
Конфигурация SVI вилана DHCP-серверов:
Логично предположить, что прописывая на SVI клиентского вилана не юникастовые, а бродкастовые ip helper-address можно дать себе возможность при необходимости добавлять/удалять сервера из пула (в нашем случае из сети 10.1.1.0/29) без перенастройки клиентских виланов.
Для примера возьмем клиентский вилан 100, в котором расположена сеть 10.1.2.0/24:
Однако данная конфигурация не работает.
На коммутаторах Cisco для обеспечения трансляции пакетов поступивших на бродкастовый адрес подсети извне этой сети, необходимо указать команду ip directed-broadcast. После чего коммутатор будет транслировать поступающие бродкасты в физические порты вилана.
Окончательная конфигурация серверного вилана выглядит следующим образом:
Ссылки:
IP Addressing and Services Commands
И в таком случае администраторы на интерфейсе клиентского вилана прописывают ip helper-address - адрес на который пересылаются udp-бродскасты (по умолчанию это порты: 37, 42, 49, 53, 67, 68, 69, 137 и 138).
В таком случае если DHCP-сервер изменяет свой адрес (например, мигрировал на другой сервер) необходимо будет изменить на всех интерфейс-виланах ip helpter-address.
В свою очередь DHCP-сервер тоже находится в отдельной подсети, и эта подсеть имеет свой бродкастовый адрес. Допустим наш DHCP-сервер расположен в подсети 10.1.1.0, его адрес 10.1.1.1, маска подсети будет 255.255.255.248 и соответственно бродкастовый адрес подсети 10.1.1.7.
Конфигурация SVI вилана DHCP-серверов:
int vlan 5
description DHCP_SERVERS
ip address 10.1.1.6 255.255.255.248
end
Логично предположить, что прописывая на SVI клиентского вилана не юникастовые, а бродкастовые ip helper-address можно дать себе возможность при необходимости добавлять/удалять сервера из пула (в нашем случае из сети 10.1.1.0/29) без перенастройки клиентских виланов.
Для примера возьмем клиентский вилан 100, в котором расположена сеть 10.1.2.0/24:
int vlan 100
ip address 10.1.2.1 255.255.255.0
ip helper-address 10.1.1.7
end
Однако данная конфигурация не работает.
На коммутаторах Cisco для обеспечения трансляции пакетов поступивших на бродкастовый адрес подсети извне этой сети, необходимо указать команду ip directed-broadcast. После чего коммутатор будет транслировать поступающие бродкасты в физические порты вилана.
Окончательная конфигурация серверного вилана выглядит следующим образом:
int vlan 5
description DHCP_SERVERS
ip address 10.1.1.6 255.255.255.248
ip directed-broadcast
end
Ссылки:
IP Addressing and Services Commands
6 мар. 2010 г.
Впечатления от сдачи экзамена Cisco TSHOOT Beta (643-832)
Вчера сдавал экзамен Cisco TSHOOT Beta (643-832).
Из положительного:
Из положительного:
- Новый GUI - понравилось что теперь время отсчитывается назад и ты всегда знаешь сколько осталось;
- всего 12 вопросов, остальное практические задания;
- Времени дали 3 часа
- Команды IOS попрежнему реализованы не все - например, очень не хватало "show int status";
- Практика решается в форме ответа на вопросы, конфигурацию изменять для проверки своей гопотезы нельзя - одно задание не смог решить, так как небыло нужного варианта ответа, потратил на него 45 минут;
- Есть опечатки как в топологии, так и в выводе команд - у меня один раз адреса выводились неправильные.
2 мар. 2010 г.
Превращаем Cisco Catalyst 6500 в кабельный тестер
Открыл для себя очень удобную фенечку 65ой каталисты - некоторые карты имеют встроенный "кабельный тестер" Time Domain Reflectometry (TDR)!
TDR может использоваться для определения обрывов в кабеле, неверно обжатых коннекторов, повреждений изоляции и др.
TDR поддерживается следующими медными линейными картами:
• WS-X6748-GE-TX (48 port CEF720 10/100/1000 line card)
• WS-X6548-GE-TX/45AF (48 port CEF256 10/100/1000 line card)
• WS-X6148A-GE-TX/45AF (48 port Classic 10/100/1000 line card)
• WS-X6148-GE-TX/45AF (48 port Classic 10/100/1000 line card)
• WS-X6148A-RJ-45/45AF (48 port Classic 10/100 line card)
Для тестирования кабеля необходимо выполнить две команды:
1. Первая - команда на тестирование порта:
2. Вторая - вывод данных тестирования:
в данном тесте обнаружено к-з на паре 7-8 .
Ссылки:
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd805457cc.html
TDR может использоваться для определения обрывов в кабеле, неверно обжатых коннекторов, повреждений изоляции и др.
TDR поддерживается следующими медными линейными картами:
• WS-X6748-GE-TX (48 port CEF720 10/100/1000 line card)
• WS-X6548-GE-TX/45AF (48 port CEF256 10/100/1000 line card)
• WS-X6148A-GE-TX/45AF (48 port Classic 10/100/1000 line card)
• WS-X6148-GE-TX/45AF (48 port Classic 10/100/1000 line card)
• WS-X6148A-RJ-45/45AF (48 port Classic 10/100 line card)
Для тестирования кабеля необходимо выполнить две команды:
1. Первая - команда на тестирование порта:
6K-LV2-CL3# test cable-diagnostics tdr interface g1/3
TDR test started on interface Gi1/3
A TDR test can take a few seconds to run on an interface
Use 'show cable-diagnostics tdr' to read the TDR results.
2. Вторая - вывод данных тестирования:
6K-LV2-CL3# show cable-diagnostics tdr interface g1/3
TDR test last run on: March 5 10:22:06
Interface Speed Pair Cable length Distance to fault Channel Pair status
--------- ----- ---- ------------------- ------------------- ------- ------------
Gi1/3 1000 1-2 1 +/- 6 m N/A Pair B Terminated
3-4 1 +/- 6 m N/A Pair A Terminated
5-6 1 +/- 6 m N/A Pair C Terminated
7-8 1 +/- 2 m N/A Pair D Short
в данном тесте обнаружено к-з на паре 7-8 .
Ссылки:
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd805457cc.html
24 февр. 2010 г.
PPTP Connection-tracking в Линукс
Наверное многих администраторов pptp-серверов линукс вводила в замешательство и заставляла долго ходить по форумам в поисках лекарства проблема с подключением windows-клиентов. Так случилось у меня.
Поставил и настроил pptp-сервер, с подключением из линукс нет проблем, но первый же windows-клиент говорит "подключаюсь и авторизуюсь, но сразу же выкидывает"...
На форумах находил или темы без ответа или бредовые идеи что все дело в DNS-сервере...
Когда накопал костыль "поставить правило явно пропускающее весь GRE до всех сonnection-tracking правил" неповерил, но время поджимало и попробовал. Помогло, коллега с виндовым ноутом смог нормально работать.
Такое решение не устраивало. Даже в скрипт файервола прописывать не стал.
Добрый человек Hando на форуме anticisco.ru открыл глаза - Для правильного автоматического трекинга соединений по протоколу PPTP необходимо в загрузку добавить модуль nf_conntrack_pptp.
Итак, прописываем nf_conntrack_pptp в /etc/modules.d и наслаждаемся.
Поставил и настроил pptp-сервер, с подключением из линукс нет проблем, но первый же windows-клиент говорит "подключаюсь и авторизуюсь, но сразу же выкидывает"...
На форумах находил или темы без ответа или бредовые идеи что все дело в DNS-сервере...
Когда накопал костыль "поставить правило явно пропускающее весь GRE до всех сonnection-tracking правил" неповерил, но время поджимало и попробовал. Помогло, коллега с виндовым ноутом смог нормально работать.
Такое решение не устраивало. Даже в скрипт файервола прописывать не стал.
Добрый человек Hando на форуме anticisco.ru открыл глаза - Для правильного автоматического трекинга соединений по протоколу PPTP необходимо в загрузку добавить модуль nf_conntrack_pptp.
Итак, прописываем nf_conntrack_pptp в /etc/modules.d и наслаждаемся.
28 янв. 2010 г.
Voice-VLAN на Cisco Catalyst для Nortel IP Phone
Как удалось выяснить и опробовать сегодня на практике, Cisco Catalyst может передавать информацию о Voice-VLAN на IP-телефоны Nortel! :)
Для этого на коммутаторе достаточно включить протокол LLDP и прописать voice-vlan на порту телефона:
#conf t
#lldp run
#int fa1/0/1
#switchport voice-vlan 10
И конечно нужно чтобы на телефоне тоже был включен LLDP, указано тэгировать Voice-VLAN и конфигурировать его автоматически. Также на телефоне необходимо отключить тэгирование в Data-VLAN.
Тестирование проводилось на коммутаторе Catalyst 3750-24TS (IOS 12.2(46)) и телефонах Nortel 1110 и 1120.
Изрядно намучался с настройкой телефонов - русский перевод меню просто Ужасный!
Меню телефонов вообще неудобное, очень. Видимо нужно учится конфигурировать эти телефоны по сети.
Честно говоря, мне до последнего не верилось что Cisco включит передачу Voice-VLAN в реализацию LLDP. но я очень рад что компания пошла по пути унификации.
Ссылки:
Michael McNamara - LLDP with Cisco 3750
LLDP-MED and Cisco Discovery Protocol
Configuring LLDP and LLDP-MED
Для этого на коммутаторе достаточно включить протокол LLDP и прописать voice-vlan на порту телефона:
#conf t
#lldp run
#int fa1/0/1
#switchport voice-vlan 10
И конечно нужно чтобы на телефоне тоже был включен LLDP, указано тэгировать Voice-VLAN и конфигурировать его автоматически. Также на телефоне необходимо отключить тэгирование в Data-VLAN.
Тестирование проводилось на коммутаторе Catalyst 3750-24TS (IOS 12.2(46)) и телефонах Nortel 1110 и 1120.
Изрядно намучался с настройкой телефонов - русский перевод меню просто Ужасный!
Меню телефонов вообще неудобное, очень. Видимо нужно учится конфигурировать эти телефоны по сети.
Честно говоря, мне до последнего не верилось что Cisco включит передачу Voice-VLAN в реализацию LLDP. но я очень рад что компания пошла по пути унификации.
Ссылки:
Michael McNamara - LLDP with Cisco 3750
LLDP-MED and Cisco Discovery Protocol
Configuring LLDP and LLDP-MED
27 дек. 2009 г.
Оборудование Cisco: курс молодого бойца
Хочу порекомендовать всем начинающим Cisco-водам "Курс молодого бойца" Сергея Федорова.
Так же статью этого же автора на Хабре: http://habrahabr.ru/blogs/cisconetworks/69782/
Оба труда хорошо систематизированы, подходят не только для начинающего читателя и помогают систематизировать полученные ранее знания.
Так же статью этого же автора на Хабре: http://habrahabr.ru/blogs/cisconetworks/69782/
Оба труда хорошо систематизированы, подходят не только для начинающего читателя и помогают систематизировать полученные ранее знания.
9 апр. 2009 г.
Vnstat - смотрим статистику через веб
Итак, vnstat настроен и собирает статистику.
Не всегда удобно заходить на консоль сервера только для того чтобы посмотреть статистику. Иногда нужно предоставить доступ третьим лицам, а консольный доступ давать не хотелось бы.Проблема решается написанием небольшого скрипта для вывода статистики в веб.
Исходим из того что веб-сервер у нас уже установлен и настроен, дело за малым - написать скрипт!Сервер линуксовый и чтобы не тянуть лишних зависимостей за скриптом, пишем на Shell:
#!/bin/sh
INTERFACES="LAN:eth0 WAN:eth1 DMZ:eth2"
echo "Content-Type: text/html; charset=utf8 \n\n";
echo '<HTML><head><link rel="stylesheet" href="/style.css" type="text/css" /></head>';
echo "<BODY>";
# evalute variables
for int in `echo ${INTERFACES} \
| sed -e 's/ /\n/g'`;
do
int_name=`echo ${int} | cut --delimiter=: --fields=1`
intf=`echo ${int} | cut --delimiter=: --fields=2-2`
echo "<p><h2>${int_name} interface (${intf})</h2>"
echo '<pre class="tab1">'
vnstat -q -d -i ${intf}
echo "</pre></p>"
done;
Переменная INTERFACES определяет пары "Название интерфейса"-интерфейс по которым необходимо выводить статистику.
Размещаем этот скрипт на сервере, где снимаем статистику с интерфейсов, и настраиваем веб-сервер.

7 апр. 2009 г.
Считаем трафик на интерфейсах сервера
Дано:
Почтовый сервер на базе Ubuntu 8.10
Четыре сетевых интерфейса
Необходимо:
Считать трафик на каждом интерфейсе, вести статистику.
Решение:
vnstat - маленький консольный пакет, который считает трафик на указанных интерфейсах и не загружает систему. Статистика считается отдельно для каждого интерфейса, трафик по ip-адресам и портам не делится. Статистика выводится по запросу с детализацией по часам, дням, неделям и тд.
Хранится статистика в файлах в каталоге /var/lib/vnstat.
Занимает места мало - у меня за три дня работы 4кб для каждого интерфейса, итого 12кб для трех наблюдаемых интерфейсов.
Устанавливаем vnstat:
#apt-get install vnstat
Инициализируем базу данных для каждого необходимого интерфейса:
#vnstat -u -i eth0
#vnstat -u -i eth1
#vnstat -u -i eth2
Далее необходимо сказать vnstat запустить мониторинг интерфейса.
Это можно сделать путем ifdown/ifup для каждого интерфейса,
либо, если нет желания разрывать соединения выполнить для каждого:
#IFACE=eth${i}
#export IFACE
#/bin/sh -x /etc/network/if-up.d/vnstat
где ${i} порядковый номер интерфейса.
Все, мониторинг готов, теперь по прошествии нескольких минут можно смотреть статистику
#vnstat -q
Почтовый сервер на базе Ubuntu 8.10
Четыре сетевых интерфейса
Необходимо:
Считать трафик на каждом интерфейсе, вести статистику.
Решение:
vnstat - маленький консольный пакет, который считает трафик на указанных интерфейсах и не загружает систему. Статистика считается отдельно для каждого интерфейса, трафик по ip-адресам и портам не делится. Статистика выводится по запросу с детализацией по часам, дням, неделям и тд.
Хранится статистика в файлах в каталоге /var/lib/vnstat.
Занимает места мало - у меня за три дня работы 4кб для каждого интерфейса, итого 12кб для трех наблюдаемых интерфейсов.
Устанавливаем vnstat:
#apt-get install vnstat
Инициализируем базу данных для каждого необходимого интерфейса:
#vnstat -u -i eth0
#vnstat -u -i eth1
#vnstat -u -i eth2
Далее необходимо сказать vnstat запустить мониторинг интерфейса.
Это можно сделать путем ifdown/ifup для каждого интерфейса,
либо, если нет желания разрывать соединения выполнить для каждого:
#IFACE=eth${i}
#export IFACE
#/bin/sh -x /etc/network/if-up.d/vnstat
где ${i} порядковый номер интерфейса.
Все, мониторинг готов, теперь по прошествии нескольких минут можно смотреть статистику
#vnstat -q
29 июл. 2008 г.
Меняем сетевую карту на машине с ОС UnixWare 7.1.3
Случилось несчастье - сдохла материнская плана.
Сетевая карта была встроенная. Заменили плату, изменился и чип сетевой карты - стала RTL8101L, вместо Intel.
Пляски с бубном вокруг установки драйверов на карту от производителя ничего не дали - драйвера исправно встают, но ОС карту Cвидеть отказывается.
На сайте SCO информацию по данному вопросу найти не удалось.
Сети нет, а машина нужна в работе. Решено было попробовать поставить другую карту, под рукой была 3COM - 3C905C-TX.
Запускаем netcfg, в меню "Hardware" выбираем пункт "Add..", ОС определила карту, спросила какой транспортный протокол использовать на этой карте, спросила настройки TCP/IP протокола и все заработало :)
Сетевая карта была встроенная. Заменили плату, изменился и чип сетевой карты - стала RTL8101L, вместо Intel.
Пляски с бубном вокруг установки драйверов на карту от производителя ничего не дали - драйвера исправно встают, но ОС карту Cвидеть отказывается.
На сайте SCO информацию по данному вопросу найти не удалось.
Сети нет, а машина нужна в работе. Решено было попробовать поставить другую карту, под рукой была 3COM - 3C905C-TX.
Запускаем netcfg, в меню "Hardware" выбираем пункт "Add..", ОС определила карту, спросила какой транспортный протокол использовать на этой карте, спросила настройки TCP/IP протокола и все заработало :)
9 мар. 2008 г.
Защита сети на уровне доступа от образования петель на коммутаторах hp без использования STP
Коммутаторы hp 2510-24 (и ряд других моделей производителя) имеют поддержку протоколов *STP (MSTP, RSTP, STP).
Применение этих протоколов на уровне доступа сопряжено с некоторыми проблемами - длительное блокирование порта при включении и периодическая длительная блокировка для проверки топологии.
Компания hp с 2007 года включила в прошивки части коммутаторов функцию защиты от образования петель (loop-protect).
Данная функция использует посылку пакета на мультикастовый адрес, который теоретически ни одно устройство в локальной сети не блокирует, что нередко случается с BPDU (например, коммутаторы hp 1800 и некоторые модели ip-телефонов их блокируют).
Конечно применение опции Edge-Port (FastPort) при конфигурировании STP позволяет сократить время блокировки порта до 5 секунд, но остается вопрос насколько целесообразно применение STP на портах где явно предполагается подключение рабочих мест.
Также с помощью loop-protect есть возможность автоматически извещать по протоколу SNMP систему мониторинга об образовании петли, что сильно упрощает работу администратора.
Далее приведу перевод части Руководства по настройке касаемое функции loop-protect:
Применение этих протоколов на уровне доступа сопряжено с некоторыми проблемами - длительное блокирование порта при включении и периодическая длительная блокировка для проверки топологии.
Компания hp с 2007 года включила в прошивки части коммутаторов функцию защиты от образования петель (loop-protect).
Данная функция использует посылку пакета на мультикастовый адрес, который теоретически ни одно устройство в локальной сети не блокирует, что нередко случается с BPDU (например, коммутаторы hp 1800 и некоторые модели ip-телефонов их блокируют).
Конечно применение опции Edge-Port (FastPort) при конфигурировании STP позволяет сократить время блокировки порта до 5 секунд, но остается вопрос насколько целесообразно применение STP на портах где явно предполагается подключение рабочих мест.
Также с помощью loop-protect есть возможность автоматически извещать по протоколу SNMP систему мониторинга об образовании петли, что сильно упрощает работу администратора.
Далее приведу перевод части Руководства по настройке касаемое функции loop-protect:
- Включение loop-protect:
ProCurve(config)# loop-protect <port-list>
Синтаксис: [no] loop-protect <port-list> [receiver-action <send-disable | no-disable> ] [transmit-interval <1-10> ] | [disable-timer <0-604800>] | [trap <loop-detected>]- [receiver-action <send-disable | no-disable>]
Устанавливает действие при обнаружении петли на порту. Если у казано "send-disable", то порт передавший пакет отключается. Если же установлено значение "no-disable" порт остается включенным.
Значение по умолчанию: send-disable - [trap <loop-detected>]
Позволяет сконфигурировать ловушку (trap) “loop-detected”, которая означает что на определенном порту обнаружена петля. - [disable-timer <0-604800>]
Определяет сколько секунд коммутатор ждет перед попыткой задействовать порт на котором была определена петля. Нулевое значение запрещает попытки задействовать порт.
Значение по умолчанию: 0. - [transmit-interval <1-10>]
Определяет частоту передачи пакетов обнаружения петель.
Значение по умолчанию: 5 секунд.
- [receiver-action <send-disable | no-disable>]
- Для вывода информации по портам с включенной функцией обнаружения петель введите следующую команду:
show loop-protect <port-list>
Если не указан список портов, то выводится информация только для портов на которых данная функция включена.
20 февр. 2008 г.
Шпаргалка по настройке коммутаторов hp 2824 (2848)
- Включаем IGMP для VLAN 1:
2824#conf
2824(config)#vlan 1 ip igmp - Включаем STP:
2824#conf
2824(config)#span
указываем какой протокол необходимо использовать (STP, RSTP или MSTP):
2824(config)#span protocol-version rstp
устанавливаем приоритет коммутатора (по умолчанию 8, у меня же в сети этот коммутатор является ядром - приоритет поднял до 3):
2824(config)#span pri 3
17 февр. 2008 г.
Шпаргалка по настройке коммутаторов hp 2510-24
- Включаем IGMP для VLAN 1:
2510-24# conf
2510-24(config)# vlan 1 ip igmp
отключаем фунцкию курьера, курьером будет коммутатор ядра
2510-24(config)# no vlan 1 ip igmp - Включаем STP:
2510-24#conf
2510-24(config)#span
указываем какой протокол необходимо использовать (STP, RSTP или MSTP):
2510-24(config)#span force-version rstp-operation
устанавливаем приоритет коммутатора (по умолчанию 8):
2510-24(config)#span pri 8
на портах к которым будут подключены непосредственно рабочие места включаем режим Edge-Port:
2510-24(config)#span eth 1-24 admin-edge-port - Включаем LACP на гигабитных портах:
2510-24(config)#int eth 25-26 lacp active
Подписаться на:
Сообщения (Atom)
