Multicast (2) PIM-DM

<>PIM-DM

Protocol Independent Multicast - Dense Mode

유니캐스트 라우팅 테이블을 통한 최단거리 라우팅으로 통신한다. (소스 트리 기반) 따라서 그룹주소와 요청호스트를 관리하는

RP라우터를 따로 지정하지 않으며, 서버와 호스트의 최단거리로 통신한다. 멀티캐스트 프로토콜을 구동하는 모든 장비는

각각의 그룹별 멀티캐스트 라우팅 테이블(mroute table)을 생성하고 관리(주기적으로 테이블 삭제, 생성)하므로 장비의 부하를

주게된다. 다시말해, 주기적으로 중계라우터들이 멀티캐스트 인터페이스로 프레임을 플러딩(flooding)하므로 이로 인한 불필요한 시스템 부하가 발생하게 된다.

   예제조건

   (1) 서버, 호스트를 포함한 모든 장비는 EIGRP로 통신 (다른 IGP도 무방)

   (2) R5와 Host 1, 2 는 서브인터페이스 트렁크 Dot1q로 연결함

   

1. PIM-DM Configuration

   R2(config)# ip multicast-routing

   R2(config-if)# ip pimdense-mode

   라우터에 멀티캐스트 라우팅을 활성화하고, 인터페이스에 PIM Dense 모드를 활성화한다.

2. 프레임 흐름

   (1) Host 1, 2 가 멀티캐스트 프레임 수신을 위해 IGMP group에 조인한다.

   

      Host1(config-if)# ip igmp join-group 239.1.1.1

      Host2(config-tf)# ip igmp join-group 239.1.2.2

    

   유저가 멀티캐스트 방송(IPTV등) 을 시청하기위해 스트리밍을 재생하는 동작과 동일하다.

   (2) 멀티캐스트 서버가 멀티캐스트 프로토콜이 활성화된 R2, R3로 프레임을 송신한다.

        그리고 R2와 R3는 R4로 송신한다.

   (3) RPF Neighbor

        R4는 멀티캐스트 소스를 두군데에서 받는데(R2, R3) 이중 메트릭값이 더 좋은 경로를 RPF네이버로

        선정하고 메트릭이 동일할경우 높은 IP를 가진 인터페이스가 RPF 네이버로 선정된다.

        예제에서 R3가 RPF 네이버가 되었고 R2로 Prune(가지치기) 메시지를 보낸다.

   (4) PIM Assert

        RPF는 라우터에서만 동작하게 된다. 따라서 R4가 만약 PC같은 종단장치라면 R2, R3의 중복패킷을

        함께 수신할수 밖에 없는데, 이때 종단장치로 멀티캐스트를 송신할 장치를 선정하는것으로 

        PIM assert 라 한다. 소스로부터 메트릭, AD값이 낮은 장비가 우선선정되고, 동일할경우 IP가 높은라우터가 

        선정된다. 

   show ip mroute 239.1.1.1   

   R2의 f0/1 포트는 Prune

   (5) IGMP querier 선정

        동일한 서브넷에서 멀티캐스트를 구동하는 라우터는 IGMP querier로 선정되어 그룹 번호 요청의 시청/비시청 질의

        하게된다. 멀티캐스트 라우터가 2대이상일경우 인터페이스 IP가 낮은쪽이 IGMP querier로 선정된다. (예제의 R2)

        예제에서 R2는 f0/0, f0/1 이 모드 IGMP querier로 선정되게 된다.

   show ip igmp interface f0/0

   this systemis IGMP querier 즉 해당 인터페이스가 querier이다.

   (6) 멀티엑세스 네트워크에서 DR선정

        DR선정시에는 DR priority가 가장 높은 인터페이스가 우선 선정되고, 동일할시 IP가 높은 인터페이스가 선정된다.

        예제에서 [1.1.123.x] 네트워크에서는 R3, [1.1.234.x] 네트워크에서는 R4가 선정된다.

        인터페이스 설정에서 DR priority 를 조정하여 DR 라우터를 변경가능하다. (PIM-DM에서는 무의미)

   인터페이스 F0/1 의 DR 우선도를 10으로 조정하였더니 R4의 1.1.234.4 에서 R2의 1.1.234.2로 DR이 변경되었음이 

   메시지로 나타난다.

   (7) Prune Overide

        R2에 멀티캐스트 프레임 리시버가 존재하지 않기때문에, (F0/0 prune상태이므로) R2가 R4로 프룬 메시지를 보내지만

        R4는 동일한 인터페이스로 R3의 프레임을 주고 받기 때문에 R2의 프룬 메시지를 무시하고 계속해서 f0/0을 포워드

        한다. R4는 R3에게 프룬 메시지를 재전송, R3는 패킷을 계속 수신해야하므로 프룬해선 안된다고 Join 메시지 전송

        R4는 앗 미안. 하고서 R2의 프룬메시지를 씹고 인터페이스 f0/0 으로 계속 포워딩한다. 이는 2~3분 간격으로 반복

   (8) 이렇게 R2,3,4 사이에서 DR선정, IGMP querier 선정, PIM 어서트, 프룬 오버라이드 등이 동작하면서 결국 패킷이,

        SERVER -> R3 -> R4로 가게된다. 그후 R4는 R5와 R6중 목적지로 가는 경로가운데서 메트릭값이 가장 좋은 R5를

        선택하고 RPF 네이버를 맺는다. (예제에서 R6은 IGP 기준상 우회경로이므로)

   R5

   1.1.123.1 소스에 대한 멀티캐스트 패킷의 RPF가 1.1.45.x 네트워크로 선정 (R4-R5)

   

   (9) 이렇게 최종적으로 멀티캐스트 패킷의 흐름이 Server -> R3 -> R4 -> R5 -> Host 로 최종 경로가 확정된다.

3. Static Mroute

   PIM-DM은 기본적으로 IGP의 라우팅 테이블을 기반으로 한 RPF 체크를 통해 네이버관계를 확립하고 통신을 하는데, 

   만약 RPF 확인이 되지 않은(IGP 라우팅 테이블에 최단경로가 아닌) 경로로 멀티캐스트 경로를 확립할시엔 정적으로

   멀티캐스트 라우팅 테이블을 구성할수 있다.

   

   위 예제에서 가정한다면, 

   (1) R4, R5의 F1/0 인터페이스, 즉 [1.1.45.x] 네트워크에 PIM-DM 모드가 활성화되지 않았다고 가정시에,

   (2) IGP는 R4에서 Host로 가는 최단경로가 R4 -> R5 -> Host 이므로 멀티캐스트 RPF 체크가 실패한다. 

        결과적으로 서버와 호스트가 통신하지 못한다.

   (3) 따라서 멀티캐스트 패킷이 R4 -> R6 -> R5로 우회하도록 경로를 수동으로 조정해야한다.

   R5(config)# ip mroute 1.1.123.0 255.255.255.0 1.1.56.6

   R6(config)# ip mroute 1.1.123.0 255.255.255.0 1.1.46.4

   R5 -> R6 ->R4로 향하도록 static으로 조정. 통신이 재게된것을 확인할수 있다.