Расчет параметров rate-limit для QoS'а на Cisco

Для ограничения полосы на интерфейсе, если использование policy-map по каким-то причинам не желательно, используется rate-limit:
int fas0/0.15
rate-limit output 'rate' 'burst_norm' 'burst_max' conform-action transmit exceed-action drop
для определения параметров 'burst_norm' и 'burst_max' можно воспользоваться рекомендацией:
Burst-normal = configured rate * 1/8 * 1.5 seconds
Burst-max = Burst-normal * 2
Таким образом для ограничения полосы, например, 128k получим:
rate-limit output 128000 24000 48000 conform-action transmit exceed-action drop

Включение группового чата (конференции) в Я.Онлайн

В клиенте Я.Онлайн такая функциональность заложена, но отключена. Для ее активации необходимо поправить сроку в файле /home/-user-/.yachat/profiles/default/options.xml
в теге Enable multi-user chat functionality заменим false на true, сохраняемся и при запуске клиента в настройках будет доступен пункт "Конференция" (самый верхний, жирный...).
Дальше можно подключаться к группвому чату  - да хотябы по вечерам субботы к online@conference.radio-t.com

Проблемы с вводом кирилического (русского) текста в Opera 10.60 в Ubuntu

После выхода новой Opera 10.60 в некоторых дистрибутивах, включая Ubuntu 10.04 был выявлен баг: невозможность ввода текста в кириллической раскладке (например, в строке поиска, что критично). В качестве временной меры до исправления бага (он был признан и уже поправлен) можно было воспользоваться скриптом запуска Opera:
$ vim opera-1.sh
#!/bin/bash
LANG=ru_RU.UTF-8
GTK_IM_MODULE=none
XMODIFIERS=@im=none
opera
$ sudo chmod +x opera-1.sh
После запуска Оперы этим скриптом проблема исчезала.
По информации от разработчиков данный баг был связан с тем, что в версии 10.60 некоторые компоненты были переписаны для использования Юникода в формате UTF-8, в то время, как отдельные (пострадавшие) дистрибутивы используют локаль в формате utf8 (даже при настроенных алиасах этих форматов в файле /usr/share/X11/locale/locales.alias).

Ubuntu 8.04.4 как обычный маршрутизатор (не шлюз).

Недавно возникла необходимость в виртуальном маршрутизаторе с 3мя интерфейсами, глядящими в три разные подсети. Первоначально решение вопроса казалось легким и непринужденным - прописать статические маршруты, но в процессе работы стало очевидно, что интерфесы пытаются отдать трафик через тот же интерфейс, с которого они его получили. То есть маршрутизатор не маршрутизировал.
Были сделаны такие сетевые настройки:
/etc/network/interfaces
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
        address 192.168.221.17
        netmask 255.255.255.0
        network 192.168.221.0
        broadcast 192.168.221.255
        gateway 192.168.221.253
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 192.168.221.105
        #dns-search citrix.demo
auto eth1
iface eth1 inet static
        address 192.168.223.1
        netmask 255.255.255.128
        network 192.168.221.0
        broadcast 192.168.221.127
        up route add -net 192.168.222.0/24 gw 192.168.223.10 dev eth1
auto eth2
iface eth2 inet static
        address 192.168.223.129
        netmask 255.255.255.128
        network 192.168.221.128
        broadcast 192.168.221.255
дополнительно же было необходимо раскоментировать строчку в
/etc/sysctl.conf
# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1
После этого виртуальный роутер заработал.

Базовые настройки Linksys SPA 3102/2102 с аналогового телефона (кусок мануала).

Иногда приходится сталкиваться с ситуациями, когда неизвестно, какой адрес назначен голосовому шлюзу, или его нужно оперативно сбросить к заводским настройкам, а диска с мануалом под рукой нет.
Итак - выдержки из мануала для сервисного меню:
**** - вход в режим голосового интерфейса (эти 4 "звездочки", астериска набираются в тональном режиме, поэтому для телефонов, имеющих по умолчанию настройку импульсного набора нужно будет набрать еще одну - первая переведет в тональник, остальные 4 в меню).
Женским голосом на нагицком наречии будут даваться краткие инструкции, типа, после ввода кода подтвердите "решеткой" - шарпом, также сохранение настроек - 1, иногда за основным кодом, предоставляющим выбор настройки будет следовать субкод (одноциферный).
100 - Узнать тип WAN подключения (скажут DHCP / Static / PPPoE), вообще 1хх для WAN'а
110 - проговаривается WAN IP адрес
120 - маска
130 - шлюз по умолчанию
140 - узнать mac адрес
150 - версия прошивки
160 - адрес первичного DNS
170 - номер порта для веб-морды
101 - выставить тип подключения (0 - DHCP, 1 - Static IP, 2 - PPPoE)
111 - выставить статический адрес (точки в адресе - астериском *)
121 - выставить маску
131 - выставить шлюз
161 - выставить DNS
210 - прослушать локальный адрес (2хх - для LAN сегмента)
201 - установить режим работы (0 - c NAT'ом, как маршрутизатор, 1 - мостовое соединение bridge)
7932 - доступ к настройкам извне (0 - разрешить, 1 - запретить)
732668 - ручная перезагрузка
73738 - сброс к заводским настройкам (1 - подтверждение, * - отмена)
877778 - User Factory Reset (его половой функции так и не понял - вроде бы сделать текущие настройки заводскими он не позволяет)
При выборе внешненго подключения по PPPoE - нужно быть готовым к сексу с набором имени пользователя и пароля с телефонной клавиатуры...
В качестве примера быстрая настройка шлюза для доступа на него с телефона с импульсным набором (выставляем статический адрес и даем доступ на веб интерфейс с WAN):
*****101#1#1 111#192*168*0*11#1 121#255*255*255*0#1 7932#1#1

Удаление Cisco VPN Client из Windows XP после неудачной установки.

В очередной раз убедился, что программисты в Циске не слишком внимательно относятся к разного рода апдейтам в Винде, что недавно привело к сбою в процессе установки VPN клиента на ХРюшу. Результатом был покоцанный IP стек, что решалось отключением Deterministic Network Enhancer'а. Собственно сам клиент и не думал работать - просто забивал блок памяти, а выкуривался завершением процесса. Штатным образом из Установки/Удаления программ также снести клиента не выходило - ведь установка не завершилась до конца, так этот надоедливый гад и висел в системе, через некоторое время даже сделавшись привычным. Однако, когда потребовалась переустановка Cisco Communicator'а, встала срочная необходимость прибить все Цисковкие компоненты, так как новые просто не могли установиться. Поэтому вычищаем VPN клиента из системы:
Для начала удаляем ключи реестра:
HKEY_LOCAL_MACHINE \ SOFTWARE \ Cisco Systems \ VPN Client
HKEY_LOCAL_MACHINE \ SOFTWARE \ Deterministic Networks
HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Uninstall \ {5624c000-b109-11d4-9db4-00e0290fcac5}
также проверяем другие ключи на предмет упоминания о VPN Client
HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ RunOnce \ CISCOREBOOTFLAG
Теперь удаляем некоторые каталоги и файлы (часть может оказаться заблокированной - для их удаления можно воспользоваться FAR'ом или удалить все незаблокированные, а потом прибить остальных после перезагрузки) .
?С\Program Files\Cisco Systems\VPN Client
?С\Program Files\Common Files\Deterministic Networks
?Windows\system32\drivers\dne2000.sys
?Windows\inf\dne2000m.inf и dne2000m.pnf
 ?Windows\system32\dneinobj.dll
 ?Windows\system32\drivers\cvpndrv.sys или cvpndrva.sys
переименуем файл ?Windows\system32\CSGina.dll в CSGina.old
теперь можно перезагрузиться и убедиться, что в системе больше нет Cisco VPN интерфейса.




   

Жонглирование LACP транками и Vlan на HP ProCurve.

Две модульные железки 5348XL и 5304XL, первая уже давно нагружена под завязку, а вторая до недавнего времени прохлаждалась почем зря. Итак, вводные: на 5348 несколько vlan'ов (нас интересуют vlan 6 и vlan 2 с адресами 192.168.215.110 и 192.168.221.253 соответственно), включена маршрутизация, от портов C15, C16 два шланга уходят на 5304 в порты A15, A16, есть vlan 1 с адресом 192.168.215.201 (это выянилось по CDP). Задача - составить транк для подсети 192.168.221.0/24 и присвоить 5304 адрес 192.168.221.203.
Основная проблема - сами железки далеко, а отрубить себя от второго девайса - дело одной ошибки (а тогда коммандировка неизбежна). Очевидно, что нам надо перетащить второй девайс в vlan 2.
Пока у нас нет доступа на 5304 - он виден только как CDP neighbour, перетянем порты на 5348 в 6 влан:
vlan 6
   untagged C15-C16
   ip address 192.168.215.110 255.255.255.0
теперь можем коннектиться на 5304 для настройки,
добавляем на дефолтный влан второй адрес:
vlan 1
   name "DEFAULT_VLAN"
   untagged A15-A16
   ip address 192.168.215.201 255.255.255.0
   ip address 192.168.221.203 255.255.255.0
убираем ненужный адрес (приведет к дисконнекту):
    no ip address 192.168.215.201 255.255.255.0
перекидываем на 5348 порты в vlan 2
vlan 2
   untagged С15-С16
   ip address 192.168.221.253 255.255.255.0
проверяем доступность 5304, заходим для настройки транков, основная проблема в том, что транк будет привязываться к vlan'у не как порты, а как trk# интерфейс, то есть нам сначала надо объединить порты в транк, а потом вязать с vlan. Но выянилась небольшая деталь - такую явную привязку нужно делать только для портов в активном режиме (используется LACP), а пассивные порты явным образом в trk# не вяжутся, поэтому сначала настраиваем доступный 5348:
trunk C15-C16 Trk2 LACP
vlan 2
   untagged Trk2
проверяем доступность второго девайса и заходим для настройки:
trunk А15-А16 Trk2 LACP
vlan 1
   untagged Trk2
должны (и будут) выдаваться ошибки о том, что порты уже находятся в динмической группе, но это нам и надо - это подтверждение правильности действий. Дополнительно просматриваем состояние каналов show lacp:
на 5348
   C15    Active    Trk2      Up        Yes       Success
   C16    Active    Trk2      Up        Yes       Success
на 5304
   A15    Passive   Dyn1      Up        Yes       Success
   A16    Passive   Dyn1      Up        Yes       Success