Overview

멀티캐스팅이란 유니캐스트와 브로드캐스트 통신 사이의 개념으로 특정 그룹에 속한 호스트들에게 1:N의 통신을 하기 위한 통신 방식입니다.

멀티캐스팅 통신을 가능케 하는 여러 프로토콜이 있는데 아래와 같이 분류됩니다.
프로토콜 | 역할 |
IGMP(Internet Group Management) | LAN에서 그룹에 참여하는 단말을 관리 |
IGMP Snooping | 스위치에서 멀티캐스팅을 인식하여 Flooding이 일어나지 않도록 함 |
PIM(Protocol Independent Multicasting) | 다수의 LAN이 멀티캐스팅에 참여하는 경우 라우팅을 담당 |
멀티캐스트는 유니캐스트와 다르게 (Source , Destination) 이 아닌 (Source, Group)의 형태로 트래픽을 전달합니다.
이 때 Source는 해당 그룹에 참여하지 않아도 됩니다.

멀티캐스트는 MAC 주소와 IP 주소에 대해 ARP를 실행하지 않으므로 L2 스위치가 어떤 호스트가 어느 그룹에 속해있는지 알 수 없습니다. 따라서 L2 네트워크에 멀티캐스트 트래픽이 인입되면 Flooding됩니다.
BUM Traffic의 M이 멀티캐스트인 이유이며, 이를 방지하기 위해 IGMP Snooping을 이용합니다.
멀티캐스팅 주소
Description | Range | 설명 |
Link Local Addresses | 224.0.0.0/24 | 로컬 세그먼트에서 사용되도록 예약 OSPF의 라우팅 정보 전송 등에 이용됨 |
Globally Scoped Addresses | 224.0.1.0 - 238.255.255.255 | 조직 간 및 인터넷을 통한 멀티캐스트 데이터 전달을 위해 예약 |
Source-Specific Multicast | 232.0.0.0/8 | SSM 데이터그램 전달 모델과 함께 사용하도록 예약 |
GLOP Addresses | 233.0.0.0/8 | |
Limited Scope Addresses | 239.0.0.0/8 | 개인 멀티캐스트 도메인에서 사용하기 위한 범위 / 사설 IP와 동일한 개념 |
주소 | 용법 |
224.0.0.1 | 모든 호스트 |
224.0.0.2 | 모든 멀티캐스트 라우터 |
224.0.0.3 | 할당되지 않음 |
224.0.0.4 | DVMRP 라우터 |
224.0.0.5 | OSPF 라우터 |
224.0.0.6 | OSPF DR/BDR 라우터 |
224.0.0.7 | ST 라우터 |
224.0.0.8 | ST 호스트 |
224.0.0.9 | RIPv2 라우터 |
224.0.0.10 | EIGRP 라우터 |
224.0.0.11 | 모바일 에이전트 |
224.0.0.12 | DHCP 서버 / 릴레이 |
224.0.0.13 | 모든 PIM 라우터 |
224.0.0.14 | RSVP 캡슐화 |
224.0.0.15 | 모든 CBT 라우터 |
224.0.0.16 | 지정된 SBM |
224.0.0.17 | 모든 SBMS |
224.0.0.18 | VRRP |
224.0.0.19 – 255 | 할당되지 않음 |
멀티캐스트는 Class D의 주소를 사용하며 위와 같이 사용목적이 예약된 주소들이 있습니다.

MAC 주소의 8번째 BIT가 1로 설정되고, IP 주소가 224.0.0.0/4 범위에 속하는 모든 패킷은 멀티캐스팅 트래픽으로 생각하면 됩니다.

멀티캐스트 MAC 주소는 0100.5E + [그룹주소] 의 형식으로 생성됩니다.
즉 앞 25Bit가 고정되기 때문에 32Bit의 IP 주소 중 23Bit만 포함되는 문제가 발생합니다.
32bit의 IP 주소 중 고정된 224를 제외한 5bit가 누락되기 때문에, 특정 멀티캐스팅 주소는 MAC 주소가 겹치는 문제가 발생함으로 함께 사용하지 않도록 구성해야합니다.
IGMP(Internet Group Management Protocol)
LAN 상에서 호스트가 멀티캐스트 그룹에 가입할 수 있도록 하는 프로토콜

주기적으로 멀티캐스트 그룹에 가입의사가 있는 호스트를 찾기 위해 membership query를 송신한다.
그룹에 가입할 의사가 있는 호스트가 해당 멀티캐스트 주소에 응답(membership report)하게 되면 해당 그룹에 가입되는 구조이다.
이때 IGMP가 구동되어 호스트의 그룹 가입 여부를 확인하는 장비를 Querier라고 칭한다.
IGMP v1
호스트는 Membership Query(60초 Interval, 224.0.0.1 브로드캐스팅)에 응답하여 그룹에 속하고 있음을 알린다.
그룹 탈퇴의 방법이 명시되어 있지 않아, 탈퇴하기 위해선 260초 동안 Query에 응답하지 않아야 한다.
IGMP v2
v1에서 그룹 탈퇴 기능을 개선한 버전이며 v1과 호환가능하다.
아래 4가지의 메시지가 추가된다.
Leave group messages
#호스트가 더 이상 멀티캐스트 그룹 주소를 수신하지 않기 위해 라우터에게 송신하는 메시지
Group-specific membership query
#기존에 v1의 경우 224.0.0.1로 보내던 Membership query messeage
#그룹별로 특정하게 뿌릴 수 있도록 개선
#불필요한 쿼리를 줄임
MRT(Maximum Response Time) field
#쿼리 메시지의 새로운 필드
#그룹에 가입한 호스트가 라우터가 보내는 쿼리에 대해 응답해야하는 시간을 지정하는 필드
Querier election process
#같은 서브넷에 라우터가 두개 존재할 시 하나만 쿼리 메시지를 보내야 하므로
#해당 프로세스를 통해 단 하나의 라우터가 쿼리 메시지를 보내도록 함
#(IP 주소가 가장 낮은 라우터가 뽑힘)
IGMP v3
공격자가 그룹 주소에 자신이 전송하고 싶은 내용을 전송하게 되면, 그룹에 속한 모든 호스트가 공격자가 전송한 내용을 수신하게 됩니다. 기존 v1,v2의 경우 Source를 검사하지 않으므로 DDOS 공격에 취약합니다.
이런 부분을 보완하기 위해 IGMPv3에 SRC Filtering 기능이 추가되어 특정 Source로부터만 멀티캐스팅 트래픽을 전달받을 수 있도록 합니다.
IGMP Snooping
IGMP Snooping은 스위치가 멀티캐스트를 인식할 수 있도록 하여 BUM Traffic에 의한 플러딩을 줄이는 기법으로 현재 출시되는 모든 스위치들에 기본 활성화되어 있습니다.
멀티캐스팅을 통해 생성된 MAC은 ARP를 통해 광고되지 않으므로 스위치는 멀티캐스트 트래픽을 보고 어느 포트로 전달해주어야 하는지 알 수 없어 플러딩을 발생시킵니다.
이를 방지하기 위한 것이 IGMP Snooping이고 IGMP Snooping table을 형성하여 해당 정보를 관리합니다.
- IGMP Membership Queries
- IGMP Membership Responses
- PIM Hello messages
IGMP Snooping이 활성화된 L2 스위치는 라우터처럼 위 메시지를 수신대기합니다.

이제 스위치는 Membership Query를 전달받는 인터페이스를 Multicast router interface로 Membership Report를 전달받는 인터페이스를 group-member interface로 구분합니다.
라우터로부터 멤버쉽 쿼리 메시지를 받게 되면 초기에는 플러딩하며 해당 쿼리에 응답하는 호스트가 연결된 포트를 Group-member interface로 등록하고 추후 멀티캐스트 트래픽 발생 시 해당 포트에만 트래픽을 전달합니다.
일반적인 스위치의 learning, flooding, forwarding과 유사합니다.
마지막으로 스위치가 Host로부터 IGMP Report를 수신하면 해당 포트를 연관된 멀티캐스트 테이블에 추가하고 Leave 메시지를 수신하면 해당 포트를 테이블에서 제거합니다.
IGMP 제어 메시지는 멀티캐스트 패킷으로 전달되어 L2 헤더만 검사한다면 일반 데이터와 구별할 수 없으므로 IGMP 스누핑을 실행하게 되면 모든 IGMP 패킷을 검사하게 됩니다.
이는 LOW-END 급의 스위치에 부담이 되어 멀티캐스팅 트래픽이 DROP될 수 있습니다.
아래는 IGMP Snooping의 Configuration입니다.
일반적으로 모든 vlan에 활성화됨
ip igmp snooping vlan [vlan number]
#igmp snooping 활성화
ip igmp snooping vlan [vlan num] mrouter interface [int num]
#multicast router interface 수동 지정
sh ip igmp snooping group
SW1# sh ip igmp snooping groups vlan 10
Flags: I -- IGMP snooping, S -- Static, P -- PIM snooping, A -- ASM mode
Vlan Group/source Type Version Port List
-----------------------------------------------------------------------
10 224.0.1.40 I v2 Et0/0
10 239.1.1.1 I v2 Et0/2
10 239.2.2.2 S v2 Et1/1
#S는 정적 구성하였다는 의미
sh ip igmp snooping mrouter
sh ip igmp snooping querier
#Multicast router interface 확인 명령어
PIM(Protocol Independent Multicasting)
멀티캐스팅의 라우팅을 위한 프로토콜, 실제로 라우팅 정보를 전달하는 것은 아니고 Unicast Routing Protocol로 선출된 경로를 참조하여 Multicast distribution Tree를 생성하여 전달합니다.
Independent?
이름에 독립적인 이라는 이름이 들어가는 이유는 이전의 네트워크에서는 멀티캐스트를 위해 병렬적인 프로토콜을 실행하여 멀티캐스트의 경로는 멀티캐스트 전용 프로토콜이 모두 실행하게 하였기 때문입니다.
E.G Unicast Routing → OSPF , Multicasting Routing → MOSPF
특정 기능을 위해 거의 동일한 기능을 하는 프로토콜을 병렬로 처리하는 것은 비효율적입니다. 따라서 경로에 관련된 것은 unicast routing을 참조하며 멀티캐스팅 처리만 할 수 있도록 한 프로토콜이 PIM이며 이런 이유로 인해서 독립적인 이라고 말하는 것입니다.
PIM 용어
용어 | 의미 |
IIF(Incoming Interface) | PIM join을 보내는 멀티캐스트 송신자와 연결되는 인터페이스 |
OIF(Outgoing Interface) | 멀티캐스트를 전달하는 인터페이스 |
LHR(Last Hop Router) | 멀티캐스트 수신 호스트(Receiver)와 연결된 라우터 |
FHR(First Hop Router) | 멀티캐스트 Source 와 연결된 라우터 |
DR(Disignate Router) | OSPF의 DR과 역할은 다르지만 선출 방법은 같다 |
Multicast Distribution Tree
PIM 유니캐스트 라우팅을 통해 장비들이 가지고 있는 경로 정보로 MDT를 형성합니다.
이러한 MDT는 Unicast Routing 처럼 같은 COST의 여러 경로를 가지는 것이 아니고, SRC → RCV(그룹에 속한 실제 호스트) 까지의 단일 경로만 형성합니다.
MDT는 두가지의 형식이 있습니다.
Source Tree(Shortest Path Tree)

Tree의 Root가 SRC 그 자체가 되는 방식으로 SRC의 트래픽이 중간 경유지점 없이 RCV에게 바로 전달된다.
Shared Tree

Shared Tree에선 RP( Rendezvous Point ) 라는 것이 존재한다. Shared Tree 상태에선 SRC가 RCV에게 바로 멀티캐스트 트래픽을 전달하는 것이 아닌 필수적으로 RP를 경유해야하며, 그룹에 참여한 호스트인 RCV도 RP에게 PIM Join 메시지를 보내 참여해야한다.
아래와 같이 작동한다.
- 1단계: FHR이 소스로부터 멀티캐스트 스트림을 수신하면 소스를 랑데부 포인트(RP)에 등록합니다.
- 2단계: 수신기가 연결된 로컬 게이트웨이 라우터(Last-hop Router, LHR)가 RP로부터 멀티캐스트를 수신하면 소스 IP 주소를 학습합니다. 그런 다음 LHR은 소스로 가는 최단 경로 트리(SPT)를 시작합니다.
- 3단계: FHR은 멀티캐스트 트래픽을 LHR로 직접 전달하고 랑데부 포인트는 더 이상 데이터 경로에 없습니다.
RPF(Reverse Path Forwarding)

PIM의 루핑 방지 기법입니다.
멀티캐스트 트래픽이 라우터에 도착했을 때 유니캐스트 라우팅 테이블을 확인하여 해당 멀티캐스트 트래픽이 유니캐스트 라우팅 테이블의 최적 경로로 오지 않았다면 루핑 발생으로 보고 해당 트래픽을 DROP 하는 기법입니다.
따라서 이런 최적 경로의 인터페이스를 RPF Interface, 그렇지 않은 인터페이스를 non-RPF Interface라고 합니다.
그리고 non-RPF Interface의 트래픽이 DROP 되는 것을 RPF Failure라고 표현합니다.

CONFIG를 아직 적지 않았지만, 멀티캐스팅을 이용할 때 PIM을 이용해 멀티캐스트 트래픽을 전달할 인터페이스를 선택합니다.
만약 Unicast Routing이 선택한 최적경로와 PIM을 실행한 RPF Interface가 서로 다르다면 문제가 발생할 수 있습니다.
PIM은 경로를 Unicast Routing에 의해 생성하기 때문에 경로는 최적경로를 이용하더라도 해당 인터페이스가 멀티캐스트 트래픽을 해석할 수 없기 때문에 트래픽이 DROP되는 문제가 발생할 수 있습니다.
최적 경로로 선택된 인터페이스를 PIM에 참가시키거나 mroute 명령어로 라우팅을 추가하여 해결해야 합니다.
PIM-DM(Dense-Mode)

UPSTREAM ROUTER | 멀티캐스팅 트래픽을 전달받는 과정에서 나에게 멀티캐스팅 트래픽을 보낸 라우터 |
DOWNSTREAM ROUTER | 전달받은 멀티캐스팅 트래픽을 포워딩할 상대 라우터 |
Source Tree를 사용하며 PUSH METHOD(모든 라우터에 플러딩하면 모든 관심 있는 수신자가 수신하게 됨)를 이용한 방법으로 DENSE 모드는 네트워크의 모든 라우터에 하나 이상의 관심 있는 수신기가 있다고 가정합니다.
가장 기본적인 멀티캐스팅 방식으로 멀티캐스트 그룹 안에 속한 모든 노드(라우터)에 멀티캐스트 트래픽을 전달하며 Dense mode가 설정된 라우터는 멀티캐스트 트래픽을 전달받으면 모든 인터페이스로 해당 트래픽을 플러딩합니다.

이로 인해 루핑이 발생하게 되는데 PIM Prune을 통해서 이를 억제하고 최종적으로는 위와 같은 Source Tree가 형성되게 됩니다.
Prune?

Prune message를 보내는 경우는 아래 3가지가 있습니다.
- 그룹에 속한 Direct Connected된 호스트가 없을 경우
- 멀티캐스팅 트래픽을 전달할 다운스트림 라우터가 없을 경우
- non-RPF interface에서 트래픽을 전달받았을 경우

업스트림 라우터도 다른 인터페이스에 관심 있는 수신자가 없는 경우 Prune 메시지를 상위 업스트림 라우터로 전파합니다.
Prune 메시지가 관심 있는 수신자가 있는 라우터에 도달하거나 소스에 도달할 때까지(네트워크에 관심 있는 수신자가 없는 경우) 프로세스가 계속됩니다. 이러한 과정을 Upstream Propagation 이라고 합니다.
PIM Prune 메시지를 수신하면 업스트림 라우터는 메시지를 수신한 인터페이스로 Prune된 그룹에 대한 멀티캐스트 트래픽을 전달하는 것을 중단합니다.
하지만 Prune 메시지의 전송은 3분마다 갱신되어 재전송해야하므로 노드가 많아질 수록 비효율 적이고 망에 무리를 줍니다.
PIM-SM(Sparse-Mode)
PULL 모델을 사용하여 멀티캐스트 트래픽을 전달하는 방식으로 Shared Tree 방식을 이용하기 때문에 하나 이상의 RP를 구성해야한다.
화상 회의 및 협업 컴퓨팅 소수의 수신기가 포함된, 실시간성을 띄는 트래픽에 적합한 방법이다.

Sparse-Mode 에서는 호스트가 멀티캐스트 요청(membership report)을 보내지 않는 한 멀티캐스트 트래픽을 전달하지 않습니다.
Source의 멀티캐스트 트래픽은 PIM Register 메시지에 담겨 RP에 전달되는데, 수신자의 요청이 있다면 이를 허용하고 아니라면 거부합니다.

거부 메시지를 받은 라우터( FHR(First Hop Router) )는 60초 동안 멀티캐스트 트래픽을 전달하지 않는다.

억제 타이머가 종료되면 멀티크새팅 트래픽을 다시 보내는 것이 아니라 PIM Register Null 패킷을 보내 수신을 원하는 수신자가 있는지 파악한다.

멀티캐스팅 트래픽에 관심 있는 수신자가 나타나면 FHR은 RP에게 PIM join 메시지를 보낸다.

초기에 따라서 RP를 경유하는 Shard Tree 방식을 이용하여 통신하게 됩니다.


이 때 FHR이 SRC의 주소를 알게 되므로 RP를 이용하는 Shared Tree에 Prune 메시지를 전달하고 SRC의 SPT에 PIM Join 메시지를 보내 Source Tree 방식으로 통신합니다.
PIM-SSM(Source Specific Mode)
현재 가장 널리 사용되는 방식으로, PIM-SM의 확장 방식이다. 그룹에 참여하는 모든 호스트들이 SRC를 필터링할 수 있어야하므로 IGMPv3를 이용하며 RP가 필요하지 않다.
Multicasting Configuration
ip multicasting-routing
#멀티캐스팅 라우팅을 이용한다고 선언
int [interface num]
ip pim [dense-mode/sparse-mode]
#PIM을 활성화하지 않는 인터페이스는 IGMP 트래픽을 처리할 수 없음
ip igmp version [number]
#IGMP Version 설정
ip igmp join group [group address] source [source]
#수신 측 즉 LHR에서 IGMP 그룹 가입을 위한 명령어
sh ip multicast
'네트워크 > 네트워크 일반' 카테고리의 다른 글
간단한 CISCO 장비 CONFIG 꿀팁 모음 (1) | 2024.12.10 |
---|---|
전자금융감독규정에 따른 금융권 대외 기관 연계의 VPN과 전용선 사용 (0) | 2024.12.02 |
HSRP, VRRP 게이트웨이(Virtual IP)가 흔들린다의 의미 (4) | 2024.11.15 |
스위치의 프레임 처리 방식 (0) | 2024.09.16 |
L3 스위치와 라우터의 차이, L3 Switch Config (0) | 2024.06.15 |