IOS-XE에서 PIM-SM을 사용한 멀티캐스트 서비스 리플렉션: 유니캐스트에 대한 멀티캐스트

소개

이 문서의 목적은 IOS-XE 플랫폼을 사용하는 MSR(Multicast Service Replication)의 기본 작업에 대한 이해를 Configuration Lab Guide의 형태로 제공하는 것입니다.

사전 요구 사항

요구 사항

PIM-SM에 대한 기본 이해

사용되는 구성 요소

ASR1000(R2&R4), ISR4300(R3), ISR2900(R1&R5)

구성

아래 다이어그램에는 멀티캐스트 전송을 위한 엔드 투 엔드 컨피그레이션이 나와 있습니다.

네트워크 다이어그램

설정

위의 다이어그램에서 노드 R1은 멀티캐스트 소스에서 유니캐스트 멀티캐스트 데이터 피드만 가져오도록 되어 있는 수신기의 역할을 합니다.

노드 R5는 루프백 0 인터페이스에서 소싱된 멀티캐스트 ICMP 트래픽을 생성하는 멀티캐스트 소스 역할을 합니다.

노드 R2는 Content Providers 멀티캐스트 코어 도메인 아래에 있으며 OSPF의 언더레이를 사용하여 PIM-SM을 실행하고 있습니다.

노드 R3는 멀티캐스트 서비스 복제 애플리케이션을 실행하는 라우터의 역할을 하며, 이 경우 멀티캐스트 데이터 트래픽이 수신자를 향해 유니캐스트 데이터 패킷으로 변환되도록 하는 멀티캐스트 보더 라우터입니다. OSPF 및 EIGRP를 각각 Content Provider 및 ISP와 함께 사용하며 멀티캐스트 코어 도메인의 루프백 인터페이스에 RP(Rendezvouz Point)를 저장합니다.

노드 R4는 ISP Core에서 제어하며 멀티캐스트가 활성화되지 않으며 언더레이 EIGRP 라우팅을 사용하여 R3 노드에 연결하는 방법만 이해합니다.

아래에서는 위 토폴로지 다이어그램에 있는 노드에 있는 관련 컨피그레이션을 찾을 수 있습니다.

R1

!
no ip domain lookup
ip cef
no ipv6 cef
!
interface GigabitEthernet0/2
 ip address 10.10.20.1 255.255.255.0
 duplex auto
 speed auto
end
!
router eigrp 100
 network 10.10.20.0 0.0.0.255
!

R2:

!
interface GigabitEthernet0/0/0
 ip address 10.10.20.2 255.255.255.0
 negotiation auto
!
interface GigabitEthernet0/0/2
 ip address 10.10.10.1 255.255.255.0
 negotiation auto
!
router eigrp 100
 network 10.10.10.0 0.0.0.255
 network 10.10.20.0 0.0.0.255
!

R3:

!
ip multicast-routing distributed
!
interface Loopback0
 ip address 192.168.2.1 255.255.255.255
 ip pim sparse-mode
 ip ospf 1 area 0
!
interface GigabitEthernet0/0/0
 ip address 192.168.30.1 255.255.255.0
 ip pim sparse-mode
 ip ospf 1 area 0
 negotiation auto
!
interface GigabitEthernet0/0/1
 ip address 10.10.10.2 255.255.255.0
 negotiation auto
!
interface Vif1
 ip address 192.169.169.1 255.255.255.0
 ip pim sparse-mode
 ip service reflect GigabitEthernet0/0/0 destination 224.1.1.0 to 10.10.20.0 mask-len 24 source 192.169.169.169 <<<< 
 ip igmp static-group 224.1.1.1
 ip ospf 1 area 0
!
router eigrp 100
 network 10.10.10.0 0.0.0.255
!
router ospf 1
!
ip pim rp-address 192.168.2.1
!

R4:

!
ip multicast-routing distributed
!
interface GigabitEthernet0/0/0
 ip address 192.168.30.2 255.255.255.0
 ip pim sparse-mode
 ip ospf 1 area 0
 negotiation auto
!
interface GigabitEthernet0/0/2
 ip address 192.168.20.1 255.255.255.0
 ip pim sparse-mode
 ip ospf 1 area 0
 negotiation auto
!
router ospf 1
!
ip pim rp-address 192.168.2.1
!

R5:

!
ip multicast-routing
ip cef
no ipv6 cef
!
interface Loopback0
 ip address 192.168.168.168 255.255.255.255
 ip pim sparse-mode
 ip ospf 1 area 0
!
interface GigabitEthernet0/2
 ip address 192.168.20.2 255.255.255.0
 ip pim sparse-mode
 ip ospf 1 area 0
 duplex auto
 speed auto
!
router ospf 1
!
ip pim rp-address 192.168.2.1
!

다음을 확인합니다.

R5 라우터의 루프백 0 인터페이스[192.168.168.168]의 소스로 멀티캐스트 트래픽을 시뮬레이션하기 위해 테스트 ping을 수행하여 멀티캐스트 주소 224.1.1.1로 이동하는 컨피그레이션을 검증할 수 있습니다. 그런 다음 MSR 애플리케이션을 실행 중인 노드(예: R3:

R5(config)#do ping 224.1.1.1 sou lo 0 rep 10000000
Type escape sequence to abort.
Sending 10000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.168.168
.............................

R3#sh ip mroute 224.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector, p - PIM Joins on route,
       x - VxLAN group, c - PFP-SA cache created entry
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 00:47:41/stopped, RP 192.168.2.1, flags: SJC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Vif1, Forward/Sparse, 00:46:36/00:01:23 <<<<

(192.168.168.168, 224.1.1.1), 00:00:20/00:02:43, flags: T
  Incoming interface: GigabitEthernet0/0/0, RPF nbr 192.168.30.2
  Outgoing interface list:
    Vif1, Forward/Sparse, 00:00:20/00:02:39 <<<<

R3#sh ip mroute 224.1.1.1 count
Use "show ip mfib count" to get better response time for a large number of mroutes.

IP Multicast Statistics
3 routes using 2938 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 224.1.1.1, Source count: 1, Packets forwarded: 1455, Packets received: 1458 <<<<
  RP-tree: Forwarding: 1/0/100/0, Other: 1/0/0
  Source: 192.168.168.168/32, Forwarding: 1454/1/113/0, Other: 1457/3/0
R3#sh ip mroute 224.1.1.1 count
Use "show ip mfib count" to get better response time for a large number of mroutes.

IP Multicast Statistics
3 routes using 2938 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 224.1.1.1, Source count: 1, Packets forwarded: 1465, Packets received: 1468 <<<<
  RP-tree: Forwarding: 1/0/100/0, Other: 1/0/0
  Source: 192.168.168.168/32, Forwarding: 1464/1/113/0, Other: 1467/3/0

또한 IOS-XE 라우터에서 EPC(Embedded Packet Capture) 기능을 사용하여 패킷이 R2 노드의 의도한 유니캐스트 대상 주소로 변환되는지 확인하기 위해 캡처를 수행할 수 있습니다.

R2#mon cap TAC int gi 0/0/2 both match any
R2#mon cap TAC buff siz 50 circular
R2#mon cap TAC start
Started capture point : TAC
R2#
*Aug 12 06:50:40.195: %BUFCAP-6-ENABLE: Capture Point TAC enabled.
R2#sh mon cap TAC buff br | i ICMP
   6  114   10.684022   192.169.169.169  ->  10.10.20.1       0  BE   ICMP <<<<
   7  114   10.684022   192.169.169.169  ->  10.10.20.1       0  BE   ICMP <<<<
   8  114   12.683015   192.169.169.169  ->  10.10.20.1       0  BE   ICMP <<<<
   9  114   12.683015   192.169.169.169  ->  10.10.20.1       0  BE   ICMP <<<<

여기서 유의할 점은 "랩 환경"에서 멀티캐스트 ICMP ping을 정기적으로 수행할 때 일반적으로 수신기 측에서 소스를 향해 다시 ICMP 에코 응답 패킷을 수신할 것으로 예상한다는 것입니다. 단, 소스 및 수신기 간에 완전한 연결성이 있다고 가정합니다. 그러나 이 시나리오에서는 멀티캐스트 ICMP 패킷의 NATted 소스 주소(예: 192.169.169.169)를 수신자(예: R1에서 EIGRP까지)까지 광고하려고 해도 유니캐스트 ICMP 에코 응답이 R3 라우터를 통과하지 않는다는 점에 유의해야 합니다. 역방향 NAT는 MSR 애플리케이션 노드에 구성되지 않기 때문입니다. R3에서 Vif 1 인터페이스의 EIGRP 경로 광고를 EIGRP(ISP Core routing)로 수행하여 이를 테스트할 수 있습니다.

ISR4351(config)#router eigrp 100
ISR4351(config-router)#network 192.169.169.0 0.0.0.255 <<<<

이제 R3으로 전송되는 ICMP 에코 응답의 R2 노드에서 캡처한 내용을 확인할 수 있습니다.

R2#sh mon cap TAC buff br | i ICMP 

 249  114  317.847948   192.169.169.169  ->  10.10.20.1       0  BE   ICMP
 250  114  317.847948   192.169.169.169  ->  10.10.20.1       0  BE   ICMP
 251  114  317.847948   10.10.20.1       ->  192.169.169.169  0  BE   ICMP <<<<
 252  114  317.847948   10.10.20.1       ->  192.169.169.169  0  BE   ICMP <<<<
 253  114  319.847948   192.169.169.169  ->  10.10.20.1       0  BE   ICMP
 254  114  319.847948   192.169.169.169  ->  10.10.20.1       0  BE   ICMP
 255  114  319.848955   10.10.20.1       ->  192.169.169.169  0  BE   ICMP <<<<
 256  114  319.848955   10.10.20.1       ->  192.169.169.169  0  BE   ICMP <<<<
 259  114  321.848955   192.169.169.169  ->  10.10.20.1       0  BE   ICMP
 260  114  321.848955   192.169.169.169  ->  10.10.20.1       0  BE   ICMP
 261  114  321.848955   10.10.20.1       ->  192.169.169.169  0  BE   ICMP <<<<
 262  114  321.848955   10.10.20.1       ->  192.169.169.169  0  BE   ICMP <<<<

그러나 Ping은 소스 R5에서 볼 수 있듯이 여전히 실패합니다.

R5(config)#do ping 224.1.1.1 sou lo 0 rep 10000000
Type escape sequence to abort.
Sending 10000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.168.168
......................................................................
......................................................................

이제 응답이 소스까지 도달하도록 하려면 확장 가능한 NAT를 구성하여 목적지에 있는 트래픽을 192.169.169.169에서 192.168.168.168로 변환하도록 MSR 애플리케이션 노드 R3에서 NAT 포트 전달을 구성할 수 있습니다.

R3(config)#int gi 0/0/1
R3(config-if)#ip nat out
R3(config-if)#int gi 0/0/0
R3(config-if)#ip nat ins
R3(config-if)#exit
R3(config)#ip nat inside source static 192.168.168.168 192.169.169.169 extendable <<<<

이제 소스 R5 노드를 검사하면 응답이 다시 오는 것을 확인할 수 있습니다.

R5(config)#do ping 224.1.1.1 sou lo 0 rep 10000000
Type escape sequence to abort.
Sending 10000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.168.168
......................................................................

Reply to request 716 from 10.10.20.1, 1 ms
Reply to request 716 from 10.10.20.1, 1 ms
Reply to request 717 from 10.10.20.1, 1 ms
Reply to request 717 from 10.10.20.1, 1 ms
Reply to request 718 from 10.10.20.1, 1 ms
Reply to request 718 from 10.10.20.1, 1 ms

위의 작업은 패킷 흐름을 설명하고 데이터 트래픽 및 다운스트림 멀티캐스트 트래픽에 대한 역방향 유니캐스트 경로/흐름을 설정하는 방법을 이해하기 위해 수행되었을 뿐입니다. 일반적인 프로덕션 시나리오에서는 서버/소스 측에서 실행되는 멀티캐스트 애플리케이션이 유니캐스트 형식의 수신자로부터 역방향 승인 패킷을 요구하는 경우/인스턴스를 건너오지 않습니다. 

위의 테스트 및 검증을 통해 멀티캐스트 보더 노드 중 하나에서 멀티캐스트 서비스 복제 애플리케이션을 실행하는 방법 및 위에 표시된 것을 대규모 구축으로 확장하려는 경우 이를 구축하는 방법에 대한 간략한 개요를 제공했어야 합니다.