Записки для подготовки к CCIE Voice Lab
maxalion
9 апр. 2012 
    1) VTGO multilab софтфоны не регистрируются на CCM/CME

решение проблемы описал в в посте вот тут.

оттуда:

...VTWizard said something like that: "Sorry, you need at least one active network connection to use VTGO". I could see in trace that vtgo successfully found my network adapter but after that it immediately placed my adapter in excluded list and ignored it. . I can't exactly tell you what the reason but i sure 90% it's Win7 localization edition question. I use Windows 7 Russian edition. I found how to remedy this:

1.Open registry and find next parameter:

HKEY_LOCAL_MACHINE\SOFTWARE\IP blue Software Solutions, LLC\VTGO-PC\sExcludeAdapter

2. clear it's value (but not delete the parameter!!!) if it's not empty.

3. Restart VTGO.


2 апр. 2012 
    1) Проблема с заливкой SIP прошивки на телефон в CME 
    2) SIP Phone in Unprovisioned state

1) При попытке проапгрейдить на CME 7961 модель на SIP прошивку, телефон не может её загрузить.
Исх.данные: файлы прошивки вылжены на TFTP сервер (раб.станция) из-за нехватики места на флеше роутера.
На этапе загрузки 7961 искал файл term61.default.loads, но не находил:

*Apr  2 08:40:08.081: TFTP: Server request for port 49153, socket_id 0x67B2BB44 for process 280
*Apr  2 08:40:08.081: TFTP: read request from host 10.10.202.50(49153) via FastEthernet0/0.400
*Apr  2 08:40:08.081: TFTP: Looking for term61.default.loads
*Apr  2 08:40:08.081: TFTP: Sending error 1 No such file

Решение:
В dhcp пуле в качестве опции 150 был указан ip роутера (Lo0). Поменял на ip станции и добавил dns-сервер. После этого 7961 подхватил sip прошивку, но ... см. п.2

2) ...7961 на CME ушел в Unprovisioned state.
решение: добавил в dhcp пул domain-name, и далее в voice register global:
upgrade
creat profile
перезагрузка телефона.
Телефон зарегился.
З.Ы. Скорее всего проблема 2) решается, в т.ч. и выполнением пункта 1.

Особенности реализации l2tpv3 на маршрутизаторах Cisco 881
maxalion
Хорошо, конечно, что такой доступный (относительно других серий) по цене  маршрутизатор cisco 881 поддерживает, причем в уже в базовом фич-сете, такую мощную провайдерскую:)) опцию, как  протокол l2tpv3. Но при настройке l2tpv3  туннеля для проброса L2 подсетей через WAN канал следует учитывать одну особенность этого девайса. Странную весьма, на мой взгляд.

Напомню, 880 серия имеет на борту встроенный 4-портовый LAN свич (порты Fa0..Fa3) и один WAN порт Fa4. Итак, при настройке  l2tpv3, чтобы протокол заработал, нужно маршуратизатор хмм.. "перевернуть", то есть WAN порт (Fa4) воткнуть в LAN сегмент сети, которую хотим пробросить по l2tpv3 , а один из четырех  портов встроенного коммутатора воткнуть уже в WAN канал. Роль layer 3 WAN интерфейса здесь будет исполнять не специально отведенный для этой цели порт Fа4,  а дополнительно поднятый на встроенном свиче интрефейс VLAN (SVI).

По логике вещей всё должно быть ровно наоборот: порт WAN  маршрутизатора  смотрит в сторону WAN канала, а порты встроенного коммутатора - в сторону внутренней пробрасываемой LAN сети. Но если делать "по-правильному", то l2tpv3 не поднимется. Точнее вроде как  поднимется, если судить по выводу команд диагностики "show l2tpv3 ...". Сей вывод честно покажет, что, мол, всё замечательно,  состояние l2tpv3 туннеля с обеих сторон  Up-Up, и даже присутствует hostname маршрутизатора, терминирующего с другой стороны наш туннель. Но на деле пакеты проходить по туннелю не будут. Не будут, пока не первернете маршрутизатор)))

Нигде на цискокоме я не нашел упоминания о таком веселом факте настройки l2tpv3 на 880 серии.

Данная статья актуальна для версий софта до 15.1s(3) включительно.

Cisco Multi Netflow Collector (MNFC), немного из практики установки и эксплуатации
maxalion
Cisco MNFC предназначен для сборки данных с множества коллекторов NFC. Работает только с версиями NFC не ниже шестой. Для складирования данных использует базу данных IBM Informix v9.4, а точнее ее компонент IDS.  Обязательным условием  является установка базы Informix на отдельный диск с  RAW партицией. Благодаря этому  Informix работает с диском напрямую,  осуществляя операции Input/Output без использования ресурсов системы.  Для работы с базой требуется предварительно создать отдельную группу informix и завести нового пользователя informix, добавив его в эту группу. После того, как вы создали RAW партицию(и), требуется устанавить для данного пользователя права и собственность на  эту партицию. В инструкции по установке это сказано, на не показано, как  сделать. Восполняю сей пробел:

chmod 660 /dev/raw/raw1
chown informix /dev/raw/raw1
chgrp informix /dev/raw/raw1



Без этого процесс Storage Manager (принадледит юзеру informix) не сможет писать данные в базу.
Это то, что касается установки MNFC.

Теперь немного о работе с продуктом.
Самый простой вариант, как заставить  MNFC что-то делать - это добавить новый коллектор и  создать агрегатор. При добавлении агрегатора учитываем, что его название должно совпадать с реальным названием агрегатора, заведенного на коллекторе, с которого собираемся складировать статистику.
После того, как добавили новый коллектор, MNFC  должен будет забирать с него статистику по протоколу ftp(sftp). Но на самом деле ничего MNFC забрать не сможет. Несмотря на то, что вы будете все делать в соответствии с гайдом. Понять, что творится что-то неладное, можно, взглянув на содержимое файла mnfc.log. Строка типа

2011-12-26 16:38:14 MSK] ERROR com.cisco.mnfc.transport.FileTransport - failed to ftp host

может направить наши размышления в нужную сторону. Нигде в руководстве по эксплуатации (User Guide) вы не найдете информации о том, что (оказывается!!!) нужно было предварительно поднять на  NFC 
коллекторе, с которого мы собираемся получать данные, сервер FTP. Итак, теперь, когда нам все известно, лезем на NFC, монтируем к нему установочный диск Red Hat и через Add/Remove Programms дополнительно устанавливаем компонент  FTP (демон  vsftpd). После установки стартуем сервис vsfpd (по умолчанию кладется в папку /etc/init.d), добавляем его в список автозагрузки (иначе после первого же ребута  коллектора MNFC перестанет получать с него данные) и не забываем добавить пользователя nfcuser (то есть того самого, которого вы указали в MNFC при добавлении нового коллектора) в группу FTP.

Cisco NFC: how to resolve interface names in reports
maxalion
Дано:
Сервер Cisco Netflow Collector (NFC) v.6
коммутатор Cisco Nexus 1000V

При генерации отчетов в NFC  столкнулся с проблемой: значения полей "Input Interface" , "Output Interface" вместо имени интерфейса соержат некое числовое значение.  Вопрос: Что это значит и Как заставить NFC выводить имя интерфейса вместо его ID?

По-умолчанию Nexus1000V  посылает в сторону коллектора, в числе прочего, информацию о входящем и исходящем
интерфейсах для потоков трафика.  Просматривая лог файл  nfc.log на NFC сервере, я заметил, что  netflow источник  отсылает коллектору шаблон данных (data template), в котором он описывает формат и содержимое данных, которые   затем будет отправлять коллектору:

[2011-12-23 15:23:55 MSK] INFO com.cisco.nfc.collector.TemplateManager - New data template from host=10.1.20.192, port=9996/udp, sourceId=4, templateId=257: id=257, fields=4
    field id=8 (ipv4 source address), offset=0, len=4
    field id=10 (interface input snmp), offset=4, len=4
    field id=14 (interface output snmp), offset=8, len=4
    field id=61 (flow direction), offset=12, len=1

Как видно из лога, информация об интрефейсах передается в виде interface input/output snmp. Эта информация   приходит  в числовом формате и означает ID интерфейса. Слово snmp здесь присутствует недаром:  чтобы коллектор смог разрешить данное значение в "читабельное" , он должен отправить NDE источнику  snmp запрос c  указанием этого ID . В ответ он получит interface name.

Чтобы разрешить коллектору отправлять  snmp запросы, нужно в файле конфигурации nfcifname.xml прописать  snmp community string (read only) для источника NDE. Файл лежит в папке /opt/CSCOnfc/config/ . Добавляем в него строчку вида:

<comm-string device="IP_ADDRESS">public</comm-string>,

заменяя выделенные поля подходящими значениями. Не забываем также прописать RO community string на самом источнике NDE.


Tags: , ,

OTV, High CPU load на нексусах 7010 при растянутом через OTV влане с кластером Microsoft NLB, Часть2
maxalion
Напомню суть проблемы: имеем  два территориально разнесенных DC (DC1 и DC2) с парой центральных коммутаторов Nexus 7010 в каждом из них. Между этими DC организована связность на уровне L2 через технологию OTV (Overlay Transport Virtualisation). Поверх OTV растянуто множество вланов. Все работает прекрасно. Почти. В одном из растянутых вланов появился Microsft NLB кластер (в режиме mulitcast IGMP), выполняющий функции PROXY сервера. 
Его появление привело к  необоснованному повышению загрузки CPU на всех четырех коммутаторах N7k, причем именно в рабочие часы. Днем ежечасно возникают короткие пики с загрузкой до 100%. Все это приводит к "лаганию" сервисов и возрастающему недовольству пользователей. Неприятно, в общем. 

Об особенностях реализации multicast IGMP в Microsoft NLB я писал ранее.

Итак, решение найдено!

На всех N7k в режиме конфигурации VLAN 

Пакеты с destination ucast IP и mcast MAC адресом обрабатываются нексусом программно, что приводит к нагрузке на его центральный CPU.  Workaraund следующий:

1) На всех N7k в основном VDC в режиме конфигурации VLAN добавить статическую запись соответствия IGMP группы кластера NLB и интерфейса нексуса, за которым находится эта  группа:

vlan configuration 10
  ip igmp snooping static-group 239.255.12.80 interface port-channel20
  ip igmp snooping static-group 239.255.12.80 interface port-channel21
2) На всех N7k в основном VDC и в том VDC,  в котором у вас реализован функционал OTV (условно VDC OTV)  в режиме конфигурации VLAN изменить lookup режим для mcast пакетов с IP based на MAC based:

vlan configuration 10
  layer-2 multicast lookup mac

После выполнения этих действий загрузка CPU на всех нексусах упала с 40-50% до прежних значений 10-15%.
Позже практика показала, что  достаточно выполнить только пункт 2. А добавление статических IGMP групп необязательно, т.к. при включенном IGMP snooping нексус самостоятельно определит, за какими портами живет соответствующая mcast группа.
Tags: , , ,

OTV, High CPU load на нексусах 7010 при растянутом через OTV влане с кластером Microsoft NLB
maxalion
!!Требует редактирования!!

Список команд, которыми пользовался инженер Cisco TAC для диагностики проблемы с высокой загрузкой CPU на нексусах 7010 при растянутом в OTV влане  с кластером Microsoft NLB:
 
смотрит, дропает ли policy-map на контрол плейне пакеты:

msk-vol-core-1# sh policy-map int control | i i class-map|drop
msk-vol-core-1#
 
Видит, что вообще ничего нету и смотрит, а есть ли на control plane хоть какой-то полиси-мап:

msk-vol-core-1# sh policy-map int control
 
msk-vol-core-1# sh run copp
 
 
 
msk-vol-core-1# sh hard int cpu inb stat | i pps
Packet rate limit ........... 32000 pps
Rx packet rate (current/max)  2061 / 10231 pps
Tx packet rate (current/max)  319 / 2741 pps
 
 
 
Ловит  встроенным ethereal пакеты и пишет пойманное на bootflash для дальнейшей обработки WireShark-ом:
 
msk-vol-core-1# etha lo in in limit-captured-frames 0 write bootflash:msk-vol-core1.pcap
 
Capturing on inband
45480
21506 packets dropped
Program exited with status 0.
msk-vol-core-1#
 
 
 
Из контекста OTV смотрим статистику пакетов на «скрытых» интерфейсах туннелей otv:
 
Show tunnel internal implicit otv | I up|source|rate
 
sh tunnel internal impli otv det | i up|source|rate
Tunnel16539 is up
    Tunnel source 10.255.249.9, destination 10.255.249.25
    0 packets output, 1 minute output rate 0 packets/sec
    0 packets input, 1 minute input rate 0 packets/sec
Tunnel16540 is up
    Tunnel source 10.255.249.9, destination 10.255.249.29
    0 packets output, 1 minute output rate 0 packets/sec
    4069360036 packets input, 1 minute input rate 2917 packets/sec
Tunnel16542 is up
    Tunnel source 10.255.249.1, destination 10.255.249.5
    0 packets output, 1 minute output rate 0 packets/sec
    0 packets input, 1 minute input rate 0 packets/sec
Tunnel16550 is up
    Tunnel source 10.255.249.1, destination 10.255.249.17
    0 packets output, 1 minute output rate 0 packets/sec
    0 packets input, 1 minute input rate 0 packets/sec
Tunnel16552 is up
    Tunnel source 10.255.249.9, destination 10.255.249.13
    0 packets output, 1 minute output rate 0 packets/sec
    0 packets input, 1 minute input rate 0 packets/sec
Tunnel16553 is up
    Tunnel source 10.255.249.1, destination 10.255.249.21
    0 packets output, 1 minute output rate 0 packets/sec
    832 packets input, 1 minute input rate 0 packets/sec
msk-var-core-1-OTV#
 
Также из контекста OTV:
 
msk-var-core-2-OTV# sh tunnel internal impli otv brief
 
-------------------------------------------------------------------------------
Interface                Status     IP Address        Encap type       MTU     
-------------------------------------------------------------------------------
Tunnel16684              up         --                GRE/IP           9178   
Tunnel16724              up         --                GRE/IP           9178   
Tunnel16731              up         --                GRE/IP           9178   
Tunnel16732              up         --                GRE/IP           9178   
Tunnel16733              up         --                GRE/IP           9178   
Tunnel16734              up         --                GRE/IP           9178  
 
 
Для каких вланов данный девайс является AED. Также из контекста OTV:
 
 
msk-var-core-2-OTV# sh otv vlan authoritative
 
OTV Extended VLANs and Edge Device State Information (* - AED)
 
VLAN   Auth. Edge Device                     Vlan State       Overlay
----   -----------------------------------   ----------       -------
  30*  msk-var-core-2-OTV                    active           Overlay2  
 100*  msk-var-core-2-OTV                    active           Overlay2  
 102*  msk-var-core-2-OTV                    active           Overlay2  
 104*  msk-var-core-2-OTV                    active           Overlay2  
 106*  msk-var-core-2-OTV                    active           Overlay2  
 108*  msk-var-core-2-OTV                    active           Overlay2  
 122*  msk-var-core-2-OTV                    active           Overlay2  
 134*  msk-var-core-2-OTV                    active           Overlay2  
 222*  msk-var-core-2-OTV                    active           Overlay1  
 232*  msk-var-core-2-OTV                    active           Overlay2  
 236*  msk-var-core-2-OTV                    active           Overlay2  
 402*  msk-var-core-2-OTV                    active           Overlay2  
 500*  msk-var-core-2-OTV                    active           Overlay2  
 502*  msk-var-core-2-OTV                    active           Overlay2  
 504*  msk-var-core-2-OTV                    active           Overlay2  
 600*  msk-var-core-2-OTV                    active           Overlay2  
 648*  msk-var-core-2-OTV                    active           Overlay2  
 656*  msk-var-core-2-OTV                    active           Overlay2  
 662*  msk-var-core-2-OTV                    active           Overlay2  
 666*  msk-var-core-2-OTV                    active           Overlay2  
 670*  msk-var-core-2-OTV                    active           Overlay2  
 672*  msk-var-core-2-OTV                    active           Overlay1  
 
 
Смотрит, какие есть IGMP группы:
 
msk-var-core-1# sh ip igmp group

Cisco ASR 1000, QoS для DMVPN - особенности настройки
maxalion
    Увы, но Cisco ASR 1000 в текущей версии софта (Version 15.1(3)S1) до сих пор не поддерживает QoS в сторону филиалов через маппинг NHRP групп для облака DMVPN. Т.е. на данный момент, если вы захотите на хабе настроить качество сервиса в сторону споков (spokes), то воспользоваться простыми средствами, давно доступными на железе уровня ISR G1/G2, вы не сможете. Поэтому приходится использовать policy-map на исходящем интерфейсе с отдельным class-map для каждого спока (группы споков). Неудобство в том, что в случае большого количества споков итоговая конструкция получится весьма громоздкой. Ладно, если речь идет о десятке споков, а если у вас несколько десятков или сотен филиалов? Придется для каждого создавать свой class-map и свой access-list.
 
    Если на хабе вы используете crypto isakmp profiles для описания ваших споков, то возможно, что для применения к ним политик QoS вам захочется (ну, во всяком случае, мне захотелось)  внутри такого профайла использовать  qos группы, чтобы потом на их основе сделать шейпинг/полисинг/приоритет трафика для отдельных филиалов. Увы, не обольщайтесь - не получится. Проблема в том, что для применения политики QoS на базе qos групп должно выполняться следующее условие: и crypto map и policy map обязательно должны применяться к одному и тому же интерфейсу! В случае с DMVPN это условие нельзя выполнить, потому что в DMPVN:
    - crypto map применяется к mGRE туннельному интерфейсу,
    - policy map применяется к физическому опорному интерфейсу. К mGRE туннельному интерфейсу его применить нельзя.
Поэтому, если необходимо применить per-spoke based политики QoS, то единственный способ это сделать - использовать отдельный ACL для каждого филиала, внутри которого нужно будет прописать:
      а) внутреннюю (inside) подсеть филиала, если используется опция qos pre-classify на туннельном интерфейсе хаба,
      б) ip адрес внешнего (outisde) интерфейса спока, если  опция qos pre-classify на туннеле не используется.
.

Tags: ,

WS-CBS3120G-S: IGMP snooping некорректно работает c mcast MAC + ucast IP
maxalion
  Итак, имеем коммутатор блейд корзины Cisco Catalyst Blade Switch 3120 . 
В случае, если в сети присутствует multicast (далее mcast), то наверняка мы захотим использовать IGMP snooping  для отправки mcast трафика только тем хостам, которые в нем заинтересованы. Обычно IGMP snooping включен по умолчанию на цисковских свичах.
  Если  при отправке mcast пакета в качестве destination MAC указан честный mcast MAC адрес и  в качестве destination IP этого пакета  указан честный mcast IP адрес, то IGMP snooping отработает как и положено, отправив данный пакет лишь в те порты коммутатора, на которых сидят участники соответствующей mcast группы (под честным mcast MAC адресом имею в виду адрес в диапазоне 0100.5Exx.xxxx, под честным mcast IP адресом -  адрес IP  в диапазоне 224.0.0.0 - 239.255.255.255).

    Проблема возникает, если destination IP окажется не mcast, a unicast (далее ucast). Такой пакет будет вопреки логике IGMP отправлен коммутатором cat3120 во все порты, принадлежащие влану, т.е., попросту говоря, пакет "зафлудится" во все порты. Ситуация, когда в заголовке пакета в поле destination окажутся mcast MAC и ucast IP, вполне возможна, если мы настраиваем сеть, в которой присутствует Microsoft NLB кластер, работающий в режиме Multicast IGMP. В  таком случае виртуальный адрес кластера будет представлять собой сочетание некоего ucast IP адреса и сгенерированного системой mcast MAC адреса. Вообще cisco устройства не любят такое сочетание и считают его некорректным. (более того, ARP reply   для такого адреса не будет приниматься коммутатором L3, и соотв. запись в его ARP таблице всегда будет Incomplete).
  Свич 3120 унаследовал архитектору софта от серии 3750, и реализованный на нем IGMP snooping процесс для отправки пакетов по назначению  использует групповой IP адрес , а не mcast MAC (т.е. не Layer 2) адрес. Если же все-таки пришел пакет с mcast MAC + ucast IP, то этот пакет будет "зафлуден" коммутатором во все порты соотв. влана.
 
  Есть способ, как этого можно избежать -  прописываем на cat3120 вручную мак адрес VIP кластера и список портов комумутатора, за которым он живет:

      mac address-table static 03bf.c0a8.1303 vlan 202 interface gigabitEthernet 1/0/21 gigabitEthernet 2/0/21

Тогда свич станет отправлять пакеты с MAC адресом 03bf.c0a8.1303 строго в указанные порты 1/0/21 и 2/0/21  и ни в какие более.

Cisco, Route Leaking между VRF и GRT
maxalion

Inter-VRF Route-Leaking делается стандартным способом через применение уникальных route distinguisher (RD) и конструкции route-target export/import  внутри каждого  описания vrf-а  и  организацию обмена такими RD через два независимых vrf-aware BGP процесса. 


Вопрос возникает с организацией  обмена маршрутами между конкретным vrf-ом и Global Routing Table (GRT).

Если надо сделать утечку static маршрутов, то это не проблема:  делается через добавление маршрута, в котором в качестве next-hop будет указан интерфейс, принадлежащий другому VRF. 

Вопрос: Как между vrf и GRT сделать утечку множества маршрутов , изученных через IGP?

Ответ: Это просто! )) Для этого поднимаем GRE туннель между GRT и нужным VRF. Для построения туннеля в качестве source и destination  используем два loopback интерфейса, причем пускай оба принадлежат GRT. Для построения такого локального туннеля у нас должно быть два создано туннельных интерфейса: один принадлежит GRT, другой  принадлежит нашему VRF. Важный момент: туннельным интерфейсам обязательно должны быть присвоены ip адреса (желательно из одной подсети). Иначе, с точки зрения L3, туннельный интерфейс не будет в Up и, соответственно, добавив статический маршрут из одного VRF в другой, и задав наш туннельный интерфейс в качестве nrxt-hop,  мы не увидим его в таблице маршрутизации. 

interface loopback 101
 ip address 1.1.1.1 255.255.255.255

interface loopback 102
 ip address 2.2.2.2 255.255.255.255

interface Tunnel 101
ip vrf forwarding MYVRF
tunnel source loopback101
tunnel destination 2.2.2.2

interface Tunnel 102
tunnel source loopback102
tunnel destination 1.1.1.1



Предположим, для обмена маршрутной информацией мы используем протокол EIGRP. Тогда помимо основного EIGRP процесса в GRT нам придется поднять дополнительный процесс в VRF. И прописать в нем автономную зону. В эти процессы мы помещаем соотв. туннельные интерфейсы, и дело сделано!


Стояла конкретная задача балансировки трафика, идущего от HQ к филиалам:
Имеется два DMVPN облака. Каждый филиал (spoke) имеет по два подключения к хабу: одно через WAN ( DMVPN cloud 1),  другое через Интернет (DMVPN cloud 2). Все устройства в DMPVN облаках включены в процесс EIGRP с общей автономной системой. 

Что надо было сделать: весь трафик от хабов, за исключением интернета, пустить через WAN канал. Интернет трафик (т.е. тот, который идет от прокси серверов, размещенных в HQ, в сторону филиалов) должен идти через интернет канал. 
При этом в случае падения интернет каналов пользовательский интернет трафик должен перенаправляться к филиалам уже через туннель поверх WAN канал. Аналогично должно отрабатываться и падение каналов WAN: весь трафик уходить через туннель поверх интернет. 


Перенастройка существующей конфигурации филиалов  затруднена из-за их большого количества и сложностей административного характера. Т.е. вносить изменения в конфигурации филиальных маршрутизаторов  было крайне проблематично.

Как, имея такие входные данные, обеспечить на хабах маршрутизацию трафика указанным способом?
Проблема заключалась в том, что  принимать решение о маршрутизации пакета надо исходя из того, от кого этот пакет был получен, т.е. базируясь на  адресе отправителя (source-based routing). Все протоколы маршрутизации по природе своей destination based. Поэтому без Policy Based Routing (PBR) нам было не обойтись.

Решалось следующим способом:
На внутреннем (inside) интерфейсе хаба при помощи PRB мы разбираем трафик, используя ACL списки доступа.  Далее трафик, подпадающий под данный ACL,  мы помещаем в отдельный VRF. Этому же vrf-e2
Решение задачи заключалось в фи


?

Log in