Отсутствие BGP маршрутов на CE (Customer / Client Edge) маршрутизаторах при стыке CE-PE по eBGP и одной AS для клиентских филиалов.

При использовании MPLS VPN, одним из наиболее эффективных стыков провайдерских роутеров с клиентскими, является использование протокола BGP. Так клиенту выдается частная автономка и он импортирует свои маршруты в выделенный ему VRF. Данный стык подразумевает поддержку протокола BGP на пограничном оборудовании клиента, что можно считать минусом, однако в плюсе - отсутствие редистрибуции (золотое правило сетевика гласит, что редистрибуции маршрутов следует избегать, особенно двусторонней) и "прозрачность" настройки и вероятного траблшутинга. Есть только одни грабли: протокол BGP для предотвращения петель маршрутизации не примет от eBGP пира апдейты со своим номером автономки, а это именно тот случай, когда филиалы с одинаковыми частными номерами AS взаимодействуют с провайдерской сетью с другим номером AS, то есть являются eBGP соседями. Для решения этой проблемы при настройке MP-BGP раздела VRF нужно использовать опцию as-override:
router bgp _AS_
...
address-family ipv4 vrf _CLIENT1_
...
neighbor _ip_addr_ as-override
---
Теперь номера AS в апдейтах на границах CE-PE будут перезаписываться PE маршрутизаторами и приниматься CE.
Описание этой фичи:
http://fengnet.com/book/ios_mpls/ch06lev1sec1.html
https://supportforums.cisco.com/docs/DOC-21837

Управление через SSH хостов виртуалок на VMWare vSphere 5>

Для получения нормального управления хостом виртуалок из консоли (SSH), делаем следующее:
из скачанного и установленного vSphere Client, заходим в Configuration / Software / Security Profile
жмем Properties и стартуем сервисы:
ESXShell
SSH
Direct Console UI
Теперь заходим под root'ом на менеджмент интерфейс.
Полезные команды:
esxcli
dcui
последняя дает доступ к интерфейсному меню, аналогичному тому, что выдается при локальном подключении (снова заходим по F2 под root'ом и меняем, что нужно).
P.S. Да, для старта сервисов в maintenance mode входить не нужно!

Полезняшка. SSH клиент в браузере - GateOne

По наводке продвинутых людей заценил эту штукенцию:
http://liftoff.github.com/GateOne/About/index.html
для скачивания: https://github.com/downloads/liftoff/GateOne/gateone_1.0-2_all.deb
Предварительно на Debian/Ubuntu нужно поставить пакет python-support, который подтянет необходимый фреймворк - python-tornado
sudo apt-get install python-support
проверяем версии зависимых пакетов:
python -V
python -c "import tornado; print(tornado.version)"
ставим сам gateone:
sudo dpkg -i gateone_1.0-2_all.deb
после установки запускаем (для теста стартовал без аутентификации):
sudo /opt/gateone/gateone.py
при старте будут созданы необходимые каталоги и файл конфигурации, доступ на клиента https://_адрес_хоста_
Из Opera не особо работает, а из Firefox и Chrome завелся.

Уже не новая нумерация BGP AS - автономных систем 32-битная

Документ: http://tools.ietf.org/html/rfc4893
Сейчас практически на всем новом оборудовании номера автономок 32-битные (вместо ранее использовавшихся 16-битных с приватными номерами от 64512 до 65535). Используется все это ажно с 2008 года.
О правилах передачи номеров в атрибутах апдейтов:
...
4.1. Interaction Between NEW BGP Speakers

A BGP speaker that supports 4-octet Autonomous System numbers SHOULD
advertise this to its peers using the BGP Capability Advertisements.
A BGP speaker that advertises such capability to a particular peer,
and receives from that peer the advertisement of such capability MUST
encode Autonomous System numbers as 4-octet entities in both the
AS_PATH and the AGGREGATOR attributes in the updates it sends to the
peer, and MUST assume that these attributes in the updates received
from the peer encode Autonomous System numbers as 4-octet entities.

The new attributes, AS4_PATH and AS4_AGGREGATOR SHOULD NOT be carried
in the UPDATE messages between NEW BGP peers. A NEW BGP speaker that
receives the AS4_PATH and AS4_AGGREGATOR path attributes in an UPDATE
message from a NEW BGP speaker SHOULD discard these path attributes
and continue processing the UPDATE message.

4.2. Interaction Between NEW and OLD BGP Speakers

4.2.1. BGP Peering

Note that peering between a NEW BGP speaker and an OLD one is
possible only if the NEW BGP speaker has a 2-octet AS number.
However, this document does not assume that an Autonomous System with
NEW speakers has to have a globally unique 2-octet AS number --
AS_TRANS could be used instead (even if a multiple Autonomous System
would use it).
...
Из настроек Циски:
hostname (config)#router bgp ?
<1-4294967295> Autonomous system number
<1.0-XX.YY> Autonomous system number
Про записи второго asdot вида рассказывают тут: http://tools.ietf.org/html/rfc5396

Полезняшка. SSH/Telnet клиент с табами и настройкой copy/paste как в виндовом Putty

Давно искал под Ubuntu SSH клиента с функционалом, близким к виндовому Putty Connection Manager. То есть интересовало наличие табов с возможностью сохранить конекшены и копирование выделением мышью и вставка правой клавишей. Такая прога нашлась (я только что о ней узнал...): gnome-connection-manager
http://kuthulu.com/gcm/gnome-connection-manager_1.1.0_all.deb
Затачивается под себя в лучшем виде!

Появление новых интерфейсов ethN при смене MAC адресов

При миграции или перемещении виртуальной машины (в моем случае под Virtual Box) при ее старте в логах присутствуют сообщения вида:
dmesg | grep network
udev[xxx]: renamed network interface eth0 to ethN
Это происходит по причине привязки MAC адреса виртуальной сетевухи к номеру интерфейса. Также, так как IP адреса назначены на "старые" интерфейсы (eth0, eth1...), то новосозданные eth2... без сетевых настроек.
Для решения этой проблемы редактируем файл
sudo vim /etc/udev/rules.d/70-persistent-net.rules
Исправляем мак-адреса интерфейсов для нужных eth0/eth1, пользуясь новыми записями (ниже в файле), а эти новые записи затираем:
...
# PCI device 0x1022:0x2000 (pcnet32)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:27:4a:90:da", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
...
# PCI device 0x8086:0x1004 (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:27:84:48:e3", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
...
Жирным выделены МАСи, которые нужно "махнуть не глядя", а вторую запись потом удалить.

Протокол ISIS на SVI интерфейсах - ошибка вида CLNS-3-BADPACKET: ISIS: LAN Ln hello, packet (xxxx) or wire (yyyy) length invalid from

При активации динамического протокола маршрутизации на SVI интерфейсах L3 коммутаторов (catalyst 3750 >), из-за разницы в MTU для адресации CLNS и IP, состояние смежности не устанавливается с появлением сообщения об ошибке вида:
CLNS-3-BADPACKET: ISIS: LAN Ln hello, packet (xxxx) or wire (yyyy) length invalid from _mac_addr_...(SVI)
Данное сообщение рассматривалось в багтраке Циско:
http://www.cisco.com/en/US/docs/ios/12_2sr/release/notes/122SRcavs2.html
с советом:
CSCtk47960
Symptoms: Large CLNP packets may be dropped when forwarded over SIP- 200/Flexwan2 module. Header Syntax errors may be recorded on receiving host.
Remote side will generate the following:
%CLNS-3-BADPACKET: ISIS: L1 LSP, packet (902) or wire (896) length invalid
Conditions: This symptom is seen on Cisco 7600 switch with SIP-200 line card that is running Cisco IOS 12.2(33)SRD3 and later releases.
Issue is seen when packets larger than 911 bytes are sent (Payload and Header).
Workaround: If CLNS is only used for ISIS neighborships "no isis hello padding" can be configured to establish ISIS neighborship. For the LSP packets, configure lns-mtu 903 under router isis on the Cisco 7600 to make this work.
По факту для решения: не отключаем
router isis
 hello padding
Проверим размер MTU для CLNS:
show clns int vlan N
обычно по-умолчанию используется размер пакета 1497, для IP MTU по-умолчанию 1500.
Чтобы не было проблем с установлением смежности (ISIS использует для этого настроенный NSAP адрес), выравниваем оба MTU и активируем протокол на SVI интерфейсе:
interface vlan 2
 clns mtu 1400
 ip mtu 1400
 ip router isis
В результате получаем новые записи в таблице маршрутов.