Архив

Архив Январь 2011

Настройка DHCP-сервера на маршрутизаторе Cisco

31 января 2011

В большинстве маршрутизаторов Cisco существует возможность настроить DHCP-сервер на базе IOS. Его функциональность достаточно широка для того, чтобы, например, запустить IP-телефонию на базе CUCME в небольшом филиале.

К делу. У нас есть маршрутизатор Cisco 2951 (voice-bundle с CUCME). Исходные данные таковы:
— сеть 192.168.1/24
— зарезервированы адреса в диапазоне 192.168.1.1 — 192.168.1.20
— шлюз по умолчанию — 192.168.1.1
— CUCME-сервер — 192.168.1.1
— DNS-серверы: 192.168.1.10, 192.168.1.20

Про CUCME я упоминаю только для того, чтобы оправдать необходимость демонстрации настройки дополнительных опций DHCP. Т.к. IP-телефонам Cisco для работы необходимо указывать адрес TFTP-сервера, мы создадим в DHCP параметр (150), раздающий клиентам адрес TFTP.

Router(config)#ip dhcp excluded-address 192.168.1.1 192.168.1.20
Router(config)#ip dhcp pool Pool-Name
Router(dhcp-config)#network 192.168.1.0 255.255.255.0
Router(dhcp-config)#option 150 ip 192.168.1.1
Router(dhcp-config)#default-router 192.168.1.1
Router(dhcp-config)#dns-server 192.168.1.10 192.168.1.20
Router(dhcp-config)#exit

Default , , , ,

WP-Note

29 января 2011

Установил WP-Note, выводящий красивые информационные таблички при вставке соответствующего тега.
Примеры:

 Этот текст обрамлен тегом [ note ]

Этот текст обрамлен тегом [ important ]

Этот текст обрамлен тегом [ warning ]

Этот текст обрамлен тегом [ tip ]

Этот текст обрамлен тегом [ help ]

Как и где буду применять — ума не приложу, но нравится.

Default ,

О быстродействии сетей TCP/IP

15 января 2011

Консультативно решал проблему с низким быстродействием гигабитной сети на 200 хостов. Решил. Полуневменяемому заказчику (кстати, айтишнику) пришлось канонически обосновывать причины, по которым было выбрано решение. И в процессе предлагать статистику, доходчиво объясняющую, почему сети иногда тормозят. Формулирую еще раз, уже публично.

Быстродействие сетей TCP/IP обычно ограничивается следующими типами ошибок:

1. потери и повреждения пакетов;
2. перегрузка каналов связи;
3. плохое оборудование;
4. некорректная IP-маршрутизация, большое время двойного оборота;
5. недопустимые размеры пакетов;
6. неэффективные приложения.

Вопросов не вызвали, пожалуй, только пункты 3 (за исключением стандартного: “А чой-то оно плохое вдруг?!”) и 6 (за исключением такого же стандартного, мол: “А чой-то они неэффективные вдруг?!”). Но на то он и руководитель департамента ИТ со степенью MBA, чтобы ничего не смыслить в технике, но давать ценные указания по работе с ней. Перевел на человеческий язык, таки почему ж тормозят сети:

1. кривые руки сетевого администратора;
2. непредназначенное для работы в enterprise-среде оборудование (в т.ч. устаревшее морально и физически);
3. зоопарк вирусов в сети (слышал о бот-нетах на несколько тысяч хостов, рассылающих горы спама… какое уж там быстродействие);
4. кривое ПО (написанное девелопмент-студией из Вышнего Волочка в перерывах между парами в шараге и брошенное на произвол судьбы сразу же после подписания акта о выполненных работах и последующей оплаты);
5. неквалифицированный технический персонал в целом (вынес отдельно от пункта 1, поскольку сетевой администратор может быть и вменяемым, а вот системный может запускать многочасовое резервное копирование через коммутатор уровня доступа на слабосильный NAS в рабочее время).

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

Default , , ,