Показаны сообщения с ярлыком Troubleshooting. Показать все сообщения
Показаны сообщения с ярлыком Troubleshooting. Показать все сообщения

понедельник, 21 мая 2012 г.

Etherchannel между Cisсo и Procurve



Cisco (Po1) - HP (Trk1) 

При объединении Cisco и HP  в Etherchannel обнаружилась неприятная вещь - при любом изменении количества активных волокон в канале на 1-2 секунды пропадает связь. Было обращение в TAC, где наличие проблемы подтвердили, однако решить ее быстро не смогли. Примерно через сутки активных экспериментов мне удалось подобрать такие настройки оборудования с обеих сторон, которые  исключили потери пакетов по крайне мере при добавлении линка и свели к ожидаемому  потери при падении одного из линков.
Итак, для минимизации потерь пакетов при падении/восстановлении физических линков, входящих в состав Etherchannel, необходимо выполнить следующие настройки:

1. Настроить на HP-Access Static LACP:
HP(config)# trunk 51-52 Trk1 LACP 
2. Настроить на Cisco LACP passive:
Cisco(config)#interface range Gi1/1,Gi1/2 
Cisco(config-if-range)#channel-group 1 mode passive

3. Для 6500 Cisco можно еще убедиться в том, что выбран Adaptive Hashing Method

Cisco(config)# show etherchannel <N> summary Flags: D - down P - bundled in port-channel I - stand-alone s - suspended H - Hot-standby (LACP only) R - Layer3 S - Layer2 U - in use N - not in use, no aggregation f - failed to allocate aggregator M - not in use, no aggregation due to minimum links not met m - not in use, port not aggregated due to minimum links not met u - unsuitable for bundling d - default port w - waiting to be aggregated Number of channel-groups in use: 5 Number of aggregators: 5 Group Port-channel Protocol Ports ------+-------------+-----------+----------------------------------------------- 1 Po1(RU) - Gi1/1(P) Gi1/2(P) Last applied Hash Distribution Algorithm: Adaptive 

Если поставлен метод Fixed, поменять на Adaptive
Cisco(config)# port-channel hash-distribution adaptive

Такие настройки позволят минимизировать потери пакетов при пропадании физического линка из состава Etherchannel и полностью избавиться от этого явления при восстановлении линка.

понедельник, 25 июля 2011 г.

QoS PRE-CLASSIFY и VTI


Команду qos pre-classify можно применить на VTI интерфейсах, IOS  ее отрабатывает без ошибок, показывает в running-config. Однако, данная команда на VTI не имеет практического  смысла.

Для VTI  правильно применять service-policy output, используя внутренние адреса, тогда соответсnвующие IPSec пакеты будут корректно прокрашиваться.

 Схема:


Конфигурация на HQ:

class-map VTI_QOS_CLASS
match access-group name VTI_QOS_ACL
!
!
policy-map VTI_QOS_POLICY
 class VTI_QOS_CLASS
  set dscp ef
!
!
interface Tunnel0
 ip unnumbered Loopback0
 qos pre-classify
 tunnel source 1.1.1.1
 tunnel destination 2.2.2.2
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI
 service-policy output VTI_QOS_POLICY
!
!
ip route 10.20.20.0 255.255.255.0 Tunnel0
!
!
ip access-list extended VTI_QOS_ACL
 permit ip host 10.10.10.10 host 10.20.20.20


Ссылки:
Virtual Tunnel Interface (VTI) Design Guide  - раньше был на сайте Cisco, теперь можно найти только в Инете.

пятница, 17 июня 2011 г.

IPSec между ASA и Cisco ISR (VTI)

Создание IPSec VPN между Cisco ASA и Cisco роутером, использующим технологию VTI на данный момент скорее всего невозможно.
При попытке установления соединения успешно завершается фаза 1, однако затем ASA пытается делать crypto map check, не находит совпадающих записей и сбрасывает соединение. Cisco роутер (при использовании VTI) аннонсирует crypto map вида permit any any и изменить это в данный момент, наверное, нельзя (можно попробовать навесить ACL непосредственно на VTI, но сейчас нет возможности проверить, а шансы, что сработает, мне кажется, малы).

Лог при этом имеет вид:
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, PHASE 1 COMPLETED
Mar 30 12:01:54 [IKEv1]: IP = 10.10.10.10, Keep-alive type for this connection: DPD
Mar 30 12:01:54 [IKEv1 DEBUG]: Group = 10.10.10.10, IP = 10.10.10.10, Starting P1 rekey timer: 82080 seconds.
Mar 30 12:01:54 [IKEv1 DECODE]: IP = 10.10.10.10, IKE Responder starting QM: msg id = e5be001d
Mar 30 12:01:54 [IKEv1]: IP = 10.10.10.10, IKE_DECODE RECEIVED Message (msgid=e5be001d) with payloads : HDR + HASH (8) + SA (1) + NONCE (10) + KE (4) + ID (5) + ID (5) + NONE (0) total length : 272
Mar 30 12:01:54 [IKEv1 DEBUG]: Group = 10.10.10.10, IP = 10.10.10.10, processing hash payload
Mar 30 12:01:54 [IKEv1 DEBUG]: Group = 10.10.10.10, IP = 10.10.10.10, processing SA payload
Mar 30 12:01:54 [IKEv1 DEBUG]: Group = 10.10.10.10, IP = 10.10.10.10, processing nonce payload
Mar 30 12:01:54 [IKEv1 DEBUG]: Group = 10.10.10.10, IP = 10.10.10.10, processing ke payload
Mar 30 12:01:54 [IKEv1 DEBUG]: Group = 10.10.10.10, IP = 10.10.10.10, processing ISA_KE for PFS in phase 2
Mar 30 12:01:54 [IKEv1 DEBUG]: Group = 10.10.10.10, IP = 10.10.10.10, processing ID payload
Mar 30 12:01:54 [IKEv1 DECODE]: Group = 10.10.10.10, IP = 10.10.10.10, ID_IPV4_ADDR_SUBNET ID received--0.0.0.0--0.0.0.0
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Received remote IP Proxy Subnet data in ID Payload: Address 0.0.0.0, Mask 0.0.0.0, Protocol 0, Port 0
Mar 30 12:01:54 [IKEv1 DEBUG]: Group = 10.10.10.10, IP = 10.10.10.10, processing ID payload
Mar 30 12:01:54 [IKEv1 DECODE]: Group = 10.10.10.10, IP = 10.10.10.10, ID_IPV4_ADDR_SUBNET ID received--0.0.0.0--0.0.0.0
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Received local IP Proxy Subnet data in ID Payload: Address 0.0.0.0, Mask 0.0.0.0, Protocol 0, Port 0
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, QM IsRekeyed old sa not found by addr
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Static Crypto Map check, checking map = outside_map, seq = 1...
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Static Crypto Map check, map = outside_map, seq = 1, ACL does not match proxy IDs src:0.0.0.0 dst:0.0.0.0
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Static Crypto Map check, checking map = outside_map, seq = 2...
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Static Crypto Map check, map = outside_map, seq = 2, ACL does not match proxy IDs src:0.0.0.0 dst:0.0.0.0
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Static Crypto Map check, checking map = outside_map, seq = 3...
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Static Crypto Map check, map = outside_map, seq = 3, ACL does not match proxy IDs src:0.0.0.0 dst:0.0.0.0
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Static Crypto Map check, checking map = outside_map, seq = 4...
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Static Crypto Map check, map = outside_map, seq = 4, ACL does not match proxy IDs src:0.0.0.0 dst:0.0.0.0
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Static Crypto Map check, checking map = outside_map, seq = 5...
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Static Crypto Map check, map = outside_map, seq = 5, ACL does not match proxy IDs src:0.0.0.0 dst:0.0.0.0
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Static Crypto Map check, checking map = outside_map, seq = 6...
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Static Crypto Map check, map = outside_map, seq = 6, ACL does not match proxy IDs src:0.0.0.0 dst:0.0.0.0
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 0.0.0.0/0.0.0.0/0/0 local proxy 0.0.0.0/0.0.0.0/0/0 on interface outside
Mar 30 12:01:54 [IKEv1 DEBUG]: Group = 10.10.10.10, IP = 10.10.10.10, sending notify message

Вот здесь описан относительно успешный опыт создания такого рода туннеля путем применения на ASA  crypto map вида permit any any.

вторник, 14 июня 2011 г.

Изменение Codec Complexity

Перед изменением параметра codec complexity на Cisco ISR'ах необходимо убрать voice порты. Для E1 это делается так:

1. Погасить соответствующий voice-port
R(config)#voice-port 0/3/0:15
R(config-voiceport)#shutdown

2. Убрать pri-group timeslots с соответствующего контроллера:
R(config)# controller E1 0/3/0
R(config-controller)#no pri-group timeslots 1-31


Иначе появляется ошибка вида:

R (config)#voice-card 0
R (config-voicecard)#codec complexity high
% Can't change codec complexity while voice port exist.
% Please remove all voice ports on this voice card first
% before changing codec complexity.

среда, 9 марта 2011 г.

Измерение ширины LFN канала на маршрутизаторах Cisco


LFN (Long Fat Network) - сеть обладающая большой пропускной способностью и большим временем задержки. Например, спутниковые или WiMAX каналы.

Оптимальным методом тестирования максимальной пропускной способности канала является передача UDP потока со скоростью заведомо превышающей скорость канала.


Чтобы получить адекватные значения пропускной способности каналов такого типа с использованием TCP, нужно иметь ввиду, что настройки TCP по умолчанию скорее всего не позволят это сделать. В Винде TCP Window Size определяется согласно данного алгоритма. Полученное значение не обеспечивает полную загрузку канала на широких линках с большой задержкой.


При тестировании LFN* сетей с помощью TCP для достижения  максимальной пропускной способности канала необходимо на конечных узлах тестирования менять TCP Window size в соответствии с пропускной способностью и задержкой  тестируемого канала.
 Расчет размера окна производится по формуле:

TCP window size (kBytes)  ≥ Bandwidth (KBytes/sec) *  packet RTT (sec)

Также для удобства расчетов TCP window size можно воспользоваться этим инструментом.

Для измерения ширины канала можно воспользоваться следующими инструментами:
1. iperf либо его графическим вариантом jperf
2. скрытой командой IOS ttcp. Команда доступна в привилегированном режиме, в большинстве версий IOS выше 11.2. Возможен вариант cisco-cisco, cisco(server)-PC(client), cisco(client)-PC(server). Приложение для PC доступно на http://renoir.csc.ncsu.edu/ttcp/
3. nuttcp




Полезные ссылки

IP Application Services Configuration Guide, Cisco IOS Release 15.1M&T
Шикарная статья
Еще статья
Tuning TCP under Windows XP
IETF RFC1323

Полезные ссылки - QoS

вторник, 1 марта 2011 г.

Auto-negotiation, Speed и Duplex

По умолчанию порты коммутаторов Cisco используют auto-negotiation для  определения скорости и дуплексности.  Эти параметры также могут быть заданы с помощью команд настроек интерфейса speed и duplex.

Для автоопределения настроек Cisco использует Fast Link Pulses(FLP).  Если устройство на другом конце  кабеля не поддерживает auto-negotiaition, порт все равно способен определить скорость. В случае несовпадения скоростей на концах линка, например при ручном его задании, связь будет невозможна.

Дуплексность определяется исключительно через auto-negotiation и только в том случае, если оба устройства на концах линка поддерживают эту функцию. Если же определить дуплексность посредством auto-negotiation невозможно, устройство предпринимает попытку «догадаться». Коммутаторы Cisco «догадываются»  по таблице:
Link speed
Duplex
10-Mbps
Half duplex
100-Mbps
Half duplex
1-Gbps
Full duplex

Чтобы отключить auto-negotioation на портах Cisco, необходимо  статически  задать speed и duplex.

Характерным признаком duplex mismatch на уровне приложения является проблема с передачей больших файлов. Например, письма с большими вложениями не уходят  или не синхронизируется AD
На уровне интерфейса (show interface) при этом наблюдается большое количество Late Collisions.
Впрочем, проблемы с передачей больших файлов могут быть вызваны также не оптимальным размером TCP Window Size.

вторник, 22 февраля 2011 г.

IPSec и фрагментация пакетов

При использовании IPSec необходима инкапсуляция пакетов, что ведет к увеличению их размеров.

 
Если размеры получившегося пакета превышают MTU, то маршрутизатор шифрует пакет, а затем его фрагментирует.  Таким образом, принимающий маршрутизатор, должен сначала собрать все фрагменты воедино, а затем расшифровать получившийся пакет. Процесс сборки обычно происходит на process level, что серьезно влияет на производительность. По этой причине фрагментации пакетов желательно избегать, где это возможно. Существуют несколько способов решения данной проблемы. Некторые требуют настройки маршрутизаторов, другие предполагают изменение настроек на конечных клиентах и серверах.

1.       Изменение MTU на конечных станциях. Возможно установить значение MTU на клиентах и серверах меньше, чем стандартное 1500 байт. Рекомендуемое в таком случае значение MTU равно 1300 байт.  К сожалению, масштабы сети часто не позволяют легко и непринужденно поменять настройки на всех машинах. В таком случае, можно попробовать ограничиться серверами, т.к. по большей части именно они являются генераторами больших пакетов.
2.       Path MTU Discovery
Эта фича была придумана, чтобы избежать необходимости фрагментации в принципе.  Она позволяет узлам определить самое маленькое MTU на пути следования пакетов и использовать его в дальнейшем. В этом случае конечная станция шлет пакеты с выставленным битом DF (запрет на фрагментирование).  Если на пути пакета попадается маршрутизатор, чей MTU меньше размеров пакетов, то этот маршрутизатор отсылает ICMP сообщение  type 3, code 4 Fragmentation needed and DF set. В неиспользуемой части ICMP пакета содержится значение MTU, используемое маршрутизатором.  Передающий хост может использовать это значение для корректировки собственного MTU. К сожалению, очень часто маршрутизаторы настроены подавлять отсылку ICMP сообщений type 3, например, с помощью популярной команды настройки интерфейса no ip unreachables. Лучше этого не делать, а если очень хочется, то использовать ip local route-map (разрешив отправку ICMP type 3, code 4). Если, конечно, IOS поддерживает cef switching для route-map (и если cef для local route-map возможен в принципе?).
3.       VPN Interface MTU
Можно подкорректировать, выставить значение 1300 на туннельном интерфейсе
ip mtu 1300
4.       Look Ahead Fragmentation
Фундаментально решает проблемы фрагментации, изменив порядок фрагментации и шифрования. Получив пакет, маршрутизатор просчитывает размер пакета после инкапсуляции, и в случае превышения MTU сначала  фрагментирует пакет, а затем шифрует получившиеся пакетики. Фича доступна с версии IOS 122(13)T и включена по умолчанию.
5.       TCP Maximum Fragment Size
Единственный способ повлиять на размер входящего пакета в условиях, когда не удается договориться с админами на втором конце. TSP MSS определяет максимальный размер TCP сегмента, что, в конечном итоге, определяет размер пакета. Влияет, естественно, только на TCP трафик.  UDP пакеты в основном не превышают  300  байт  за исключением видео.
По историческим причинам (до изобретения PMTUD) MTU для хостов за пределами локальной сети был равен 1300 байт. Отсюда взялось ограничение TCP MSS в 1260 байт (1300 – 20-byte-IP-header – 20-byte-TCP-header).  После внедрения PMTUD это ограничение было снято.
Каждый  из хостов при установлении TCP соединения анонсирует свой MSS в SYN пакетах(необязательно совпадающие).
Команда конфигурирования интерфейса
ip tcp adjust-mss 1260
принудительно переводит поведение TCP сессий в до-PMTUD эпоху. При использовании этой команды на интерфейсе  маршрутизатор переписывает значения MSS в TCP SYN пакетах, полученных на этом интерфейсе. Что, впрочем, заметно нагружает маршрутизатор.

понедельник, 21 февраля 2011 г.

IOS Order of Operations

Валяющийся на Cisco.com документ под названием "NAT order of operation" безобразно устарел. На просторах Инета удалось откопать документ следующего содержания:


пятница, 4 февраля 2011 г.

ZBF и Traceroute


В версии IOS 12.4 при использовании Zone-Based Firewall  для корректной работы утилиты traceroute требуется разрешить прохождение ICMP пакетов port-unreachable (type 3, code 3) и ttl-exceeded(type 11, code 1) без инспекции.

Для этого создаем ACL:

ip access-list extended TRACE
 permit icmp any any port-unreachable
 permit icmp any any ttl-exceeded

ip access-list extended ICMP
 permit icmp any any port-unreachable
 permit icmp any any ttl-exceeded
 permit icmp any any packet-too-big


Класс:

class-map type inspect match-all TRACE
 match access-group name TRACE

class-map type inspect match-all ICMP
 match access-group name ICMP



И объявляем политику так, чтобы эти пакеты не инспектировались, а пропускались как есть:

1.   Внутрь

policy-map type inspect ISP-SELF
 class type inspect  TRACE
  pass
 class type inspect ISP-SELF
  inspect
 class class-default
  drop log


2.   Наружу

policy-map type inspect SELF-ISP
 class type inspect ICMP
  pass
 class type inspect SELF-ISP
  inspect
 class class-default
  drop

пятница, 28 января 2011 г.

Особенности реализации TRACEROUTE на различных ОС


Принцип работы команды основан на отсылке серии IP пакетов с возрастающим параметром Time To Live (TTL) от 1 до максимум  30 (по умолчанию).  Каждый маршрутизатор на пути следования пакета, приняв пакет с TTL=1 отсылает источнику сообщение ICMP type 11 , code 0 (time exceeded, TTL exceeded). Таким образом, у источника есть шанс узнать путь к хосту назначения. При условии, конечно, что для всех отосланных пакетов путь был одинаковым, т.е. маршруты стабильными и предопределенными.  На разных операционках команда реализована разными способами.

 Cisco IOS и Linux
Используются udp пакеты с начальным TTL по умолчанию равным 1 и с начальным портом назначения по умолчанию 33434. Порт источника выбирается случайным образом выше 0x8000 (32768).  Каждый следующий пакет высылается на следующий UDP порт, а порт источника снова выбирается случайным образом.  Т.н. расширенная (extended) traceroute позволяет задавать параметры, отличные от параметров по умолчанию.
Каждый маршрутизатор на пути следования пакетов, получивший пакет с TTL=1 отсылает источнику ICMP сообщение type 11, code 0 (time exceeded, TTL exceeded).
По достижении пакетом хоста назначения, последний отправляет ICMP type3, code 3 (destination unreachable, port unreachable).
В Linux команда работает похожим образом, только порт источника остается постоянным.

 
На Cisco маршрутизаторах коды ответов команды traceroute в CLI:
! -- success
* -- time out
N -- network unreachable
H -- host unreachable
P -- protocol unreachable
A -- admin denied
Q -- source quench received (congestion)
? -- unknown (any other ICMP message)

Для предотвращения DoS атак на Cisco маршрутизаторах установлено ограничение на отправку сообщений ICMP ureachable не чаще, чем раз в 500 ms. Это объясняет "пропадающие" ответные пакеты. В версиях IOS 12.1 и выше 'njn параметр можно поменять командой
 
no ip icmp rate-limit unreachable
 
 
 
Microsoft Windows
Для трассировки использует ICMP  type=8, code=0 (echo request) вместо UDP. Соответственно, хост назначения высылает ICMP type=0, code=0 (echo reply). Все остальное аналогично.