Basics of routing & switching: Multicast

3,051 views
2,922 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,051
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
66
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Basics of routing & switching: Multicast

  1. 1. Basics of Switching & Routing Разработка: Владимир Литовка doka.ua@gmail.com http://doka-ua.blogspot.com/ Этот документ доступен по лицензии Creative Commons «Attribution-NonCommercial-ShareAlike» 3.0 Непортированная (http://creativecommons.org/licenses/by-nc-sa/3.0/deed.ru)Switching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  2. 2. Multicast R&S   Основы Milticast   PIM Dense Mode   PIM Sparse Mode o  Auto-RP o  BSR   IGMP v2   MBGP for Multicast   MVR   MSDP o  Anycast RP   PIM-SSM   IGMP v3   IGMP v2 / SSM interoperabilitySwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  3. 3. Multicast Routing & SwitchingSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  4. 4. Что такое Multicast Источник Unicast Источник MulticastSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  5. 5. Преимущества Multicast   Высокая эффективность o  трафик получают и обрабатывают только те, кто его явно запросил   Масштабируемость o  объем трафика не растет вместе с абонентами o  нагрузка на устройства не растет вместе с абонентами 0.8 0.6 Traffic Multicast 0.4 Mbps Unicast 0.2 0 1 20 40 60 80 100 # ClientsSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  6. 6. Недостатки Multicast Multicast-трафик передается поверх UDP   негарантированная доставка при нештатных ситуациях в сети возможны потери пакетов   слабый контроль за использованием ресурсов сети отсутствие механизмов TCP windowing и “slow-start” могут вызвать перегруженность каналов связи   дублирование данных   неупорядоченное получение данных при нештатных ситуациях в сети возможны дублирование или приход пакетов не в той последовательности, в которой они были отправлены источником Приложения Multicast должны отрабатывать нештатные ситуации самостоятельноSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  7. 7. Семейство протоколов Multicast IGMP HDTV AS101 PIM   MBGP   MSDP IGMP Snooping AS100 HDTV IGMPSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  8. 8. Адресация Multicast Sender & Receiver   Каждая multicast-группа идентифицируется Group 2 Member Class-D адресом Sender   Для получения данных абонент должен быть участником группы Non-Group Member   Данные, посылаемые в группу, будут получены всеми участниками группы   Для посылки данных в группу отправитель не должен быть Group 1 Group 1&2 участником группы Member Member   Адрес источника никогда не Receiver Receiver может быть Class-D адресомSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  9. 9. Адресация Multicast (ч.2) Class D: 224.0.0.0 – 239.255.255.255   Reserved Link-Local Addresses : 224.0.0.0 – 224.0.0.255 Передаются с TTL=1 Пример: 224.0.0.5 – OSPF routers   Other Reserved Addresses : 224.0.1.0 – 224.0.1.255 Передаются с TTL>1 Пример: 224.0.1.1 – Network Time Protocol   Global Scope Addresses : o  232.0.0.0 – 232.255.255.255 – Source Specific Multicast o  233.0.0.0 – 233.255.255.255 – Static Global Group Address Assignment •  AS Number вставляется в два средних октета •  нижний октет используется для распределения между группами •  RFC 2770 и draft-ietf-mboned-glop-addressing-xx.txt   Administrative Scope Addresses : 239.0.0.0-239.255.255.255 Аналог RFC1918 для Unicast-адресов, зарезервированы для использования в закрытых (private) сетяхSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  10. 10. Well-known groups Некоторые из назначенных Multicast-групп: Группа Описание 224.0.0.1 All Hosts 224.0.0.2 All Routers 224.0.0.5 OSPF AllSPFRouters 224.0.0.6 OSPF AllDRouters 224.0.0.9 RIPv2 224.0.0.13 PIMv2 224.0.0.18 VRRP 224.0.0.22 IGMPv3 Routers 224.0.1.39 Cisco AUTO-RP-ANNOUNCE 224.0.1.40 Cisco AUTO-RP-DISCOVERY http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xmlSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  11. 11. Адресация Multicast (ч.3) 32 Bits В Class-D IP-адресе верхние 4 бита всегда 1110, для идентификации группы остается 1110 28 Bits 28 бит Блок адресов 01-00-5e делегирован 239.255.0.1 5 Bits IANA, из них половина (23 бита) Lost 0100.5E-00.0000 – 0100.5E-7F.FFFF распределена для адресации Multicast в Ethernet-сетях 01-00-5e-7f-00-01 25 Bits 23 Bits Таким образом, при трансляции 48 Bits IP-адреса в Ethernet-адрес теряются верхние 5 бит адреса и при проектировании сети следует учитывать этот факт (пересечение адресов 32:1). Например, адреса: 224.10.0.1 (11100000.00001010.00000000.00000001) 225.138.0.1 (11100000.10001010.00000000.00000001) будут транслироваться в одинаковый MAC-адрес 01-00-5E-0A-00-01. http://www.multicast.org.uk/address-tools/Switching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  12. 12. Shortest Path Tree (SPT) Sender 2   Кратчайший путь (lowest cost) Sender 1 между источником и получателями   Пересылка трафика осуществляется по двум параметрам – адресу источника (Source) и адресу группы (Group), поэтому описание дерева выглядит следующим образом: (S,G)   Каждое дерево строится на основе адреса источника и адреса группы, поэтому для каждой пары Receiver 1 Receiver 2 строится свое деревоSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  13. 13. Rendezvous Point Tree (RPT) Sender 2   Также известно как Shared Path Tree   В общем дереве multicast-потоки от нескольких источников собираются в Rendezvous единую точку – Rendezvous Point (RP) – Point (RP) из которой далее пересылаются получателям потоков. Sender 1   Поскольку источники потоков скрыты, то пересылка трафика осуществляется по одному параметру (Группе), вне зависимости от адреса источника и описание дерева выглядит следующим образом: (*,G)   Источник регистрируется на RP Receiver 1 Receiver 2 (посылкой соответствующего Register Message) и RP регистрируется в SPT к источнику. Source Tree Shared TreeSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  14. 14. Multicast Forwarding Для пересылки Multicast-трафика используется пара (S,G), а получатель неизвестен Механизмы управления доставкой трафика:   Reverse Path Forwarding (RPF) транзитный маршрутизатор пересылает полученный multicast-пакет только в том случае, если источник трафика доступен через интерфейс, с которого данный пакет получен   TTL Threshold административное ограничение по TTL multicast-пакета   Administrative Boundary ограничение по разрешенным в заданной части сети multicast-группамSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  15. 15. Reverse Path Forwarding   В таблице Unicast-маршрутизации блок адресов 151.10.0.0/16 маршрутизируется S=151.10.7.11 через интерфейс S1.   Multicast-пакет с адресом S1 узла-отправителя 151.10.7.11, S2 пришедший из интерфейса S0, будет S0 без предупреждения отброшен. E0   Multicast-пакет с адресом Router#sh ip route узла-отправителя 151.10.7.11, […] пришедший из интерфейса S1, O IA 150.10.0.0/16 via x.x.x.x, Serial1 будет переправлен в каждый интерфейс, где находятся абоненты данной multicast-группы.   Никакие multicast-пакеты никогда не будут отправлены в тот интерфейс, с которого были получены.Switching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  16. 16. Выбор маршрута для RPF   Если маршрут доступен из двух и более источников, выбор основывается на administrative distance каждого источника, с учетом Multicast-расширений Таблица, из которой Administrative Distance известен источник Unicast (Distance of route) iMBGP 200 eMBGP 20 DVMRP 0 Static mroute 0Switching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  17. 17. TTL Threshold   TTL Threshold задается на каждом интерфейсе. Значение по-умолчанию TTL = 24 – 0 (нет установленного лимита).   У всякого входящего пакета значение TTL уменьшается на S1 единицу. Если результат <= 0, S2 то пакет отбрасывается. S0 TTL Th = 16 TTL Th = 64   Если получившееся значение E0 TTL >= установленного на исходящем TTL Th = 0 интерфейсе лимита, то пакет форвардится в этот интерфейс.   Если получившееся значение TTL < установленного на исходящем интерфейсе лимита, то пакет отбрасывается.Switching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  18. 18. Administrative Boundary Administrative Boundary = 239.0.0.0/8 239.x.x.x multicast 239.x.x.x multicast packets packets S0 S1   Конфигурируется командой “ip multicast boundary <acl>” на заданном интерфейсе   Определяет набор multicast-групп, потоки из которых не будут пересекать границу (boundary) ни в одном из направленийSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  19. 19. Построение Multicast Distribution Tree в сетях IPSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  20. 20. Протоколы построения дерева   Dense Mode (push model) o  По умолчанию трафик распространяется по всей сети o  Маршрутизаторы, у которых нет получателей multicast-трафика, в явном виде отказываются от этого трафика o  Процесс пересылки и отказа от трафика повторяется периодически o  Протоколы PIM-DM, DVMRP, MOSPF   Sparse Mode (pull model) o  Маршрутизаторы явно запрашивают multicast-трафик при возникновении активных получателей o  Трафик пересылается только в те фрагменты сети, где есть активные получатели o  Протокол PIM-SMSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  21. 21. PIM Dense Mode (PIM-DM)   Не зависит от протоколов маршрутизации дерево строится на основе таблицы маршрутизации узла и неважно, как она сформирована   Shortest Path Tree, строится на основе механизма Flood / Prune / Graft o  multicast-трафик «разливается» по всей сети o  узлы без подписчиков отказываются от трафика o  при появлении подписчиков – заказывают трафик   Flood / Prune периодически повторяется o  PIM State-Refresh – периодическая посылка Prune Refresh сообщений с ближайшего к источнику узла   Механизм Assert для избежания дублирования http://www.faqs.org/rfcs/rfc3973.htmlSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  22. 22. PIM-DM operations Source   Информация о состоянии (S, G) создается на каждом Multicast Packets маршрутизаторе сети Prune Messages   После окончания процесса After “Prune” flow Flood-Prune информация (S, G) все равно остается на каждом Receiver 1 маршрутизаторе сети http://www.faqs.org/rfcs/rfc3973.htmlSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  23. 23. PIM-DM operations (ч.2) Source Receiver 2 Graft Message Receiver 1 http://www.faqs.org/rfcs/rfc3973.htmlSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  24. 24. PIM-DM Assert   При детектировании петли граничные маршрутизаторы Assert Message шлют в сегмент сообщение Assert   Assert содержит metric и administrative distance до источника o  побеждает (Assert Winner) лучший путь до источника o  или – наибольший (highest) IP-address o  прочие узлы (Assert Losers) прекращают посылки Dec 9 00:40:53: PIM(0): Send v2 Assert on FastEthernet0/1 for 239.1.1.1, source 100.2.0.2, metric [110/20] Dec 9 00:40:53: PIM(0): Assert metric to source 100.2.0.2 is [110/20] Dec 9 00:40:53: PIM(0): Received v2 Assert on FastEthernet0/1 from 1.1.1.1 Dec 9 00:40:53: PIM(0): Assert metric to source 100.2.0.2 is [0/0] Dec 9 00:40:53: PIM(0): We lose, our metric [110/20] Dec 9 00:40:53: PIM(0): Prune FastEthernet0/1/239.1.1.1 from (100.2.0.2/32, 239.1.1.1)Switching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  25. 25. PIM-DM Assert   При детектировании петли граничные маршрутизаторы Assert Message шлют в сегмент сообщение Assert В случае выхода из строя Assert   Assert содержит metric и administrative distance Winner подача трафика в сегмент до источника o  прекращается до следующей o  побеждает (Assert Winner) лучший путь до источника или – наибольший (highest) IP-address итерации Assert o  прочие узлы (Assert Losers) прекращают посылки Dec 9 00:40:53: PIM(0): Send v2 Assert on FastEthernet0/1 for 239.1.1.1, source 100.2.0.2, metric [110/20] Dec 9 00:40:53: PIM(0): Assert metric to source 100.2.0.2 is [110/20] Dec 9 00:40:53: PIM(0): Received v2 Assert on FastEthernet0/1 from 1.1.1.1 Dec 9 00:40:53: PIM(0): Assert metric to source 100.2.0.2 is [0/0] Dec 9 00:40:53: PIM(0): We lose, our metric [110/20] Dec 9 00:40:53: PIM(0): Prune FastEthernet0/1/239.1.1.1 from (100.2.0.2/32, 239.1.1.1)Switching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  26. 26. PIM-DM State Refresh Next-Hop to source PIM-node Receiver 2 Source State-Refresh message Сообщение State Refresh reset Prune timer включает метрику до источника. Таким образом, исчезает надобность в периодическом re-Assert Receiver 1 http://www.faqs.org/rfcs/rfc3973.htmlSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  27. 27. Прочие Dense-mode протоколы   DVMRP o  собственная таблица маршрутизации (Truncated Broadcast Tree, TBT) o  RIP-like протокол формирования таблицы •  максимальное количество хопов – 32 •  медленная сходимость   Multicast OSPF (MOSPF) o  требует OSPF в сети o  расчет дерева для каждой пары (S, G)   Общие недостатки Dense-mode протоколов: o  не поддерживается Shared Tree o  больший объем маршрутной информации ( F[S*G] ) o  периодические всплески трафика (Flood / Prune)Switching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  28. 28. PIM Sparse Mode (PIM-SM)   Не зависит от протоколов маршрутизации дерево строится на основе таблицы маршрутизации узла и неважно, как она сформирована   Передача трафика по явному запросу (Pull Mode)   Понятие Rendezvous Point (RP) – точка сбора трафика от источников для передачи получателям: o  источник регистрируется на RP, между источниками и RP – Shortest Path Tree (SPT) o  получатели регистрируются на RP, между получателями и RP – Rendezvous Point Tree (RPT)   Возможность резервирования RP   Возможность переключения на SPT непосредственно между получателем и источникомSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  29. 29. PIM-SM operations Register (S,G) 2 Register-Stop 6 Rendezvous 5 Point Source 1 5 NHS 4 1.  При появлении трафика ближайший к источнику (next-hop to source, NHS) PIM-узел (2) регистрируется на RP [ … сеть ждет первого получателя …] 4 3.  IGMP Join (*, G) 4.  PIM Join (*, G) в сторону RP 5.  PIM Join (S, G) в сторону NHS 3 6.  Построенное дерево: Receiver 1 o  SPT между источником и RP o  RPT между RP и получателемSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  30. 30. PIM Join/Prune Messages   Multicast Source Address o  адрес источника multicast-потока o  если установлен флаг WC, то – адрес Rendezvous Point   Multicast Group Address   WC-bit (Wildcard flag) o  индикатор (*,G)   RP-bit (RP Tree flag) o  запрос должен форвардиться вверх по RPT в направлении Rendezvous Point o  используется для отказа от трафика RPT при переключении на SPTSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  31. 31. PIM-SM operations (ч.2) B0#sh ip mroute IP Multicast Routing Table Rendezvous Flags: P - Pruned, F - Register flag, [ … ] NHS Point (*, 239.1.1.1), 00:09:42/stopped, RP 2.2.0.6, flags: SPF Incoming interface: POS2/0, RPF nbr 2.2.0.6 Outgoing interface list: Null (100.2.0.2, 239.1.1.1), 00:09:42/00:02:14, flags: FT Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Source POS2/0, Forward/Sparse, 00:09:42/00:02:38 Z0#sh ip mroute IP Multicast Routing Table Flags: T - SPT-bit set [ … ] (*, 239.1.1.1), 00:04:41/stopped, RP 2.2.0.6, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Receiver 1 Outgoing interface list: POS3/0, Forward/Sparse, 00:04:41/00:02:43 (100.2.0.2, 239.1.1.1), 00:00:11/00:02:59, flags: T D0#sh ip mroute Incoming interface: POS2/0, RPF nbr 2.2.0.2 IP Multicast Routing Table Outgoing interface list: Flags: S - Sparse, C - Connected, POS3/0, Forward/Sparse, 00:00:11/00:02:48 [ … ] (*, 239.1.1.1), 00:00:02/00:02:59, RP 2.2.0.6, flags: SC Incoming interface: POS3/0, RPF nbr 2.2.0.6 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:00:02/00:02:59Switching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  32. 32. PIM flags S Sparse Mode Группа работает в режиме Sparse D Dense Mode Группа работает в режиме Dense C Connected Участники группы непосредственно подключены L Local Узел сам по себе является участником группы P Pruned Outgoing Interface List пуст T SPT flag Соответствует записям (S, G) Join SPT Превышен порог переключения на SPT. Следующий пакет, J для (*, G) пришедший по (*,G) вызовет переключение на (S,G) Join SPT Было переключение с (*,G) на (S,G). При трафике ниже J для (S, G) порога произойдет возврат на (*,G) F Register flag По этой записи генерируются Register-* сообщения. R RP flag on (S, G) RP-bit flagSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  33. 33. PIM-SM switchover Rendezvous Source Point Join (S,G) NHS   Next-Hop to Receiver (NHR) может переключиться на SPT при o  обнаружении источника NHR o  и превышении порога трафика в RPT NOTE: значение порога по умолчанию – 0 Receiver 1   NHR шлет PIM Join (S, G) в сторону NHSSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  34. 34. PIM-SM switchover (ч.2) Rendezvous Source Point Prune (S,G) NHS Prune (*,G) При построении SPT и получении трафика в нем: NHR   NHR шлет PIM Prune (*, G) в сторону RP o  если RPT не нужен – исчезает   RP шлет PIM Prune (S, G) в сторону NHS Receiver 1 o  если SPT не нужен - исчезаетSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  35. 35. PIM-SM switchover (ч.3) Rendezvous Source Point NHS После переключения c RPT на SPT, узел NHR “Rendezvous Point” продолжает функционировать и для обслуживания новых подключений Receiver 1Switching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  36. 36. Designated Router Election   Если в сегменте более одного PIM-узла, то происходит выбор одного из них на роль Designated PIM Hello   Designated Router – единственный в сегменте, который шлет PIM Join / Prune для этого сегмента   Побеждает PIM-узел (Designated Router) с o  наибольшим приоритетом o  или – наибольшим (highest) IP-адресом   Если Designated Router выходит из строя, то по истечении timeout происходят новые выборы DR o  до выборов нового DR трафик в сегмент не поступаетSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  37. 37. Идентификация Rendezvous Point в сетиSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  38. 38. Идентификация RP в сети   Статическая o  ip pim rp-address … o  … на каждом PIM-узле o  все недостатки статической конфигурации   Auto-RP o  Cisco Proprietary o  поддерживает PIM v1/v2 o  резервирование RP o  требует Dense Mode для используемых групп   Bootstrap Router (BSR) o  стандартный механизм o  резервирование PR и балансировка нагрузки o  только PIM v2 o  использует 224.0.0.13 (All-PIM-Routers) для работыSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  39. 39. Auto-RP operations   Candidate-RP (C-RP) o  список обслуживаемых групп определяется конфигурацией o  RP-Announcements в группу 224.0.1.39 (Cisco Announce) с соответствием RP / Group List   Настройка C-RP ip pim send-rp-announce <interface> scope <ttl> group-list ? <1-99> Access-list reference for multicast groups WORD IP Named Standard Access list Правило здравого смысла: используйте Loopback для идентификации C-RPSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  40. 40. Auto-RP operations (ч.2)   Mapping Agent (MA) o  подписан на группу «Cisco Announce» o  выбирает RP для каждого списка групп победитель – Candidate-RP с highest IP address o  анонсирует финальный результат в группу 224.0.1.40 (Cisco Discovery) o  все PIM-узлы подписаны на «Cisco Discovery»   Настройка MA ip pim send-rp-discovery <interface> scope <ttl> ip pim rp-announce-filter rp-list <acl> group-list <acl> Правило здравого смысла: используйте Loopback для идентификации MASwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  41. 41. Auto-RP Dense Mode   Проблема курицы и яйца   Группы «Cisco Announce» и «Cisco Discovery» требуют Dense Mode   Два способа: o  Глобальная конфигурация: Z0(config)#ip pim autorp listener o  Конфигурация на каждом, участвующем в PIM, интерфейсе: Z0(config-if)#ip pim sparse-dense-modeSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  42. 42. BSR Operations   Candidate-RP o  Список обслуживаемых групп определяется конфигурацией o  C-RP-Advertisement – выбранному BSR, unicast-сообщением выбранный BSR анонсируется через группу «All-PIM- Routers» (224.0.0.13) o  Настройка C-RP ip pim rp-candidate <interface> ? group-list group-list (список обслуживаемых групп) interval RP candidate advertisement interval (TTL) priority RP candidate prioritySwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  43. 43. BSR Operations (ч.2)   Candidate-BSR (C-BSR) o  содержит полный список C-RP’s в домене o  рассылает список C-RP’s в группу «All-PIM- Routers» (224.0.0.13) o  все PIM-узлы самостоятельно выбирают RP для списка группа поскольку алгоритм выбора строго определен, то все узлы получают в результате расчета одинаковый результат o  использование механизма хэширования для балансировки нагрузки между RP’sSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  44. 44. BSR Operations (ч.3)   Настройка C-BSR ip pim bsr-candidate <interface> <hash_mask_len> <priority> где: o  Hash Mask Length определяет количество последовательных групп, которые будут отображаться на RP при балансировке, напр. 32 – hash_mask_len == 2бита == 4 группы o  Priority определяет приоритет C-BSR при выборах. Чем выше значение – тем выше приоритет при одинаковом приоритете – higher IP address   Граница домена для сообщений BSR Router(config-if)#ip pim bsr-borderSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  45. 45. PIM-SM: выводы   Оптимальное использование ресурсов сети: o  простой эффективный алгоритм построения дерева o  использование существующей unicast routing table o  возможность переключения от RPT к SPT   Механизмы резервирования Rendezvous Points o  регистрация в сети новых источников и их доступность для получателей не будут прерываться   Основа для PIM-SSM   Основа для Inter-Domain Multicast Routing o  При использовании с MBGP, MSDP Multicast-сети практически любой сложности могут быть построены с использованием PIM-SMSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  46. 46. Построение Multicast Distribution Tree в сетях EthernetSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  47. 47. Internet Group Messaging Protocol С помощью протокола Internet Group Management Protocol (IGMP) абонентские устройства (компьютер, Set-Top-Box (STB) и другие) сообщают о своем желании подключиться к multicast-группе, которая распространяется по IP-сети   RFC 1112 описывает первую (устаревшую) версию   RFC 2236 описывает IGMP v2 – наиболее широко распространенная версия   RFC 3376 описывает IGMP v3 TTL = 1 IGMP не передается за пределы сегментаSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  48. 48. IGMP v2: заголовок 7 15 31   Type: Type Max. Resp. Checksum 0x11 = Group Membership Query Time 0x12 = Version 1 Membership Report Group Address 0x16 = Version 2 Membership Report 0x17 = Leave Group   Maximum Response Time максимальное время, которое дается абонентским устройствам для ответ на запрос, в 1/10 secs. Default: 10 секунд   Group Address: Multicast Group Address (0.0.0.0 for General Queries)Switching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  49. 49. IGMP v2 запросы Типы IGMP v2 запросов: o  Join Group Membership Query c адресом multicast-группы IP dstaddr: 224.0.0.2 (All Routers) o  Leave Leave Group с адресом multicast-группы IP dstaddr: 224.0.0.2 (All Routers) o  General Query (v1 Membership Query) IP dstaddr: 224.0.0.1 (All Hosts) Ответ – Membership Report / group address o  Group Specific Query (v2 Membership Query) IP dstaddr: адрес запрашиваемой группы Ответ – Membership Report / group addressSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  50. 50. IGMP v2   Дополнительные механизмы o  Querier Election Mechanism   IGMP Querier – выбранный узел, единственный опрашивающий сегмент •  аналог PIM DR Election •  используется IGMP General Query •  побеждает минимальный IP-адрес   при выходе из строя IGMP Querier – новые выборы •  IGMP Querier Timeout = 2x Query Interval (250 сек) o  Response Suppression Mechanism в ответ на запросы отвечает только один хост (первый по случайному таймеру, в интервале до Maximum Response Time)Switching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  51. 51. IGMP v2 обмен сообщениями 1.1.1.10 1.1.1.11 1.1.1.12 239.1.1.1 239.1.1.1 H1 H2 H3 Leave to Report to #1 224.0.0.2 #3 239.1.1.1 1.1.1.1 Group Specific Query to 239.1.1.1   H2 отключается от группы и посылает сообщение Leave. #2   IGMP Querier посылает Group Specific Query   Один из оставшихся участников группы шлет “Group Specific Membership”   Группа остается активной до тех пор, пока будут приходить ответы от активных хостовSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  52. 52. Multicast VLAN Registration Multicast VLAN Data VLAN IGMP Join / Leave SDTV SDTV Два варианта поддержки MVR:   MVR on Access Port   MVR on Trunk Port (поддерживается на некоторых моделях) http://www.cisco.com/en/US/docs/switches/metro/me3400e/software/release/12.2_55_se/configuration/guide/swigmp.htmlSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  53. 53. Interdomain Multicast RoutingSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  54. 54. Multiprotocol BGP extensions AS1 AS2 PIM Join Multicast Stream AS5 AS3 AS4 No multicast PIM Join   Кратчайший путь для Unicast-трафика (AS3 – AS4 – AS5) не работает для Multicast-трафика   Нужна отдельная таблица маршрутизации для Multicast   Multiprotocol BGP extensionsSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  55. 55. MBGP for Multicast   Различные идентификаторы для различных типов префиксов: o  AFI (Address Family Information) 1 для IPv4 / 2 для IPv6 o  SubAFI (Subsequent AFI) 1 (Unicast) / 2 (Multicast) / 3 (Unicast & Multicast)   Multicast-префиксы не размещаются в таблице маршрутизации Security tip: если разместить источники в RFC1918-адресах и распространять их через MBGP, то доступа к ним из Unicast- пространства не будет   Не является заменой протоколу PIM – не передает и не поддерживает состояние multicast distribution tree   PIM при построении дерева использует маршруты в следующем порядке: 1/Static, 2/MBGP, 3/Unicast http://www.faqs.org/rfcs/rfc2858.htmlSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  56. 56. MBGP for Multicast router bgp 100 router bgp 101 no bgp default ipv4-unicast no bgp default ipv4-unicast bgp log-neighbor-changes bgp log-neighbor-changes neighbor “X0” remote-as 100 neighbor “X0” remote-as 100 neighbor “X0” update-source Loopback0 neighbor “Z0” remote-as 100 neighbor “X1” remote-as 101 ! ! address-family ipv4 address-family ipv4 no synchronization Z0 no synchronization AS101 network 101.0.0.0 neighbor “X0” activate network 100.0.0.0 Multic ast lin neighbor “X0” next-hop-self neighbor “X0” activate k no auto-summary no auto-summary X1 exit-address-family exit-address-family ! ! AS100 address-family ipv4 multicast address-family ipv4 multicast network 100.2.0.0 mask 255.255.0.0 neighbor “Z0” activate neighbor “X1” activate neighbor “Z0” next-hop-self X0 no auto-summary neighbor “X1” next-hop-self no auto-summary exit-address-family exit-address-family router bgp 100 no synchronization bgp log-neighbor-changes network 100.0.0.0 network 192.168.0.0 neighbor “Z0” remote-as 100 neighbor “Z0” update-source Loopback0 neighbor “X1” remote-as 101 neighbor “X1” next-hop-self neighbor “X1” default-originate no auto-summary http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/guide/1cfmbgp.htmlSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  57. 57. Multicast Source Discovery Protocol   RFC 3618   Работает только с PIM-SM o RP осведомлены обо всех источниках в своем домене  Источники регистрируются на RP посредством “PIM Register”  RP обмениваются информацией об источниках посредством сообщений MSDP SA (Source Active) o RP осведомлены обо всех получателях в своем домене  Получатели подключаются к RP посредством Join (*, G)  RP подключаются к источникам в других доменах посредством Join (S, G) http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/guide/1cfmsdp.htmlSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  58. 58. MSDP в действии SA: Source Active AS5 RP AS3 RP AS2 RP RP AS1 AS4 RP ( 100.2.0.2, 239.1.1.1 ) MSDP SA (S, G) Register (S, G)Switching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  59. 59. MSDP в действии (ч.2) AS5 RP AS3 RP AS2 RP Join (*,G) RP Join (S,G) AS1 AS4 RP ( 100.2.0.2, 239.1.1.1 ) Конечный узел (ближайший к получателю) может выполнить переключение на SPT, отключаясь от своего RP (в примере – от RP-AS5)Switching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  60. 60. Anycast RP   Резервирование RP внутри одного домена o  основано на MSDP   RFC 3446   Концепция в общем: o  Внутри одного домена размещается несколько RP с одинаковым IP-адресом o  Источники и получатели пользуются ближайшим (в соответствии с unicast-маршрутизацией) RP   балансировка нагрузки между несколькими RP o  Для обмена информацией между RP об активных источниках используется MSDPSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  61. 61. Anycast RP в действии Src1 Src2 RP1 RP2 MSDP A B SA (src1) SA (src2) 10.1.1.1 10.1.1.1 Rec Rec Rec RecSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  62. 62. Anycast RP failover Src1 Src2 RP1 RP2 A B 10.1.1.1 10.1.1.1 Rec Rec Rec RecSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  63. 63. Anycast RP: конфигурация RP1 RP2 MSDP A B ip pim rp-address 10.0.0.1 ip pim rp-address 10.0.0.1 C D Interface loopback 0 Interface loopback 0 ip address 10.0.0.1 255.255.255.255 ip address 10.0.0.1 255.255.255.255 Interface loopback 1 Interface loopback 1 ip address 10.0.0.2 255.255.255.255 ip address 10.0.0.3 255.255.255.255 ! ! ip msdp peer 10.0.0.3 connect-source loopback 1 ip msdp peer 10.0.0.2 connect-source loopback 1 ip msdp originator-id loopback 1 ip msdp originator-id loopback 1Switching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  64. 64. Source Specific Multicast IGMP v3Switching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  65. 65. Source Specific Multicast   Зачем протоколу PIM-SM требуется Shared Tree / Rendezvous Point? o  Для того, чтобы узнавать о появлении новых источников   А что если источник известен заранее? o  Абонентские устройства должны слать запрос в виде (S, G) для подключения к SPT o  Shared Tree / RP больше не нужен o  Различные источники могут использовать одинаковые группы и никак не мешать друг другу   Source Specific Multicast (SSM) o  RFC 3569Switching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  66. 66. SSM в действии Directory Server Source 4 3 NHR 1.  Получатель делает запрос к 1 серверу-каталогу 2 2.  … и посылает IGMP (S,G) Join 3.  NHR формирует PIM (S,G) Join 4.  По выстроенному SPT начинает передаваться поток ReceiverSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  67. 67. Модель Anycast Source   В сети присутствует два (и более) Source “A” Source “B” одновременно работающих 10.10.10.10 10.10.10.10 источника вещания с одинаковыми IP-адресами Анонсы   Получатель подключается к IGP ближайшему (с точки зрения IGP) источнику   Источник, пока активен, анонсирует себя посредством IGP (например, RIPv2)   Преимущества o  Не нужен MSDP (как в случае с Anycast-RP) o  Балансирование нагрузки o  РезервированиеSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  68. 68. Преимущества SSM   Решает проблему распределения адресов o  потоки идентифицируются парой (S, G), а не только группой o  операторы могут использовать одни и те же группы, поскольку пара (S, G) уникальна   Позволяет избегать атак: o  трафик от неизвестных источников не расходует емкость сети o  трафик от неизвестных источников не попадает на абонентские устройства поскольку источники не зарегистрированы в каталогеSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  69. 69. IGMP v3   IGMP v2 не позволяет явно задать источник   IGMP v3 (RFC 3376) o  добавлены списки Include / Exclude Source явно определяющие список источников o  другой Application Programming Interface (API) приложения / операционные системы должны быть расширены поддержкой IGMP v3 o  IGMP v3 Snooping отличается от IGMP v2 Snooping необходима поддержка в коммутаторах доступа o  Новая группа 224.0.0.22 (IGMPv3 Routers) o  Исчез механизм Report Suppression http://alor.antifork.org/talks/IGMP-v3.pptSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  70. 70. IGMP v3 “Membership Query”   Формат запроса “Membership Query” (0x11) изменился: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x11 | Max Resp Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resv |S| QRV | QQIC(*) | Number of Sources (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address [1] | +- -+ | Source Address [2] | +- . -+ . . . . . . +- -+ | Source Address [N] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (*) QQIC – Querier’s Query Interval CodeSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  71. 71. IGMP v3 “Membership Report”   Добавился запрос “IGMPv3 Membership Report” (0x22): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x22 | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Number of Group Records (M) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Group Record [1] . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | . . . | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Group Record [M] . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Switching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  72. 72. IGMP v3 “Group Record” +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record Type | Aux Data Len | Number of Sources (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address [1] | +- -+ . . . . . . +- -+ | Source Address [N] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Auxiliary Data . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Record Types (RFC 3376, 4.2.12 clause): 1 / MODE_IS_INCLUDE 3 / CHANGE_TO_INCLUDE_MODE 5 / ALLOW_NEW_SOURCES 2 / MODE_IS_EXCLUDE 4 / CHANGE_TO_EXCLUDE_MODE 6 / BLOCK_OLD_SOURCESSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  73. 73. IGMP v3 operations   Сообщения «Membership Report» отсылаются на destination IP-address 224.0.0.22 (IGMPv3 Routers)   Отвечают все хосты (no Report Suppression) o  задержка ответа – случайное значение в интервале до Maximum Response Time o  если несколько запросов – у каждого своя задержка o  хост может давать комбинированный ответ с учетом ранее сформированные и задержанных сообщений   Back compatibility o  маршрутизаторы, поддерживающие IGMPv3, должны поддерживать также IGMP v1/v2Switching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  74. 74. Поддержка IGMPv3   Операционные системы o  Windows XP o  Linux kernel 2.5 o  FreeBSD 8.0 o  Solaris 10   Коммутаторы (IGMP v3 Snooping) o  Cisco Catalyst o  Juniper o  Alcatel o  Huawei o  Zyxel o  D-Link o  3Com o  Edge-CoreSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  75. 75. IGMPv2 / SSM interoperability   Если абонентская сторона не поддерживает IGMP v3, то необходима трансляция IGMP v2 в PIM (S,G) Join   Доступные механизмы: o  URL Rendezvous Protocol o  если приложение стартует из браузера o  IGMPv3 Lite o  если приложение знает про IGMPv3, а ОС - нет o  SSM Mapping o  если ни приложение, ни ОС не знают про IGMPv3   Общая идея механизмов – сформировать Join (S,G) дополнительно к IGMP v2, предоставив маршрутизатору способы для генерации пары (S,G)Switching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  76. 76. URL Rendezvous Protocol (URD)   В HTML-документе присутствует две ссылки: <FRAME SRC=“http://sessions.broadcast.com/sports.sdp” NAME=”Frame to start receiver app“> <FRAME SRC=“http://www.broadcast.com:465/urd-helper? group=232.3.4.5&source=192.44.81.5” NAME=”URD URL“>   Первая ссылка – штатный запрос о подключении к потоку на медиа-сервере, который вернет тип потока и параметры подключения к нему: GET /sports.sdp HTTP/1.0 … Content-type: application/x-sdp … i=Sports Channel c=232.3.4.5 http://www.cisco.com/en/US/docs/ios/12_1t/12_1t5/feature/guide/dtssm5t.htmlSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  77. 77. URL Rendezvous Protocol (ч.2) Вторая ссылка – специальным образом сформированный запрос к порту 465, который будет обработан первым-же маршрутизатором: IGMPv2 (S,G) Join URD 101.2.0.1 Я понимаю, что это за запрос и запоминаю, что нужно подключиться к группе 239.1.1.1 на источнике 101.2.0.1 как только (если еще нет) я получу с этого интерфейса IGMP v2 Membership Report для группы 239.1.1.1Switching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  78. 78. IGMPv3 Lite   Применяется в том случае, если приложение понимает IGMPv3, а операционная система – нет   Используется HSIL (Host Side IGMP Library) – API к IGMPv3Lite Daemon, работающему в операционной системе http://www.cisco.com/en/US/docs/ios/12_1t/12_1t5/feature/guide/dtssm5t.htmlSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  79. 79. IGMPv3 Lite в действии IP SSM application IGMPv3Lite UDP 465 Daemon Membership (S,G) Join Report IGMPv3 Lite- aware INCLUDE Router IP SSM API (S,G) HSIL (*,G) Join Host Operation System IGMPv2 Membership ReportSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  80. 80. SSM Mapping Формат записи в DNS: Source 3.2.1.232.ssm.cisco.com IN A 172.23.20.70 172.23.20.70 PIM (S,G) join 3 2 DNS Server Запрос к DNS IGMPv2 join 232.1.2.3 1 Set Top Box (STB) http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_ssm_mapping.htmlSwitching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  81. 81. Топология лаборатории HDTV LO3 A1 101.2.0.1/24 -> 2 AS101 1 1.1 B1 1.3 3 4 X1 1.2 101.0.0.1/30 -> 2 101.0.0.5/30 -> 6 2 LO4 LO1 HDTV 1 100.2.0.1/24 -> 2 2 0.2 192.168.0.2/24 -> 1 4 B0 0.5 0.6 1 X0 Z0 3 .2 <= 1.1.1.0/24 => .1 0.4 D0 100.2.1.1/24 -> 2 HDTV AS100 LO5Switching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)
  82. 82. End of 4 th Day Happy configuring! Switching & Routing – doka.ua – T102 2010, Владимир Литовка (http://doka-ua.blogspot.com/)

×