Cisco - два провайдера и ip sla / rtr

Итак, рассмотрим простой пример. Есть клиент и имеется два провайдера (аплинка). Автономной системы для построения BGP-peer'ов у нас нет, а работать, при падении одного каналов как-то надо. При этом у нас есть внутренний клиент нашей сети который работает не как все, а с точностью до наоборот. В нормальной (оба канала работают) этот клиент всё-равно ходит через резервный канал (Dialer1), в то время как все работают по основному (Dialer0) и переключается он на основной канал только в том случае если резервный(!) падает (бывает и такое).
Одно из возможных решений может выглядеть так:

interface Vlan1
ip address 192.168.0.1 255.255.255.0
ip policy route-map tracking
!
route-map tracking permit 10
match ip address 1
set default interface Dialer1 Dialer0
!
route-map tracking permit 20
match ip address 2
set default interface Dialer0 Dialer1
!
access-list 1 permit 192.168.0.101
access-list 2 deny   192.168.0.101
access-list 2 permit 192.168.0.0 0.0.0.255

Да, такая конструкция работает, но есть один недостаток, причём достаточно не очевидный.
Может наблюдаться такая ситуация, что и статус и протокол могут находиться в состоянии Up, а канал может не работать. Тогда эта конструкция ничем не поможет.
Что-же делать? Всё очень просто: использовать возможности sla.
Что нам для этого надо? Просто надо переписать route-map tracking и написать правила для sla.

interface Vlan1
ip address 192.168.0.1 255.255.255.0
ip policy route-map tracking
!
track 123 rtr 1 reachability
!
track 124 rtr 2 reachability
!
ip sla 1
icmp-echo 195.5.5.208 source-interface Dialer1
timeout 2000
threshold 2
frequency 3
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 193.34.140.1 source-interface Dialer0
timeout 2000
threshold 2
frequency 3
ip sla schedule 2 life forever start-time now
!
route-map tracking permit 100
match ip address 1
set ip next-hop verify-availability 195.5.5.208 10 track 123
set ip next-hop verify-availability 193.34.140.1 20 track 124
!
route-map tracking permit 120
match ip address 2
set ip next-hop verify-availability 193.34.140.1 10 track 124
set ip next-hop verify-availability 195.5.5.208 20 track 123
!
route-map tracking permit 200
set ip next-hop verify-availability 195.5.5.208 10 track 123
set ip next-hop verify-availability 193.34.140.1 20 track 124
!
access-list 1 permit 192.168.0.101
access-list 2 deny   192.168.0.101
access-list 2 permit 192.168.0.0 0.0.0.255

Собственно всё банально просто. ;)
route-map перестаёт отрабатывать для пакета свои правила после того как обнаружит первое-же совпадение. Поэтому, собственно, порядок определения сиквенсов важен!
Теперь если мы взглянем на состояние интерфейсов то увидим:

#sh ip int br | i ^Dialer
Dialer0                    193.34.141.151  YES IPCP   up                    up      
Dialer1                    unassigned      YES IPCP   up                    up

При этом видим, что и статус и протокол Dialer1 находятся в состоянии up, т.е. первый вариант route-map tracking не сработал бы и клиент 192.168.0.101 просто не работал бы. Но если мы взглянем на статистику по route-map tracking из второго варианта то увидим:

#sh route-map tracking
route-map tracking, permit, sequence 100
Match clauses:
ip address (access-lists): 1 
Set clauses:
ip next-hop verify-availability 195.5.5.208 10 track 123  [down]
ip next-hop verify-availability 193.34.140.1 20 track 124  [up]
Policy routing matches: 711 packets, 95929 bytes
route-map tracking, permit, sequence 120
Match clauses:
ip address (access-lists): 2 
Set clauses:
ip next-hop verify-availability 193.34.140.1 10 track 124  [up]
ip next-hop verify-availability 195.5.5.208 20 track 123  [down]
Policy routing matches: 216 packets, 14100 bytes
route-map tracking, permit, sequence 200
Match clauses:
Set clauses:
ip next-hop verify-availability 195.5.5.208 10 track 123  [down]
ip next-hop verify-availability 193.34.140.1 20 track 124  [up]
Policy routing matches: 0 packets, 0 bytes

Состояние в ip next-hop verify-availability 195.5.5.208 10 обозначено как down, а соответственно эти маршруты установлены не будут.

Всё. Вот и вся заметка. ¨Спасибы¨ принимаются в литрах ;)

Игры с xkbcomp

Господа, как же мне не нравится циклическое переключение раскладок клавиатуры. Циклически это как? Это когда за английским следует русский, за русским украинский, за украинским опять английский и т.д.
До чего-же упрощается жизнь когда привыкаешь к асимметричному переключению раскладок. Это когда переключению в каждую раскладку соответствует своя комбинация.
Например, хотите английский - нажмите CapsLock (очень часто-густо нужная клавиша, правда?), русский - Shift + CapsLock, украинский Ctrl + CapsLock. Кажется неудобным? Как бы не так! Когда привыкните - не сможете больше отвыкнуть.
Так как же это сделать в любимых X'ах? На самом деле не просто, а очень просто. Изначально, года четыре назад, я просто как обезьяна скопировал у sash-kan'а маленький keymap, которым сейчас с удовольствием готов поделиться дальше [gz, bz2, xz]:

xkb_keymap {
    xkb_keycodes { include "evdev+aliases(qwerty)" };
    xkb_geometry { include "pc(pc104)" };
    xkb_types    {
        include "complete"
        type "THREE_GROUPS" {
            modifiers = Shift+Control+Alt;
            map[None] = Level1;
            map[Shift] = Level2;
            map[Control] = Level3;
            map[Control+Shift] = Level4;
            map[Alt] = Level5;
            level_name[Level1] = "Base";
            level_name[Level2] = "Shift";
            level_name[Level3] = "Ctrl";
            level_name[Level4] = "Ctrl Shift";
            level_name[Level5] = "Alt";
        };
    };
    xkb_compatibility { include "complete" };
    xkb_symbols {
        include "pc+us+ru:2+ua:3+us(dvorak):4+level3(menu_switch)+inet(evdev)"
        replace key <CAPS>
        {
            type = "THREE_GROUPS",
            actions[Group1]=[LockGroup(group=1), LockGroup(group=2), LockGroup(group=3), LockMods(modifiers=Lock), LockGroup(group=4)]
        };
    };
};

Собственно "изюминка" тут даже невооружённым взглядом заметна. Ну и ещё. Безусловно этот конфиг в каждой секции можно дополнить другими определениями - это всего лишь обычный keymap который скармливается xkbcomp'у.
Чтобы этот конфиг отрабатывал каждый раз при входе в Ваш любимый DE, сохраните вышеприведённый конфиг, скажем, в /usr/share/X11/xkb/keymap/three_groups и нарисуйте примерно такой скрипт в /etc/X11/Xsession.d/60xkb-lang:

(
cd /usr/share/X11/xkb/ && xkbcomp keymap/three_groups $DISPLAY &>/dev/null
)

true

Маленькая заметка напоследок. Уже несколько раз при обновлении любимого Debian'а сталкивался с проблемой, что разработчики что-то переписывали-переопределяли в xkb в результате чего надо было заново и заново пытаться перелопатить конфиг в поиске нужной комбинации include в symbols. Огромное спасибо sash-kan'у который натолкнул сегодня меня на следующую мысль:

$ xkbcomp $DISPLAY - | less

Просто сегодня в очередной раз обновился и с расстройством обнаружил, что у меня не отрабатывают клавиши Up, Down, Left, Right, Home и т.д. когда компилится вышеуказанный keymap. Но при этом великолепно работают при, так сказать, установках "по-умолчанию" в Gnome. Простая командочка:

$ xkbcomp $DISPLAY - | egrep "^xkb_"

позволила увидеть искомую комбинацию для include. Моему счастью не было предела! ;)
Ну, собственно, на этой оптимистической нотке эту заметку можно и закончить :)

Поиск производителя по mac-адресу

http://www.coffer.com/mac_find/
Ethernet Vendor Code Lookup Tool

Поиск по имени производителя. Например: "apple" or "allied"
Поиск по MAC-адресу. Например: "00:13:A9" or "00-80-C7" or "000420"

Если Вы видите MAC-адрес "08:00:69:02:01:FC", введите первые три байта "08:00:69", или полный MAC-адрес "08:00:69:02:01:FC".

Производителя "железа" определяют именно первые три байта!

Репликация Master-Slave в MySQL

Оригинал нижеприведённой статьи смотрим тут http://www.webnext.ru/blog/2007/08/21/replication-mysql-master-slave.html, а тут я просто себе её скопипастил, как "хозяйке на заметку" :)

Репликация позволяет решать несколько очень важных задач — это повышение доступности и надёжности хранения данных. Начиная с версии 4.1.13 MySQL поддерживает кластеризацию. Итак, что даёт нам репликация?

1. Резервное копирование в режиме online.
2. Высокая надёжность хранения данных. Если один сервер по каким либо причинам повредился и данные потерялись, то у нас всегда будет зекрало базы.
3. Высокая доступность системы. В случае, если один сервер перестал работать, мы может переключить наших клиентов на другой сервер, туда, куда призводилась репликация.
4. Масштабирумость системы. Это отдельный разговор, его мы как нибудь затронем, но с помощью разных видов репликаций можно достигать почти горизонтальной масштабируемости, когда при N увеличении компьютеров в вашем кластере, скорость работы вашего сервиса увеличивается “почти” в N раз. Я говорю почти, потому что кроме самой базы данных, ещё много других “бутылочных горлышек” и связывающий канал между вашими серверами — тоже отдельная песня.

Терминология

Репликация — процесс копирования данных одной БД между другими БД. Master Server — Главный сервер, с которого производиться копирование. Slave Server — Подчинённый сервер, на который, производиться копирование данных.

Что нам нужно

Один master сервер и один slave-сервер. Все изменения на master-сервере будут синхронизироваться на slave сервер.

Как это работает

Slave-сервер с определённой периодичностью будет опрашивать master-сервер на предмет изменений в базе. Таким образом все изменения в master-сервере будут повторяться на slave-сервере. Таким образом создаётся избыточность данных на двух серверах и тем самым достигается высокая доступность и надёжность данных. Важным преимуществом между “холодным копированием” заключается в том, что мы переносим по сети только изменения, а не все данные каждый раз. Тем более не стоит забывать что во время создания backup`а мы нагружаем наш master-сервер. Здесь же всё иначе, master-сервер все изменения в базе пишет в “бинарный журнальный лог”, присваивая каждой операции номер. Когда slave-сервер обращается к нашему главному серверу, то он сообщает номер последней операции, которую он уже произвёл у себя и получает все новые изменения отсчитывая от этого номера.

Настраиваем

Первым делом надо включить “Бинарный журнал” на master-сервере. Это файл, в котором регистрируются все изменения данных. Однако, опреаторы update и delete, которые не затронули ни одной строки — регистрироваться в журнале не будут. Включение журнала немного понижают общую производительноть базы, но не сильно, примерно на 1%. Зато, в случае падения базы, этот журнал используется для “автоматического восстановления после сбоя”. Для включения этого журнала отредактируем конфигурационный файл (у меня в Gentoo Linux это /etc/mysql/my.cnf)

log-bin = my-bin

my-bin в данном случае — это имя файла бинарного лога. В ходе работы базы в папке с данными (у меня это /var/lib/mysql) будут создаваться файлы my-bin.000001, my-bin.000002 и так далее, при каждом старте базы, будет создан новый файл. Вместе с этим будет создан файл my-bin.index в котором будут перечислен список всех бинарных логов. Продолжим настройку нашего главного сервера, добавим следующие строки:

server-id = 1
slave-compressed = 1
binlog-do-db = mydb

server-id является обязательным параметром, это идентификатор базы, пускай будет 1, каждый сервер в схеме репликаций должен иметь уникальный номер. На slave-сервере мы укажем server-id=2. slave-compressed я включил, потому что мой slave-сервер находиться не “рядом” и передача идёт по сети, в этом случае можно повысить скорость и разрешить сжимать поток. bin-do-db — необязательный параметр, позволяет указать изменения какой именно базы будет писаться в бинарный журнальный лог. Создадим отдельную учётную запись на головном сервере c привилегиями REPLICATION SLAVE, SELECT, RELOAD, SUPER. При создании учётной записи не забудьте правильно указать “Хост”. Например, если все наши slave-сервера находятся в зоне webnext.ru то мы можем ограничить доступ как ‘%.webnext.ru’. Перед запуском подчинённого (slave) сервера, на нём необходимо разместить полную копию данных главного (master) сервера. Задача состоит в том, что на головном сервере необходимо сделать дамп базы в режиме блокировки на запись. И пока делается дамп необходимо узнать номер журнала и смещение от начала файла. Для этого выполните запрос:

SHOW master STATUS;

В столбце File указано имя текущего журнального файла, а в столбце Position — смещение относительно начала файла. Эти значения представляют собой координаты, с которых подчинённому серверу следует получать новые изменения. Далее на slave-сервере следует выполнить следующую sql-команду.

CHANGE master TO master_host = 'master_host', master_user = 'user'. master_password = 'password', master_log_file = 'log_file', master_log_pos = log_pos;

Тут master_host — хост или ip главного (master) сервера с которого мы делаем репликацию. user и password — имя пользователя, которого мы завели специально для репликаций и его пароль. log_file и log_pos — имя текущего журнального файла на главном сервере и смещение от начала файла, эти поля мы получили выше с главного (master) сервера. И последнее что осталось, это запустить на подчинёном сервере процесс репликации, это делается sql-командой.

start slave;

Тест на знание интернет-сленга

Узнай, насколько ты в теме языка российских интернетов?

Настройка сети VirtualBox через хост-интерфейс

~$ sudo aptitude install uml-utilities bridge-utils
~$ sudo tunctl -t tap2 -u olden
Set 'tap2' persistent and owned by uid 1000
~$ sudo brctl addbr br1
~$ sudo ip a a 192.168.0.1/24 brd 192.168.0.255 dev br1
~$ sudo brctl addif br1 tap2
~$ sudo ip l s dev br1 up
~$ sudo ip l s dev tap2 up
~$ ip a s dev br1
5: br1:  mtu 1500 qdisc noqueue state UNKNOWN
link/ether 2e:82:c1:77:9d:83 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.1/24 brd 192.168.0.255 scope global br1
~$ ip a s dev tap2
4: tap2:  mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
link/ether 2e:82:c1:77:9d:83 brd ff:ff:ff:ff:ff:ff

Получаем:

• br1 - интерфейс для связи с виртуальной машиной
• tap2 - интерфейс на виртуальной машине (выбираем в свойствах сети виртуальной машины)

Дальше, как обычно, настраиваем фильтрацию через iptables ;)

$ sudo iptables-save | fgrep "192.168.0.0"
-A POSTROUTING -s 192.168.0.0/24 -o vlan8 -j MASQUERADE
-A FORWARD -s 192.168.0.0/24 -i br1 -o vlan8 -j ACCEPT

Как быстро поменять тип таблиц в базе MySQL

Собственно я так и не обнаружил как сказать MySQL чтобы он по умолчанию создавал таблицы типа InnoDB. Поэтому не мудрствуя лукаво быстренько "на коленке" накатал следующий скрипт:

MYSQL='mysql -uusername -ppassword database'
echo "show tables" | \
$MYSQL | \
awk 'BEGIN { n=1}
n==0 { printf("ALTER TABLE %s ENGINE=InnoDB;\n", $1) }
n==1 { n=0 }' | \
$MYSQL

Дёшево и сердито! ;)
Ну и конечно-же всё это можно уместить в одну строчку и даже можно попытаться алиас создать.

alias mysqlmoddb='echo "show tables" | $MYSQL | awk '\''BEGIN { n=1} n==0 { printf("ALTER TABLE %s ENGINE=InnoDB;\n", $1) } n==1 { n=0 }'\'' | $MYSQL'

Тогда достаточно будет лишь менять значение переменной MYSQL, примерно так:

$ MYSQL='mysql -uroot mysql'
$ mysqlmoddb