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".

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