Cisco Frame Relay switching Connect feature.

В процессе изучения Frame Relay технологии попробовал сэмулировать сеть с парой FR свичей и 4мя клиентами (3 спока завязываются на хаб). Ниже схема включения (использовался IOU v3 от flyxj.cn):

Шнурки между двумя Frame Relay Switch'ами (FRS1 / 2) объединены в Multilink Frame Relay интерфейс - MFR0. Рутер R01 - хаб.
Получилось примерно так:
FRS1
FRS1:
interface MFR0
 no ip address
 encapsulation frame-relay IETF
 no keepalive
 frame-relay lmi-type ansi
 frame-relay intf-type nni
!
interface Serial2/0
 no ip address
 encapsulation frame-relay MFR0
 serial restart-delay 0
 no arp frame-relay
!
interface Serial2/1
 no ip address
 encapsulation frame-relay MFR0
 serial restart-delay 0
 no arp frame-relay
!
interface Serial2/2
 no ip address
 encapsulation frame-relay IETF
 serial restart-delay 0
 frame-relay lmi-type ansi
 frame-relay intf-type dce
!
interface Serial2/3
 no ip address
 encapsulation frame-relay IETF
 serial restart-delay 0
 frame-relay lmi-type ansi
 frame-relay intf-type dce
!        
connect R01-CE1 Serial2/2 102 Serial2/3 203
connect R1-CE2 Serial2/2 108 MFR0 207
connect R1-R6 Serial2/2 106 MFR0 702
---
FRS2:
interface MFR0
 no ip address
 encapsulation frame-relay IETF
 no keepalive
 frame-relay lmi-type ansi
 frame-relay intf-type nni
!
interface Serial2/0
 no ip address
 encapsulation frame-relay MFR0
 serial restart-delay 0
 no arp frame-relay
!
interface Serial2/1
 no ip address
 encapsulation frame-relay MFR0
 serial restart-delay 0
 no arp frame-relay
!
interface Serial3/0
 no ip address
 encapsulation frame-relay IETF
 serial restart-delay 0
 frame-relay lmi-type ansi
 frame-relay intf-type dce
!
interface Serial3/2
 no ip address
 encapsulation frame-relay IETF
 serial restart-delay 0
 frame-relay lmi-type ansi
 frame-relay intf-type dce
!
connect CE2-R1 Serial3/2 708 MFR0 207
connect R6-R1 Serial3/0 607 MFR0 702
По уму, здесь нужно поменять serial интерфейсы к клиентам (которые inf-type dce) на субинтерфейсы и включить clock rate, ну да задача была разобраться в connect feature...

JunOS Olive установка в Virtual Box, апгрейд.

На просторах Интернета полно статей по установке JunOS поверх фряхи.
Например, полезняшки здесь:
http://habrahabr.ru/post/111974/
здесь:
http://pauldotcom.com/2011/05/virtualizing-junos-on-vmware.html
здесь:
http://www.packetmischief.ca/2011/03/24/installing-olive-10-4r1-under-vmware/
и, конечно, здесь:
http://juniper.cluepon.net/index.php/Olive
В целом, алгоритм ясен:
- ставим фряху с большим разделом /var,
- достаем в "труднодоступных" местах jinstall-xxx.tgz,
- распаковываем и правим ряд параметров,
- пакуем с правками тарболл взад и,
- ставим во фре, как обычный пакет pkg_add.
В процессе изучения сабжа выяснилось несколько моментов:
- не каждая фряха одинаково полезна, наилучшие результаты достигались на версии 4.11 (это при живущей уже 9ке!),
- вопреки расхожему мнению, jinstall тарболл извлекается и из iso'шников,
- патчить / править тарбол можно на любой машине, где есть tar.
Начнем с подготовки виртуалки:
- выделяем 768Мб ОЗУ,
- выделяем IDE хард на 6Гб,
- отключаем звук, USB,
- создаем serial host pipe для COM1, пусть на /tmp/junos9com1
Собственно, скопипастенные действия для JunOS 9.6:
cd /var/tmp
mkdir jinst ; cd jinst ; tar xvzf ../jinstall-9.6R1.13-domestic-olive.tgz
# rm *.md5 *.sha1 *.sig
mkdir domestic ; cd domestic ; tar xvzf ../jbundle-9.6R1.13-domestic.tgz
rm *.md5 *.sha1 *.sig
mkdir pkgtools ; cd pkgtools ; tar xvzf ../pkgtools.tgz
cd pkg ; rm *.md5 *.sha1 *.sig ; cd ..
все распаковано и все контрольные суммы прибиты, теперь подменяем скрипт проверки (обращение будет возвращать код true)
cp /usr/bin/true bin/checkpic
пакуем все обратно, стирая созданные каталоги:
tar cvzf ../pkgtools.tgz *
cd .. ; rm -rf pkgtools
tar cvzf ../jbundle-9.6R1.13-domestic.tgz *
cd .. ; rm -rf domestic/
tar cvzf ../jinstall-9.6R1.13-domestic-no-checkpic.tgz *
cd .. ; rm -rf jinst/
В результате получаем тарболл jinstall-9.6R1.13-domestic-no-checkpic.tgz, который и будет установлен:
pkg_add jinstall-9.6R1.13-domestic-no-checkpic.tgz
перезагружаемся - reboot, параллельно можно открыть консольный вывод, чтобы видеть процесс установки JunOS, или, как рекомендуемый вариант, поправим запись:
chmod +w /boot/loader.conf
vi /boot/loader.conf
находим запись console="comconsole" и исправляем ее на
    console="vidconsole"
если этого параметра нет - просто дописываем в конец файла и сохраняем.
Да, консольный вывод (используя socat), мне нравится такой вариант:
screen sudo socat /tmp/junos9com1 -
После всех проделанных процедур, получаем виртуальный рутер с ПО для Juniper M / T / MX Series.
В данной серии оборудования функционал распределяется по аппаратным модулям, ОС же играет роль центра управления, так что огромное количество фич будет не доступно, например, для работы NAT необходим service-interface (sr-0/0/0.0). Без него настройки NAT просто не применятся, кстати, в данной серии девайсов настройка NAT осуществляется через edit services nat.
Пошарив по задворкам тырнета наткнулся на пару утверждений, что для Оливки самый правильный JunOS - тот, который для J-Series (JSR?) рутеров - типа там у них все софтово творится, так что на эмуляторе пойдет кучеряво.
Надыбал  junos-jsr-10.3R1.9-domestic.tgz, который сам по себе на фряху не ставится, но им можно проапгрейдить имеющийся 9.6 JunOS.
Правим тарбол практически аналогично, с добавками (для 10й и старших версий) - везде, где видим файлы +INSTALL и +REQUIRE находим в них строки проверки архитектуры и подменяем (в vi):
check_arch_compatibility()
{
    #re_name=`/sbin/sysctl -n hw.re.name 2>/dev/null`
    re_name='olive'
    if [ -z "$re_name" ]; then
        Error "hw.re.name sysctl not supported."
    fi
комментируем строку re_name... и создаем свою с именем "olive", сохраняем все правки и пакуем обратно.
Теперь процедура обновления, в моем случае, патченный тарболл находится на локальном ftp серваке, так из cli выполняем:
request system software add unlink no-copy ftp://_username_:_password_@_ip_ftp_server_/Software/Juniper/junos-jsr-10.3R1.9-domestic-patched.tgz
Дожидаемся примерно таких строк:
JUNOS 10.3R1.9 will become active at next reboot
cat: /packages/junos-10.3R1.9-domestic.sha1: No such file or directory
Saving state for rollback ...
Removing /var/tmp/junos-10.3R1.9.tgz
и перезагружаем виртулку:
request system reboot
Новый рутер начал определяться уже как J4300, однако при настройке NAT (эта проверка настоятельно рекомендуется тем, кто планирует использовать сабж, как пограничное устройство), опять постиг облом:
error: usp_ipc_client_open: failed to connect to the server after 1 retries
поиск по ошибке указал на то, что в девайсе не хватает модуля, что проверка шасси и подтвердила:
show chassis fpc             
                     Temp  CPU Utilization (%)   Memory    Utilization (%)
Slot State            (C)  Total  Interrupt      DRAM (MB) Heap     Buffer
  0  Empty          
  1  Empty          
  2  Empty          
  3  Empty          
  4  Empty          
  5  Empty          
  6  Empty          
Кстати, здесь NAT настраивается через edit security nat...

Привилегированный доступ к машинам Virtual Box для подключения к среде GNS3

Для создания интерфейсов подключения GNS3 запускается с правами суперпользователя (параметры запуска предваряются вариантом sudo для графических приложений - gksudo /home/_username_/GNS3-0.8.2-BETA-src/gns3.pyw). Аналогично для подключения vbox хостов приложению Virtual Box также необходимо запускаться через gksudo, при этом, файл со списком настроенных виртуалок будет использовать путь /root/.VirtualBox/VirtualBox.xml, то есть при старте мы не увидим ни одной машины. Для исправления:
бэкапим существующий файл
sudo cp /root/.VirtualBox/VirtualBox.xml /root/.VirtualBox/VirtualBox.xml.backup
копируем не-sudo файл )из домашнего каталога
sudo cp /home/_username_/.VirtualBox/VirtualBox.xml /root/.VirtualBox/VirtualBox.xml
Теперь, машины, созданные не с использованием путей по-умолчанию, будут полностью доступны и работоспособны, а те, что создавались с дефолтными параметрами, будут ссылаться на конфиги и vHHD в каталогах
src="Machines/_виртуалка_", эти сокращенные пути по факту: /home/_username_/.VirtualBox/Machines/, так что это необходимо поправить в файле
sudo vim /root/.VirtualBox/VirtualBox.xml
в разделе MachineRegistry

Virtual Box ошибка выключения и запуск в среде GNS3

При использовании Oracle Virtual Box версии 4.1.8 было замечено два глюка:
1. при выключении питания, если в работе использовались виртуалки с vboxnetX адаптерами, это выключение замораживалось с ошибкой unregister_netdevice waiting for vboxnetX to become free
2. при тестировании подключения виртуальных машин Virtual Box в среде GNS3 выдавалась ошибка vboxapi module cannot be loaded
Обе эти проблемы решались сначала полным удалением существующего приложения (4.1.8) и новой установкой пакета версии 4.1.20, собранного конкретно под текущую версию ОС - не All distributions! В моем случае, это пакет для Ubuntu 12.04 LTS ("Precise Pangolin")  i386 (http://download.virtualbox.org/virtualbox/4.1.20/virtualbox-4.1_4.1.20-80170~Ubuntu~precise_i386.deb).
В результате 1й глюк успешно побеждается, 2й же немного видоизменяется - при тесте выдается ошибка failed to start xdotool, но это чинится установкой этих самых тулзов:
sudo apt-get install xdotool

Применение патча 0029-Integrating-Dynamips-and-GNS3-UDP-tunnels-Patches.patch для QEMU 1.0 в Ubuntu 12.04

Без данного патча подключить в GNS3 (в моем случае это версия GNS3-0.8.2-BETA) такие полезняшки как Cisco ASA и JunOS (Olive) router можно, но сложно. На просторах Интернета куча статей и HowTo по данному вопросу, однако коротко и ясно все решение было изложено у коллеги: http://kaktyc.wordpress.com/2012/05/18/запуск-qemu-хоста-в-gns3/.
В процессе использования приведенных инструкций проявилась и парочка граблей. В целом, порядок действий такой:
- выделяем каталог под сборку пакета - mkdir gns3-qemu
- проверяем версию QEMU на нашей машине (грабли №1 - нужна версия 1.0)
стоит обратить внимание, что просто команды qemu (как было раньше) уже нет, варианты:
qemu [Tab]
qemu-ga             qemu-ifup           qemulator           qemu-system-i386   
qemu-i386           qemu-img            qemu-launcher       qemu-system-x86_64 
qemu-ifdown         qemu-io             qemu-nbd            qemu-x86_64
$ qemu-i386 -version
qemu-i386 version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard
$ qemu-system-i386 -version
QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard
Если версия ниже - необходимо проапгрейдиться до 1.0, для "правильной" версии устанавливаем девелоперские инструменты и сорцы,
- sudo apt-get build-dep qemu-kvm ,
- apt-get source qemu-kvm ,
- благодаря ссылке коллеги kaktyc'а о том, что Gentoo'шный патч подходит, качаем его:
wget -c http://dev.gentoo.org/~lu_zero/distfiles/qemu-1.0-patches.tar.xz
там также есть патчи qemu-1.1.0-patches.tar.xz и qemu-1.1.0-r1-patches.tar.xz - более поздние, но они нам не подходят,
- распаковываем и применяем нужный патч на сорцы:
tar xvJf qemu-1.0-patches.tar.xz
 cd qemu-kvm-1.0+noroms/
 patch -p1 < ../patches/0029-Integrating-Dynamips-and-GNS3-UDP-tunnels-Patches.patch
- теперь создаем deb пакет с примененным патчем:
dpkg-buildpackage -b -uc -nc -j4
- в результате будут созданы два! deb пакета (в моем случае, архитектуры i386, у коллеги amd64):
qemu_1.0+noroms-0ubuntu14.1_i386.deb и qemu-kvm_1.0+noroms-0ubuntu14.1_i386.deb
Первый содержит:
dpkg --contents qemu_1.0+noroms-0ubuntu14.1_i386.deb
drwxr-xr-x root/root         0 2012-09-02 00:55 ./
drwxr-xr-x root/root         0 2012-09-02 00:55 ./usr/
drwxr-xr-x root/root         0 2012-09-02 00:55 ./usr/share/
drwxr-xr-x root/root         0 2012-09-02 00:55 ./usr/share/doc/
drwxr-xr-x root/root         0 2012-09-02 00:55 ./usr/share/doc/qemu/
-rw-r--r-- root/root     19020 2012-09-02 00:48 ./usr/share/doc/qemu/changelog.Debian.gz
-rw-r--r-- root/root      4079 2012-09-02 00:48 ./usr/share/doc/qemu/copyright
то есть только раздел doc, а вот второй:
dpkg --contents qemu-kvm_1.0+noroms-0ubuntu14.1_i386.deb
...
drwxr-xr-x root/root         0 2012-09-02 00:55 ./usr/bin/
-rwxr-xr-x root/root     13720 2011-12-04 14:38 ./usr/bin/kvm_stat
-rwxr-xr-x root/root    987712 2012-09-02 00:55 ./usr/bin/qemu-i386
-rwxr-xr-x root/root    416616 2012-09-02 00:55 ./usr/bin/qemu-io
-rwxr-xr-x root/root   1164148 2012-09-02 00:55 ./usr/bin/qemu-x86_64
-rwxr-xr-x root/root   3734788 2012-09-02 00:55 ./usr/bin/qemu-system-x86_64
-rwxr-xr-x root/root   3566468 2012-09-02 00:55 ./usr/bin/qemu-system-i386
-rwxr-xr-x root/root    124552 2012-09-02 00:55 ./usr/bin/qemu-ga
...
Его-то нам и нужно установить:
- sudo dpkg -i qemu-kvm_1.0+noroms-0ubuntu14.1_i386.deb
В результате патч применится.
Непосредственно в самом GNS3 для запуска QEMU в разделе Edit / Preferences / Qemu / General Settings / Path to Qemu указываем не просто qemu, а qemu-system-i386 (Грабли №2).
Теперь тест - Test Settings пройдет успешно.

Проброс портов через SSH Линукс клиентом и Putty

В мемориз.
В "родном" Linux ssh client делается так:
ssh -L 44433:192.168.75.2:443 -L 54433:192.168.75.200:443 -L 43389:192.168.75.4:3389 username@ssh_gateway -N
в данном случае это не только port-forward, но еще и port-trigger (позднее мы будем коннектиться на localhost по портам, первым в записях -L).
В Putty похожее также реализовано (например, здесь: http://www.virtuallifestyle.nl/2010/03/tunneling-a-vsphere-client-connection-over-ssh/ отличное описание проброса нужных портов для VMWare Client'а с учетом того, что конкретно VMWare клиенту не следует устанавливать переключение портов - port-trigger, так как ему нужны свои родные порты 443,902 и 903). В целом, для Putty действия такие:
- новая ssh сессия (Session) - указываем ssh хост (будет ssh gateway),
- в разделе Connection / SSH / Tunnels / Add new forwarded port: указываем Source Port как Local (можно также указать, что он IPv4 или оставить Auto), в Destination Указываем адрес и порт на которые нужно будет пробросить коннекшен вида ip_server:port,
- добавляем Add это в таблицу Forwarded Ports,
- можно вернувшись в раздел Session сохранить (поименовав) ее.

Создание ярлыков запуска (Launcher'ов) в Ubuntu 12.04 с Gnome Shell

В мемориз.
В Ubuntu 12.04 (даже с Gnome Shell'ом) создание Launcher'ов по контекстному меню больше не работает, на рабочем столе из него можно только создавать файлы/папки, да "копипастить" всякое. Теперь эта ланчеры создаются в приложении alacarte (sudo apt-get install alacarte) - оно же Applications / System Tools / Preferences / Main Menu
Там создаем новый item, а дальше все как на обычном Launcher'е.