отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 

Ответы на задачи конкурса: "Следствие ведут ИТ-шники"

День 1: Маршрутизация и коммутация.

 

Задача 1.

Решение:

1. Проблема вызвана использованием MPLS L3VPN с 2-мя метками, которые добавляют 8 байт к пакету. 

2. Увеличение MTU на MPLS интерфейсах минимум на 8 байт 

3. Workaround – использование команды ‘ip tcp adjust-mss’ 

 

Задача 2

Решение: Внутри MPLS сети на пути траффика на одном из линков пропало LDP соседство –> пропал непрерывный LSP между PE маршрутизаторами -> vpnv4 траффик не может пройти этот линк

 

Задача 3

Решение: Для трафика от Host1 к Host2 будет использован путь R4->R3->R2, т.к. в соответствии c OSPF rfc2328 intra-area путь до R2 ASBR/next-hop более предпочтителен. Для того, чтобы трафик гарантированно шел через 10GE линк нужно в area1 поднять virtual-link между router-id R1 и R2 или же поднять gre tunnel на этих же маршрутизаторах и поместить его в area0.

 

Задача 4

Решение: Причиной проблемы является то, что МАС адрес default-gateway для data vlan 11 стал виден через интерфейс Gi2/4, и так как на интерфейсе Gi2/4 настроен port-security, то этот адрес в МАС таблице прописался как STATIC (11    000f.352c.b112    STATIC      Gi2/4), что нарушило правила передачи пакетов, идущих в Интернет – вместо отправки в интерфейс Gi5/1 они отправлялись в интерфейс Gi2/4. Необходимо удалить неправильную запись из МАС таблицы (11    000f.352c.b112    STATIC      Gi2/4). Это мог быть злой умысел, когда адрес на компьютере поменяли сознательно, это могла быть ошибка подключения линка на 6500, это могла быть ошибка IOS.

 

День 2: Информационная безопасность.

 

Задача 1

- Почему не поднимается туннель при инциировании со стороны роутера ZZZ ?

Ответ: Согласно первому дебагу, роутер ZZZ при подъеме первой фазы IKE присылает для первой фазы следующие алгоритмы шифрования (трансформы) DES/MD5/DH Group 1 и DES/SHA/DH Group 1. 

Поскольку роутер Cisco отвечает (по первому дебагу) сообщением no offers accepted!, то это говорит о том, что на роутере Cisco вообще не настроены такие алгоритмы для первой фазы.  Т.е. на Cisco 881 не настроен DES.

 

- Почему этот же туннель успешно поднимается при инициировании со стороны роутера Cisco 881 ?

Ответ: Роутеры разных производителей могут иметь разную логику работы.  Логика работы роутера ZZZ может отличаться от логики работы роутера Cisco.

Роутер Cisco всегда использует свои алгоритмы шифрования (трансформы) для первой фазы IKE симметрично - при инциировании туннеля удаленному роутеру отправляются все имеющиеся на Cisco трансформы первой фазы IKE, при приеме туннеля также просматриваются все трансформы, имеющиеся на роутере Cisco. 

Неправильной настройкой трансформов первой фазы IKE на роутере Cisco нельзя добиться асимметричного подъема туннеля - если будет хоть одно совпадение в транформах с удаленным роутером, туннель будет подниматься в обоих направлениях, если же ни одного совпадения не будет, туннель не будет подниматься ни в одном.

Однако, роутер другого производителя ZZZ может иметь другую логику работы, и в частности, может использовать имеющиеся на нем трансформы первой фазы IKE асимметрично.  При принятии туннеля роутером ZZZ может использоваться один комплект трансформов (скажем, все имеющиеся), а при инициировании туннеля со стороны ZZZ может использоваться другой комплект (скажем, только явно указанный для конкретного туннеля трансформ).

В данном конкретном случае настройки были такие:

- на стороне Cisco для первой фазы IKE было настроено:  3DES/SHA/DH Group 2 (это видно из второго дебага).

- на стороне роутера ZZZ для первой фазы IKE были настроены:  DES/MD5/DH Group 1, DES/SHA/DH Group 1, 3DES/SHA/DH Group 2 (это видно из обоих дебагов).

При этом, роутер ZZZ был настроен так, что при инициировании туннеля он использовал _ТОЛЬКО_ трансформы с DES, явно привязанные администратором для данного туннеля в настройках роутера ZZZ (они были указаны там по ошибке вместо трансформов с 3DES, также имеющихся на роутере ZZZ).  Поднятие туннеля со стороны ZZZ не работало, т.к. ZZZ предлагал только DES, а на Cisco не было DES. 

При инциировании туннеля со стороны Cisco с использованием 3DES, роутер ZZZ, выступая в роли респондера, просматривал ВСЕ имеющиеся у него в конфигурации трансформы (а не только те, которые были заданы для проблемного туннеля явно), и соглашался на 3DES от Cisco, поскольку у него в конфигурации были и DES и 3DES.  Таким образом, от Cisco к ZZZ туннель поднимался.

Ошибка была на стороне роутера ZZZ.  После явного указания трансформов с 3DES для первой фазы IKE для данного туннеля, все начало работать корректно.

 

Задача 2

Решение:

Есть несколько способов решения этой проблемы. Наиболее изящный приведен ниже.

 

interface GigabitEthernet0/0
nameif outside
security-level 0
ip address 194.1.1.253 255.255.255.252
 
interface GigabitEthernet0/2
nameif dmz
security-level 50
ip address 194.1.1.1 255.255.255.0
 
object network obj-194.1.1.0
subnet 194.1.1.0 255.255.255.0
 
arp dmz 194.1.1.254 001d.454c.2364 alias
 
nat (dmz,outside) source static obj-194.1.1.0 obj-194.1.1.0
 
access-list outside_in extended permit icmp any any
access-group outside_in in interface outside
 
route outside 0.0.0.0 0.0.0.0 194.1.1.254 1

 

Разумеется, в ACL д.б. и др. строки для разрешения трафика на сервера в DMZ.

Обратите внимание, что на интерфейс outside назначен 194.1.1.253/30 с маской /30, а на провайдере по условиям задачи настроено 194.1.1.254/24 с маской /24, как и на DMZ-интерфейсе - 194.1.1.1/24. В отличие от маршрутизаторов, такое возможно.

 

BSNS-ASA5520-2# sh route
 
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route
 
Gateway of last resort is 194.1.1.254 to network 0.0.0.0
 
C    194.1.1.252 255.255.255.252 is directly connected, outside
C    194.1.1.0 255.255.255.0 is directly connected, dmz
S*   0.0.0.0 0.0.0.0 [1/0] via 194.1.1.254, outside

 

С т.зр. ASA подсети 194.1.1.252/30 и 194.1.1.0/24 различны, коль скоро .252 не равно .0 :)

В "debug arp" видно следующее, если пинговать сервер в DMZ 194.1.1.2 с маршрутизатора ISP 194.1.1.254:

 

arp-in: request at outside from 194.1.1.254 0013.7f3d.bcdf for 194.1.1.2 0000.0000.0000
arp-in: rqst for me from 194.1.1.254 for 194.1.1.2, on outside
arp-set: added arp outside 194.1.1.254 0013.7f3d.bcdf and updating NPs at 2923140
arp-in: generating reply from 194.1.1.2 001d.454c.2362 to 194.1.1.254 0013.7f3d.bcdf
 
arp-in: request at dmz from 194.1.1.2 30e4.db22.7181 for 194.1.1.254 0000.0000.0000
arp-in: rqst for me from 194.1.1.2 for 194.1.1.254, on dmz
arp-set: added arp dmz 194.1.1.2 30e4.db22.7181 and updating NPs at 2925140
arp-in: generating reply from 194.1.1.254 001d.454c.2364 to 194.1.1.2 30e4.db22.7181
 

Команда статического NAT в конфигурации обеспечивает, что ASA отвечает на ARP-запросы маршрутизатора ISP, который считает, что 194.1.1.2 находится в его локальном сегменте (первая часть debug).

Команда "arp dmz..." в конфигурации необходима, чтобы ASA ответила на ARP-запрос DMZ-сервера 194.1.1.2, который также думает, что маршрутизатор ISP находится в локальном сетевом сегменте (вторая часть debug). MAC 001d.454c.2364 – это MAC-адрес DMZ-интерфейса ASA.

Т.о., ASA не выполняет proxy ARP по умолчанию. Необходим либо статический identity NAT (без ключа "no-proxy-arp" в команде), либо статическая ARP-запись. Использование proxy ARP позволяет решить поставленную задачу без потери IP-адресов.

 

Задача 3

Сообщение-решение:

 

%ADJ-5-PARENT: Midchain parent maintenance for IP midchain out of Tunnel0, addr 172.16.1.2 (incomplete) - looped chain attempting to stack

свидетельствует о том, что CEF обнаружил петлю маршрутизации. Очевидно, что эта петля не на уровне IPSec, поскольку IPSec peer 212.1.1.2 гарантированно доступен с DMVPN Hub по маршруту по умолчанию. Проблема находится на уровне GRE, который используется для промежуточной инкапсуляции трафика, передаваемого по DMVPN:

! Hub
show ip route
 
D     192.168.0.0/22 [90/26882560] via 172.16.1.2, 12:31:47, Tunnel0
 
show ip nhrp       
 
172.16.1.2/32 via 172.16.1.2
   Tunnel0 created 00:37:20, expire 00:04:17
   Type: dynamic, Flags: unique registered used
   NBMA address: 192.168.0.2

 

Этот вывод, по-сути, означает, что с т.зр. GRE, сеть 192.168.0.0/22 доступна через 192.168.0.2 (NBMA address), т.е. сеть доступна через адрес из этой же сети, а это и есть "петля". При промежуточной инкапсуляции в GRE в поле Destination-IP дополнительного IP-заголовка действительно заносится адрес 192.168.0.2. В подобных случаях процесс CEF формирует т.н. "drop adjacency":

! Hub
show ip cef 192.168.0.0 255.255.252.0 internal
 
192.168.0.0/22, epoch 0, flags cover dependents, RIB[I], refcount 7, per-destination sharing
  sources: RIB
  feature space:
   IPRM: 0x00028000
  subblocks:
   Covered dependent prefixes: 1
     notify cover updated: 1
  ifnums:
   Tunnel0(5): 172.16.1.2
  path 67E73EE0, path list 67FFE0F8, share 1/1, type attached nexthop, for IPv4
  nexthop 172.16.1.2 Tunnel0, adjacency IP midchain out of Tunnel0, addr 172.16.1.2 698C88A0
  output chain: IP midchain out of Tunnel0, addr 172.16.1.2 698C88A0 drop

 

(Обратите внимание на "drop" в конце вывода). Если CEF выключить с помощью "no ip cef", то ничего подобного не происходит, поскольку Process Switching ничего подобного не делает, а физически никакой петли нет (точнее эта мнимая петля исчезает, как только при инкапсуляции в IPSec (ESP) добавляется новый IP-заголовок, где в качестве адреса получателя будет 212.1.1.2).

Очевидно, что проблема вызвана тем, что мы включили адрес внешнего интерфейса Spoke в суммаризацию на Spoke. Проблема исчезнет, если суммаризацию отключить.

Можно ли сохранить суммаризацию? Да, если вместо туннельного режима IPSec настроить транспортный режим:

 

crypto ipsec transform-set SET1 esp-3des esp-md5-hmac
 mode transport require

 

В этом случае дополнительный IP-заголовок при инкапсуляции в GRE формироваться не будет (будет сформирован только дополнительный IP-заголовок при инкапсуляции в ESP) и 192.168.0.0/22 станет доступна через 212.1.1.2:

! Hub
show ip route
 
D     192.168.0.0/22 [90/26882560] via 172.16.1.2, 12:31:47, Tunnel0
 
show ip nhrp
 
172.16.1.2/32 via 172.16.1.2
   Tunnel0 created 00:02:53, expire 00:03:47
   Type: dynamic, Flags: unique registered
   NBMA address: 212.1.1.2
    (Claimed NBMA address: 192.168.0.2)

Т.о., это еще одна причина, почему транспортный режим IPSec всегда рекомендуется использовать в DMVPN-сетях.

 

Задача 4

Причина: SYN flood или DOS-атака

Решение: настройка лимита на embryonic connection

 

День 3: Видео и голосовая связь

 

Задача 1

Решение: Как видно из дебагов, CME отправляет сообщение Ringing без SDP, что является одним из двух возможных сценариев обработки контроля посылки вызова.

Второй сценарий - inband audio, в данной конфигурации CME отправлять не умеет.

Возможно сеть провайдера, либо сеть вызывающего абонента некорректно отрабатывают сценарий без inband audio и согласования Early Media.

До смены протокола c H.323 на SIP КПВ обрабатывался корректно.

После обращения к провайдеру проблема была локализована и устранена.

 

Задача 2

Решение: Вызов рассоединяется по таймауту при попытке перевести вызов с DN CTIRP на DN CTI порта.

Это может быть вызванно разными причинами – как например отсутсвием partition CTI порта в CSS CTIRP, так и например тем что CTI порт был удален.

 

Правильный ответ  - вот эти строчки из лога CUCM, о том что CUCM в DA запросе при редиректе вызова с CTI RP на CTI порт - не находит маршрут для коммутации вызова.

 

03729757.001 |15:59:22.934 |AppInfo  |Digit Analysis: star_DaReq: daReq.partitionSearchSpace(:2422ae85-46cb-c0eb-ace6-c65ff7412dd7), filteredPartitionSearchSpaceString(HR_pt), partitionSearchSpaceString(HR_pt)
03729757.002 |15:59:22.934 |AppInfo  |Digit Analysis: star_DaReq: Matching Legacy Numeric, digits=8009951
03729757.003 |15:59:22.934 |AppInfo  |Digit Analysis: getDaRes data: daRes.ssType=[0] Intercept DAMR.sstype=[0], TPcount=[0], DAMR.NotifyCount=[0], DaRes.NotifyCount=[0]
03729757.004 |15:59:22.934 |AppInfo  |Digit analysis: patternUsage=2
03729757.005 |15:59:22.934 |AppInfo  |Digit analysis: match(pi="1",fqcn="5555", cn="5555", plv="5", pss="HR_pt", TodFilteredPss="HR_pt", dd="8009951",dac="0")
03729757.006 |15:59:22.934 |AppInfo  |Digit analysis: potentialMatches=NoPotentialMatchesExist
 

Задача 3

Решение: Для звонков, в которых нужно проводить донабор (голосове меню), появляется потребность согласования DTMF.

Так как со у телефона и шлюза поддерживаются разные DTMF-Relay, то возникает необходимочть задействовать MTP для преобразования DTMF.

В итоге при задействовании транскодера, мы получаем ситуацию, когда происходит преобразование из g711 в g711 кодек.

Всю эту информацию можно найти в SDI/SDL трейсах.

Как известно в обычной конфигурации «железный» транскодер не поддерживает подобного преобразования.

Для решения проблемы нужно настроить Universal transcoder:

http://www.cisco.com/c/en/us/td/docs/ios/12_4t/12_4t15/it_unitr.html

 

После настройки проблема была решена.

 

Задача 4

Решение: Поскольку взаимодействие между клиентом Jabber Video и VCS идет по протоколу TLS, то в дампе пакетов мы его прочитать на сможем и начать нужно с лога VCS. Там виден весь обычный диалог для получения конфигурации устройством, начиная с SIP SUBSCRIBE на адрес provisioning@video.lab и заканчивая сообщением SIP NOTIFY с конфигурацией клиента. Мы также видим SIP OK в ответ на NOTIFY - значит клиент конфигурацию получил. После этого мы ожидаем увидеть от клиента SIP REGISTER, но вместо этого снова приходит SUBSCRIBE на provisioning. Дальше нужно смотреть, что происходит на клиенте, но сначала возьмем его конфигурацию из SIP NOTIFY:

 

<?xml version="1.0" encoding="UTF-8"?>
<ProvData xmlns="http://www.tandberg.net/Provisioning/2/">
   <Services item="1">
      <PhoneBook item="1">
         <URL item="1">phonebook@video.lab</URL>
      </PhoneBook>
      <Sip item="1">
         <URL item="1">vcs-c.video.lab</URL>
         <SignOnUri item="1">Mike.movi@video.lab</SignOnUri>
      </Sip>
      <Presence item="1">
         <URL item="1">presence@video.lab</URL>
      </Presence>
   </Services>
   <Configuration item="1">
      <DisplayName item="1">Mike</DisplayName>
   </Configuration>
</ProvData>

 

В теге Sip клиент получил адрес VCS, на котором он должен регистрироваться, поэтому в дампе пакетов нужно смотреть, что происходит с этим адресом. В дампе мы видим DNS запросы на SIP SRV записи для этого сервера (пакеты 36, 38, 40), но DNS сервер отвечает на них - No such name. Варианта два - либо неправильно настроен DNS, либо в конфигурации неправильное имя сервера, поэтому мы смотрим конфиг VCS и видим:

   *c xConfiguration IP DNS Domain Name: "video.lab"

   *c xConfiguration IP DNS Hostname: “vcsc”

т.е. реальное имя сервера отличается от того, что получил клиент.

 

Соответственно, правильный ответ на задачу:

На сервере TMS в настройках Provisioning (Systems > Provisioning > Directory) для данного клиента (или его группы) нужно изменить параметр SIP Server Address на “vcsc.video.lab”.

 

Задачи:

"Следствие ведут ИТ-шники". День 1: Маршрутизация и коммутация.

"Следствие ведут ИТ-шники". День 2: Информационная безопасность.

"Следствие ведут ИТ-шники". День 3: Видео и голосовая связь.

 

История версий
Редакция №
1 из 1
Последнее обновление:
‎12-29-2014 02:35 AM
Автор обновления:
 
Теги (2)
Комментарии

Отличный конкурс, почаще бы такие проводили, ну или хотя бы ввести в предновогоднюю традицию. Большое спасибо организаторам за труды, тяжело, наверное, было вычитывать поток мыслей в ответах участников. От себя просьба - можно ли разместить изначальные задания? Сохраню себе для истории, неоторые с удовольствием применял бы на собеседовании кандидатов.

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

New Member

Здравствуйте!

А сохранились ли где-то упоминания о победителях?