Самый первый ГАВ!

Этот пост первый, он будет висеть всегда на высоте, пополнятся.
Постараюсь сделать это место как можно уютнее.
Основные тематики блога:

• Сети и системы связи (всё с чем сталкиваюсь на работе, будет тут)
• Программное обеспечение начиная от ОС, до прикладного ПО
• Литература (впечатления, пожелания, советы)

В данный момент переношу технику из ЖЖ

FTP over NAT (Cisco asa)

Приветствую!
Недавно имело место очередное приключение, а именно решение проблемы с ftp сессиями проходящими через nat организованный на cisco asa.
В общем и целом симптомы выглядели примерно так:
500 Illegal PORT command.
Данное сообщение повествует о том что data plane в ftp сессии не сработал.
Иными словами произошло следующее:
После установки TCP соединения клиента на 21 порт сервера, передачи пары логин/пароль, происходит выбор режима передачи из 2х доступных:
- ascii
- binary
/Не будем погружаться в разницу между двумя режимами передачи/
Далее двум системам надо определить порты для передачи самих данных т.е. 21 порт это control plane а определение data plane только начинается. Существует команда port она принимает следующее значение:
клиент сообщает серверу адрес и порт на котором он ждет данные:
port 192,168,0,2,42,23
В примере адрес 192.168.0.2 порт 4223.
Но тут происходит интересная череда событий, asa которая стоит на границе получив пакет предназначенный для ftp сервера и содержащий в себе команду port отправляет его серверу, но соответствующую трансляцию о канале передачи данных не создает, сервер получив команду от клиента начинает слать данные на указанный в команде адрес и порт, листинг домашней директории, и т.д. asa отбрасывает пакеты пришедшие к ней для клиента т.к. записи о сеансе трансляции нет.
Получилось так:
- соединение есть, но данные не идут.
Что надо сделать, что бы всё вернулось на круги своя? Правильно, заставить asa разбирать пакеты не только на 3/4 уровне, а еще и на 7 заглядывать, и на основании данных которыми перестреливаются клиент/сервер подстраивать работу nat.
Как это сделать? Просто:
/Кусочек конфига для Cisco ASA/PIX (PIX/ASA OS ver. > 7.0)/

class-map ftp
description "FTP inspection"
match port tcp eq ftp
!
policy-map type inspect ftp ftp-inspection
parameters
mask-banner
mask-syst-reply
match request-command help
reset
!
policy-map outside_protection
class ftp
inspect ftp strict ftp-inspection
set connection conn-max 1500
!
service-policy outside_protection interface outside
Вот и весь секрет.

IOS Reality

Странно, но качество ОС IOS на мой взгляд начало сильно страдать, вот примеры того с чем я столкнулся:
1) При настройке iBGP между двумя directly connected neighbors, процесс rib update занимал 90% процессорного времени, что влияло на устойчивость сегмента сети. Проблема была в следующем:
при поступлении внешних маршрутов от пира где задействован eBGP, роутер пытался сопоставить next-hop address полученного префикса по таблице маршрутизации и находил там только default route.
т.е. iBGP сообщает:
125.11.24.0/24 next-hop 217.12.240.2
В таблице машрутизации:
271.12.240.2 --> 0.0.0.0/0 - 89.107.24.1 (условный next-hop пира)
Тут происходило обновление FIB, которая разлеталась в "кровавые ошметки", и маршрутизатор честно уходил в перезагрузку
Решение: на пире с eBGP сессией установить next-hop-self в сторону iBGP соседа тогда процесс поиска узла следующего перехода и инсталяция маршрута в global routing table проходит нормально т.к. next-hop есть в таблице маршрутизации явно а не в виде 0/0.
IOS 12.4.20T
2) Оказывается есть команда:
show tunnel interface tunnel "номер интерфейса"
если вводить по "?" то говорит что нет ничего дальше.
#show tunnel ?
endpoints Display endpoints associated with multipoint tunnel
#show tunnel interface tunnel 1
Tunnel1
Mode:GRE/IP, Destination 10.69.16.162, Source Vlan200
IP transport: output interface Vlan572 next hop 10.69.4.41
Linestate - current down
Internal linestate - current down, evaluated down - keepalive down
Вывод очень удобен для просмотра краткого статуса и сводки конфигурации тунеля.

3) И опять BGP. Ситуация, есть 2 роутера, у каждого по eBGP пиру. Хотим зарезервировать подключение к внешним AS, исходя из этих соображений настраиваем между ними iBGP(учитывая баг описанный в пункте №1). После поднятия iBGP один из роутеров уходит в перезагрузку под нагрузкой, или пишет про не распознанный bgp header. На самом деле симптомов может быть уйма главнее что связка не работает, и не заработает.
решение: откат на 12.4.15
IOS 12.4.20T
Скажу по секрету, инженеры cisco сами очень не рекомендуют ставить "Т" серию, много там веселого.