return

Ответ к задаче №9.1

18 мая 2016, 21:10

R1#

ip forward-protocol udp 10999
ip access-list extended BR-to-MULT
permit udp any any eq 10999
interface Ethernet0/0
description to SERVER
ip multicast helper-map broadcast 239.9.9.9 BR-to-MULT

R5#

ip access-list extended BR-to-MULT
permit udp any any eq 10999
interface Ethernet0/1
description to R3
ip multicast helper-map 239.9.9.9 192.168.5.255 BR-to-MULT
interface Ethernet0/0
description to CLIENT2
ip directed-broadcast

===========================
Проверка: Для того чтобы проверить преобразование пакетов, нам нужно сгенерировать UDP пакеты на порт 10999 и IP 255.255.255.255.
К сожалению, в IP SLA уже нет возможности так сделать, поэтому, для проверки, мы воспользуемся DNS-запросами, которые отправляет IOS, когда мы неправильно вводим команду.
Для этого нам нужно добавить на R1 и R5 в ACL строку:

ip access-list extended BR-to-MULT
permit udp any any eq 10999
permit udp any any eq domain

На R6 (маршрутизаторе, который у нас в роли сервера) надо включить:

ip domain-lookup

Сначала проверим получает ли клиент 1 мультикаст.
Для этого, на интерфейсе клиента, который смотрит на R4 (в роли клиента тоже маршрутизатор), настроим:

interface Ethernet0/0
ip address 192.168.4.2 255.255.255.0
ip igmp join-group 239.9.9.9

Теперь на клиенте 1 включаем debug ip packet. И на сервере набираем неправильную команду:

SERVER#ds
Translating "ds"...domain server (255.255.255.255)
(255.255.255.255)
Translating "ds"...domain server (255.255.255.255)
% Bad IP address or host name
% Unknown command or computer name, or unable to find computer address

На клиенте 1 видим:

CLIENT1#
IP: s=172.16.0.5 (Ethernet0/0), d=239.9.9.9, len 48, input feature, MCI Check(82), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
IP: s=172.16.0.5 (Ethernet0/0), d=239.9.9.9, len 48, rcvd 2
IP: s=172.16.0.5 (Ethernet0/0), d=239.9.9.9, len 48, stop process pak for forus packet
IP: s=172.16.0.5 (Ethernet0/0), d=239.9.9.9, len 48, input feature, MCI Check(82), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
IP: s=172.16.0.5 (Ethernet0/0), d=239.9.9.9, len 48, rcvd 2
IP: s=172.16.0.5 (Ethernet0/0), d=239.9.9.9, len 48, stop process pak for forus packet
CLIENT1#

Мы видим, что к клиенту 1 пакеты приходят с адресом отправителя 172.16.0.5 и получателем 239.9.9.9.
Соответственно, на промежуточных устройствах, например, на R2:

R2#sh ip mroute 
...
(*, 239.9.9.9), 02:23:06/stopped, RP 2.2.2.2, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 02:05:01/00:03:21
Ethernet0/2, Forward/Sparse, 02:21:18/00:02:52
(172.16.0.5, 239.9.9.9), 00:00:03/00:03:29, flags: T
Incoming interface: Ethernet0/1, RPF nbr 10.0.12.1
Outgoing interface list:
Ethernet0/2, Forward/Sparse, 00:00:03/00:03:26

Теперь проверим приходит ли к клиенту 2 бродкаст.
Аналогичным образом на клиенте 2 включаем debug ip packet. И на сервере набираем неправильную команду.
На клиенте 2 получаем:

CLIENT2#
IP: s=172.16.0.5 (Ethernet0/0), d=255.255.255.255, len 48, input feature, MCI Check(82), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
IP: s=172.16.0.5 (Ethernet0/0), d=255.255.255.255, len 48, rcvd 2
IP: s=172.16.0.5 (Ethernet0/0), d=255.255.255.255, len 48, stop process pak for forus packet
IP: s=172.16.0.5 (Ethernet0/0), d=255.255.255.255, len 48, input feature, MCI Check(82), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
IP: s=172.16.0.5 (Ethernet0/0), d=255.255.255.255, len 48, rcvd 2
IP: s=172.16.0.5 (Ethernet0/0), d=255.255.255.255, len 48, stop process pak for forus packet
CLIENT2#

Мы видим, что к клиенту 2 пакеты приходят с адресом отправителя 172.16.0.5 и получателем 255.255.255.255.

Вывод debug ip packet на R5:
R5#

IP: s=172.16.0.5 (Ethernet0/1), d=239.9.9.9, len 48, input feature, MCI Check(82), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
IP: tableid=0, s=172.16.0.5 (Ethernet0/1), d=192.168.5.255 (Ethernet0/0), routed via RIB
IP: s=172.16.0.5 (Ethernet0/1), d=255.255.255.255 (Ethernet0/0), len 48, sending full packet
like 0 views 6432 message 4

4 коментария

  • Интересно, что маршрутизатор не отправляет полученный волшебной командой пакет, а ещё раз менает ему dst адрес на 255.255.255.255
    Это видимо wellknown поведение и поэтому вопрос не отновсится к этой задаче. Но почему?

    16 декабря 2020, 14:28
  • Мне было бы удобнее видеть в description’ах «from», а не «to».

    16 декабря 2020, 14:15
  • Дмитрий Максименко

    На R5 забыли ip forward-protocol udp 10999

    22 мая 2019, 04:11
  • Дмитрий Максименко

    и еще интерфейсы почему-то Ethernet вместо FastEthernet

    22 мая 2019, 04:15

Ещё статьи

linkmeup 4 года
Мы отсчитываем возраст проекта от даты публикации на Хабре нулевого выпуска. Итак, какова статистика за такой огромный период? 12 выпусков СДСМ. 421 564 Посетителей. 3,4 млн Просмотров. 22 Запроса в секунду в ...
like 0 110 0
20 декабря 2015
Вебинар на тему: «Основы маршрутизации/CEF»
UPD2: По многочисленным жалобам на Youtube и его 480р, оригинал: Просмотреть в оригинале (с помощью Webex) Скачать оригинал в формате .arf для оффлайн просмотра UPD: Вебинар состоялся. В среду 4 ...
like 234 4604 2
3 мая 2016
Анонс подкаста. Выпуск 57 \\\\\12.11.2017 13:00 МСК
Онлайн Трансляция Настал тот прекрасный день, когда товарищ майор разрешил, но хитро прищурив глаз пообещал приглядывать… В следующем выпуске мы затронем тему, которая потребует от нас очень тщательно подбирать вопросы, ...
like 0 3406 0
31 октября 2017