ASA 멀티캐스트 문제 해결 및 일반적인 문제

다운로드 옵션

PDF (272.9 KB)
다양한 디바이스에서 Adobe Reader로 보기
ePub (213.0 KB)
iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
Mobi (Kindle) (372.2 KB)
Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기

업데이트:2013년 2월 5일 (화)

문서 ID:115804

번역에 관하여

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

소개

이 문서에서는 ASA(Adaptive Security Appliance)의 멀티캐스트 기능과 이 기능을 사용할 때 발생할 수 있는 잠재적인 문제에 대해 설명합니다.

사전 요구 사항

요구 사항

다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

ASA 멀티캐스트

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참고하십시오.

기능 정보

ASA 명령줄 컨피그레이션 가이드에서는 멀티캐스트 라우팅 기능과 이를 구성하는 방법을 설명합니다.

http://www.cisco.com/en/US/docs/security/asa/asa90/configuration/guide/route_multicast.html

ASA의 멀티캐스트는 두 가지 모드 중 하나로 구성할 수 있습니다.

PIM sparse-mode(기본 설정)
IGMP stub 모드(인터넷 그룹 관리 프로토콜, RFC 2236 IGMPv2)

ASA가 진정한 PIM(Multicast Routing Protocol)을 사용하여 네이버와 통신하기 때문에 PIM sparse-mode가 기본 선택 사항입니다.IGMP Stub-mode는 ASA 버전 7.0이 릴리스되기 전의 유일한 멀티캐스트 컨피그레이션 옵션이며 클라이언트에서 받은 IGMP 보고서를 업스트림 라우터로 단순히 전달하는 방식으로 작동합니다.

PIM 스파스 모드 작업

ASA는 PIM sparse-mode 및 PIM 양방향 모드를 지원합니다.
PIM sparse-mode 및 IGMP stub-mode 명령은 동시에 구성할 수 없습니다.
PIM sparse-mode를 사용하면 모든 멀티캐스트 트래픽이 처음에 RP(Rendezvous Point)로 이동한 다음 수신자에게 전달됩니다.잠시 후에 멀티캐스트 흐름이 소스에서 수신기로 직접 이동합니다(RP 우회).

아래 그림에는 ASA가 하나의 인터페이스에 멀티캐스트 클라이언트를, 다른 인터페이스에 PIM 인접 디바이스가 있는 공통 구축이 나와 있습니다.

PIM 스파스 모드 샘플 컨피그레이션

다음 단계를 완료하십시오.

멀티캐스트 라우팅(전역 컨피그레이션 모드)을 활성화합니다.
```
ASA(config)# multicast-routing
```
PIM Rendezvous-point 주소를 정의합니다.
```
ASA(config)# pim rp-address 172.18.123.3
```
적절한 인터페이스에서 멀티캐스트 패킷을 허용합니다(ASA의 보안 정책이 인바운드 멀티캐스트 패킷을 차단하는 경우에만 필요).
```
access-list 105 extended permit ip any host 224.1.2.3
access-group 105 in interface outside
```

IGMP stub-mode 작업

IGMP Stub-mode에서 ASA는 인접한 라우터에 IGMP 보고서(IGMP "joins"라고도 함)를 생성하거나 전달하여 멀티캐스트 트래픽의 수신을 트리거하여 멀티캐스트 클라이언트 역할을 합니다
라우터는 주기적으로 호스트에 쿼리를 보내 네트워크의 노드가 멀티캐스트 트래픽을 계속 수신하기를 원하는지 확인합니다.
PIM sparse-mode는 Stub-mode보다 많은 이점을 제공하므로 IGMP Stub-mode를 사용하지 않는 것이 좋습니다(보다 효율적인 멀티캐스트 트래픽 흐름, PIM에 참여할 수 있는 기능 등).

아래 그림은 IGMP Stub-mode로 구성된 ASA의 기본 작동을 보여줍니다.

IGMP stub-mode 컨피그레이션

다음 단계를 완료하십시오.

멀티캐스트 라우팅(전역 컨피그레이션 모드)을 활성화합니다.
```
ASA(config)# multicast-routing
```
igmp 보고서를 수신할 인터페이스에서 igmp forward-interface 명령을 구성합니다.패킷을 인터페이스 밖으로 스트림의 소스로 전달합니다.아래 예에서는 멀티캐스트 수신기가 내부 인터페이스에 직접 연결되고 멀티캐스트 소스가 외부 인터페이스 외부에 있습니다.
```
!
interface Ethernet0
 nameif outside
 security-level 0
 ip address 172.16.1.1 255.255.255.0
 no pim
!
interface Ethernet1
 nameif inside
 security-level 100
 ip address 10.0.0.1 255.255.255.0
 no pim
 igmp forward interface outside
!
```
적절한 인터페이스에서 멀티캐스트 패킷을 허용합니다(ASA의 보안 정책이 인바운드 멀티캐스트 트래픽을 거부하는 경우에만 필요).
```
access-list 105 extended permit ip any host 224.1.2.3
access-group 105 in interface outside
```
종종 서로 다른 igmp interface 하위 모드 명령에 혼동이 발생하고 아래 다이어그램에서는 각 명령을 사용할 시기를 설명합니다.

문제 해결 방법론

멀티캐스트 문제 해결 시 수집할 정보

ASA에서 멀티캐스트 포워딩 문제를 완전히 이해하고 진단하려면 이 정보의 일부 또는 전체가 필요할 수 있습니다.

멀티캐스트 발신자, 수신자 및 랑데부 지점의 위치를 포함하여 네트워크 토폴로지에 대한 설명입니다.
트래픽이 사용 중인 특정 그룹 IP 주소 및 사용된 포트 및 프로토콜.
멀티캐스트 스트림에 문제가 있을 때 ASA에서 생성한 Syslog입니다.

ASA 명령줄 인터페이스의 특정 show 명령 출력(예:

show mroute
show mfib
show pim neighbor
show route
show tech-support

패킷 캡처는 멀티캐스트 데이터가 ASA에 도착하는지, 패킷이 ASA를 통해 전달되는지 여부를 표시합니다.
IGMP 및/또는 PIM 패킷을 표시하는 패킷 캡처.
'show mroute' 및 'show mfib'와 같은 인접 멀티캐스트 디바이스(라우터)의 정보.
패킷은 ASA에서 멀티캐스트 패킷을 삭제할지 여부를 확인하기 위해 명령을 캡처 및/또는 표시합니다.'show asp drop' 명령을 사용하여 ASA에서 패킷을 삭제하는지 확인할 수 있습니다.또한 'asp-drop' 유형의 패킷 캡처를 사용하여 ASA에서 삭제하는 모든 패킷을 캡처하고 멀티캐스트 패킷이 드롭 캡처에 있는지 확인할 수 있습니다.

유용한 show 명령 출력

show mroute 명령 출력은 다양한 그룹 및 전달 정보를 표시하며 IOS show mroute 명령과 매우 유사합니다.show mfib 명령은 다양한 멀티캐스트 그룹의 전달 상태를 표시합니다.Forwarding 패킷 카운터와 Other(삭제 표시)를 관찰하는 것은 특히 중요합니다.

ciscoasa# show mfib
Entry Flags: C - Directly Connected, S - Signal, IA - Inherit A flag,
             AR - Activity Required, K - Keepalive
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second
Other counts: Total/RPF failed/Other drops
Interface Flags: A - Accept, F - Forward, NS - Negate Signalling 
             IC - Internal Copy, NP - Not platform switched
             SP - Signal Present
Interface Counts: FS Pkt Count/PS Pkt Count
(*,224.1.2.3) Flags: S K
   Forwarding: 0/0/0/0, Other: 0/0/0
   inside Flags: F
     Pkts: 0/0
(192.168.1.100,224.1.2.3) Flags: K
   Forwarding: 6749/18/1300/182, Other: 690/0/690
   outside Flags: A
   inside Flags: F
     Pkts: 6619/8
(*,232.0.0.0/8) Flags: K
   Forwarding: 0/0/0/0, Other: 0/0/0
ciscoasa#

clear mfib counters 명령을 사용하여 카운터를 지울 수 있으며 이는 테스트 중에 매우 유용합니다.

ciscoasa# clear mfib counters
ciscoasa#

패킷 캡처를 사용하여 멀티캐스트 트래픽 캡처

ASA의 온보드 패킷 캡처 유틸리티는 멀티캐스트 문제를 해결하는 데 매우 유용합니다.아래 예에서는 239.17.17.17으로 향하는 ASA의 DMZ 인터페이스에 도착하는 모든 패킷이 캡처됩니다.

ciscoasa# capture dmzcap interface dmz 
ciscoasa# capture dmzcap match ip any host 239.17.17.17
ciscoasa# show cap dmzcap

324 packets captured

   1: 17:13:30.976618       802.1Q vlan#301 P0 10.1.123.129.2000 > 239.17.17.17.16384:
  udp 172 
   2: 17:13:30.976679       802.1Q vlan#301 P0 10.1.123.129.2000 > 239.17.17.17.16384:
  udp 172 
   3: 17:13:30.996606       802.1Q vlan#301 P0 10.1.123.129.2000 > 239.17.17.17.16384:
  udp 172 
   4: 17:13:30.996652       802.1Q vlan#301 P0 10.1.123.129.2000 > 239.17.17.17.16384:
  udp 172 
   5: 17:13:31.016676       802.1Q vlan#301 P0 10.1.123.129.2000 > 239.17.17.17.16384:
  udp 172 
   6: 17:13:31.016722       802.1Q vlan#301 P0 10.1.123.129.2000 > 239.17.17.17.16384:
  udp 172 
....

패킷 캡처는 PIM 및 IGMP 트래픽을 캡처하는 데에도 유용합니다.아래 캡처는 내부 인터페이스가 10.0.0.2에서 소싱된 IGMP 패킷(IP 프로토콜 2)을 수신했음을 보여줍니다.

ciscoasa# capture capin interface inside
ciscoasa# capture capin match igmp any any
ciscoasa# show cap capin
1 packets captured
1: 10:47:53.540346 802.1Q vlan#15 P0 10.0.0.2 > 224.1.2.3:
  ip-proto-2, length 8
ciscoasa#

ASA PIM Sparse-Mode 멀티캐스트 구축 예

아래 다이어그램은 ASA가 PIM sparse-mode를 사용하여 멀티캐스트 트래픽 흐름을 가져오기 위해 인접 디바이스와 상호 작용하는 방법을 보여줍니다.이 구체적인 예에서는 ASA가 수신합니다.

네트워크 토폴로지 이해

테스트 중인 특정 멀티캐스트 스트림의 발신자와 수신자가 있는 위치를 정확히 확인합니다.또한 사용 중인 멀티캐스트 그룹 IP 주소와 랑데부 지점의 위치를 확인합니다.

이 경우 데이터는 ASA의 외부 인터페이스에서 수신되고 내부 인터페이스의 멀티캐스트 수신기로 전달되어야 합니다.수신자는 ASA의 내부 인터페이스와 동일한 IP 서브넷에 있으므로 클라이언트가 스트림을 수신하도록 요청할 때 ASA 내부 인터페이스에서 수신된 IGMP 보고서를 볼 수 있습니다.발신자의 IP 주소는 192.168.1.50입니다.

ASA가 수신자로부터 IGMP 보고서를 수신하는지 확인

이 예에서는 IGMP 보고서가 수신자에 의해 생성되어 ASA에 의해 처리됩니다.

패킷 캡처 및 debug igmp 출력을 사용하여 ASA가 IGMP 메시지를 수신하고 성공적으로 처리했는지 확인할 수 있습니다.

ASA가 rendezvous 지점으로 PIM 가입 메시지를 전송하는지 확인하는 중

ASA는 IGMP 보고서를 해석하고 PIM 가입 메시지를 생성한 다음 인터페이스를 RP로 전송합니다.

아래 출력은 debug pim group 224.1.2.3의 출력이며 ASA가 성공적으로 PIM 가입 메시지를 전송했음을 보여줍니다.멀티캐스트 스트림의 발신자는 192.168.1.50입니다.

IPv4 PIM: (*,224.1.2.3) J/P processing
IPv4 PIM: (*,224.1.2.3) Periodic J/P scheduled in 50 secs
IPv4 PIM: (*,224.1.2.3) J/P adding Join on outside
IPv4 PIM: (*,224.1.2.3) inside Processing timers
IPv4 PIM: Sending J/P message for neighbor 10.2.3.2 on outside for 1 groups
IPv4 PIM: [0] (192.168.1.50,224.1.2.3/32) MRIB update (a=0,f=0,t=1)
IPv4 PIM: [0] (192.168.1.50,224.1.2.3/32) outside MRIB update (f=20,c=20)
IPv4 PIM: [0] (192.168.1.50,224.1.2.3) Signal present on outside
IPv4 PIM: (192.168.1.50,224.1.2.3) Create entry
IPv4 PIM: [0] (192.168.1.50,224.1.2.3/32) outside MRIB modify NS
IPv4 PIM: Adding monitor for 192.168.1.5

ASA가 멀티캐스트 스트림을 수신하고 전달하는지 확인

ASA는 외부 인터페이스(녹색 화살표로 표시됨)에서 멀티캐스트 트래픽을 수신하고 내부의 수신기에 전달합니다.

show mroute 및 show mfib 명령과 패킷 캡처를 사용하여 ASA가 멀티캐스트 패킷을 수신하고 전달하는지 확인할 수 있습니다.

ASA의 연결 테이블에 멀티캐스트 스트림을 나타내는 연결이 구축됩니다.

ciscoasa# show conn
59 in use, 29089 most used
...
UDP outside:192.168.1.50/52075 inside:224.1.2.3/1234 flags -
...

데이터 분석

일반적인 문제

이 섹션에서는 네트워크 관리자가 과거에 겪었던 일련의 실제 ASA 멀티캐스트 관련 문제를 설명합니다.

HSRP로 인해 ASA가 업스트림 라우터로 PIM 메시지를 보내지 못함

이 문제가 발생하면 ASA는 인터페이스에서 PIM 메시지를 보내지 못합니다.아래 다이어그램은 ASA가 발신자에게 PIM 메시지를 보낼 수 없다는 것을 보여주지만, ASA가 RP로 PIM 메시지를 보내야 하는 경우에도 동일한 문제를 확인할 수 있습니다.

debug pim의 출력은 ASA가 PIM 메시지를 업스트림 next-hop 라우터로 보낼 수 없음을 보여줍니다.

IPv4 PIM: Sending J/P to an invalid neighbor: outside 10.0.0.1

이 문제는 ASA에 국한되지 않으며 라우터에도 영향을 미칩니다.이 문제는 ASA의 라우팅 테이블 컨피그레이션과 PIM 네이버에서 사용하는 HSRP 컨피그레이션의 조합으로 트리거됩니다.

ASA의 라우팅 테이블은 HSRP IP 10.0.0.1을 next-hop 디바이스로 가리킵니다.

ciscoasa# sh run route
route outside 0.0.0.0 0.0.0.0 10.0.0.1 1

그러나 PIM 네이버 관계는 HSRP IP가 아니라 라우터의 물리적 인터페이스 IP 주소 간에 형성됩니다.

ciscoasa# sh pim neighbor
Neighbor Address  Interface          Uptime    Expires DR pri Bidir
10.0.0.2          outside            01:18:27  00:01:25 1 
10.0.0.3          outside            01:18:03  00:01:29 1 (DR)

PIM 스파스 모드가 HSRP 주소에 대한 고정 경로와 함께 작동하지 않는 이유는 무엇입니까?자세한 내용을 참조하십시오.

문서에서 발췌한 내용:

"라우터가 Join/Prune 메시지를 보내지 않는 이유는 무엇입니까?RFC 2362에 따르면 "라우터가 각(S,G), (*,G) 및 (*,*,RP) 항목과 연결된 각 고유 RPF 인접 디바이스에 주기적인 조인/정리 메시지를 보냅니다.RPF 인접 디바이스가 PIM 인접 디바이스인 경우에만 조인/정리 메시지가 전송됩니다."

문제를 완화하려면 해당 트래픽에 대해 ASA에 고정 mroute 항목을 추가합니다.두 라우터의 인터페이스 IP 주소(위 예에서 10.0.0.2 또는 10.0.0.3) 중 하나를 가리키는지 확인합니다. 이 경우 다음 명령을 사용하면 ASA가 멀티캐스트 발신자(172.16.1.2)에게 보내는 PIM 메시지를 전송할 수 있습니다.

ciscoasa(config)# mroute 172.16.1.2 255.255.255.255 10.0.0.3

이 작업이 완료되면 멀티캐스트 라우팅 테이블이 ASA의 유니캐스트 라우팅 테이블을 재정의하고, ASA가 PIM 메시지를 10.0.0.3 인접 디바이스로 직접 전송합니다.

ASA는 LAN 세그먼트의 지정된 라우터가 아니므로 IGMP 보고서를 무시합니다.

이 문제에 대해 ASA는 직접 연결된 멀티캐스트 수신기에서 IGMP 보고서를 수신하지만 무시합니다.디버그 출력이 생성되지 않으며 패킷이 단순히 삭제되고 스트림 수신이 실패합니다.

이 문제와 관련하여 ASA는 클라이언트가 상주하는 LAN 세그먼트에서 선택된 PIM이 아니므로 패킷을 무시합니다.

아래 ASA CLI 출력에서는 내부 인터페이스 네트워크의 다른 디바이스가 지정된 라우터("DR"로 표시됨)임을 보여줍니다.

ciscoasa#show pim neighbor

 Neighbor Address  Interface          Uptime    Expires DR pri Bidir
 192.168.1.2       outside      	   01:18:27  00:01:25 N/A> 
 10.0.0.2          inside              01:18:03  00:01:29 1 (DR)

기본적으로 멀티캐스트 라우팅 명령이 ASA 컨피그레이션에 추가되면 모든 ASA 인터페이스에서 PIM이 활성화됩니다.ASA의 내부 인터페이스에 다른 PIM 네이버(다른 라우터 또는 ASA)가 있고(클라이언트가 상주하는) 해당 세그먼트의 DR이 있기 때문에 해당 네이버 중 하나가 선택된 경우, 기타 비 DR 라우터는 IGMP 보고서를 삭제합니다.이 솔루션은 ASA의 인터페이스에서 PIM을 비활성화하거나(관련 인터페이스에서 pim no 명령 사용), pim dr-priority interface 명령을 사용하여 ASA를 해당 세그먼트의 DR로 설정합니다.

ASA가 232.x.x.x/8 범위의 멀티캐스트 트래픽을 전달하지 못함

이 주소 범위는 ASA에서 현재 지원하지 않는 SSM(Source Specific Multicast)과 함께 사용하기 위한 것입니다.

debug igmp의 출력에 다음 오류가 표시됩니다.

IGMP: Exclude report on inside ignored for SSM group 232.179.89.253

ASA는 역방향 경로 전달 확인 때문에 멀티캐스트 패킷을 삭제합니다.

이 경우 ASA는 인터페이스에서 멀티캐스트 트래픽을 수신하지만 수신자에게 전달되지 않습니다.패킷은 RPF(Reverse Path Forwarding) 보안 검사에 실패하여 ASA에서 삭제됩니다.RPF는 멀티캐스트 트래픽에 대한 모든 인터페이스에서 활성화되며 비활성화할 수 없습니다(유니캐스트 패킷의 경우 기본적으로 확인 기능이 설정되지 않으며 ip verify reverse-path interface 명령으로 활성화).

RPF 검사 때문에, 인터페이스에서 멀티캐스트 트래픽이 수신되면 ASA는 해당 인터페이스에서 멀티캐스트 트래픽 트래픽의 소스로 다시 경로가 있는지 확인합니다(유니캐스트 및 멀티캐스트 라우팅 테이블을 확인합니다).발신자에 대한 경로가 없는 경우 패킷을 삭제합니다.이러한 삭제는 show asp drop 출력에 카운터로 표시될 수 있습니다.

ciscoasa(config)# show asp drop

Frame drop:
  Invalid UDP Length                                          2
  No valid adjacency                                         36
  No route to host                                         4469
  Reverse-path verify failed                      121012

이 문제는 트래픽의 발신자에 대해 ASA에 특정 멀티캐스트 라우팅 테이블 항목을 추가하여 해결할 수 있습니다.아래 예에서 mroute 명령은 외부 인터페이스에서 수신된 172.16.1.2에서 제공된 멀티캐스트 트래픽에 대한 RPF 검사를 충족시키는 데 사용됩니다.

ciscoasa(config)# mroute 172.16.1.2 255.255.255.255 outside

ASA는 소스 트리로의 PIM 전환 시 PIM 조인을 생성하지 않습니다.

처음에는 PIM sparse-mode 멀티캐스트 패킷이 멀티캐스트 발신자에서 RP로, 그런 다음 공유 멀티캐스트 트리를 통해 RP에서 수신자로 이동합니다.그러나 집계 비트 속도가 특정 임계값에 도달하면 멀티캐스트 수신기에 가장 가까운 라우터가 소스 특정 트리를 따라 트래픽을 수신하려고 시도합니다.이 라우터는 그룹에 대한 새 PIM 조인을 생성하고 이를 멀티캐스트 스트림의 발신자에게 보냅니다(이전과 같이 RP를 향하지 않음).

네트워크 토폴로지에 따라 멀티캐스트 트래픽의 발신자는 RP와 다른 ASA 인터페이스에 상주할 수 있습니다.ASA가 소스 특정 트리로 전환하기 위해 PIM 조인을 수신하는 경우 ASA는 발신자의 IP 주소에 대한 경로를 가져야 합니다.이 경로를 찾을 수 없으면 PIM 조인 패킷이 삭제되고 디버그 pim의 출력에서 다음 메시지가 표시됩니다.

NO RPF Neighbor to send J/P

이 문제의 해결 방법은 스트림 발신자에 대한 정적 mroute 항목을 추가하여 발신자가 상주하는 ASA 인터페이스를 가리키는 것입니다.

TTL(Time To Live)이 초과되어 ASA가 멀티캐스트 패킷을 삭제합니다.

이 경우 패킷의 TTL이 너무 낮기 때문에 멀티캐스트 트래픽이 실패합니다.이로 인해 ASA 또는 네트워크의 다른 디바이스가 삭제됩니다.

멀티캐스트 패킷은 IP TTL 값을 전송한 애플리케이션에 의해 매우 낮게 설정된 경우가 많습니다.이 작업은 기본적으로 수행되므로 멀티캐스트 트래픽이 네트워크를 통해 너무 멀리 이동하지 않도록 할 수 있습니다.예를 들어, 기본적으로 Video LAN Client 애플리케이션(널리 사용되는 멀티캐스트 송신기 및 테스트 툴)은 IP 패킷의 TTL을 1로 설정합니다.

ASA는 특정 멀티캐스트 토폴로지로 인해 높은 CPU 사용량 및 삭제된 패킷을 경험합니다.

ASA는 높은 CPU를 경험할 수 있으며 멀티캐스트 토폴로지에 대해 다음 사항이 모두 true이면 멀티캐스트 스트림에 패킷 드랍이 발생할 수 있습니다.

ASA는 RP 역할을 합니다.
ASA는 멀티캐스트 스트림의 첫 번째 hop 수신기입니다.즉, 멀티캐스트 발신자가 동일한 IP 서브넷과 ASA 인터페이스에 있음을 의미합니다.
ASA는 멀티캐스트 스트림의 마지막 hop 라우터입니다.이는 멀티캐스트 수신기가 ASA 인터페이스와 동일한 IP 서브넷에 있음을 의미합니다.

위의 모든 사항이 참인 경우 설계 제한을 해야 ASA가 멀티캐스트 트래픽 스위치를 처리해야 합니다.이로 인해 패킷 삭제를 경험하기 위한 높은 데이터 속도 멀티캐스트 스트림이 발생합니다.이러한 패킷이 삭제될 때 증가하는 show asp drop 카운터는 punt-rate-limit입니다.

ASA에 이 문제가 발생하는지 확인하려면 다음 단계를 완료하십시오.

1단계:다음 두 명령을 사용하여 ASA가 RP인지 확인합니다.

show run pim
show pim tunnel

2단계:다음 명령을 사용하여 ASA가 마지막 hop 라우터인지 확인합니다.

show igmp group <mcast_group_IP>

3단계:다음 명령을 사용하여 ASA가 첫 번째 hop 라우터인지 확인합니다.

show mroute <mcast_group_IP>

멀티캐스트 수신기의 연결을 끊으면 다른 인터페이스에서 멀티캐스트 그룹 수신 중단

IGMP Stub 모드에서 작동하는 ASA만 이 문제를 경험합니다.PIM 멀티캐스트 라우팅에 참여하는 ASA는 영향을 받지 않습니다.

이 문제는 버그 CSCeg48235 - IGMP로 식별됩니다.그룹 수신 중지: 다른 인터페이스에서 그룹 수신 중단

다음은 문제를 설명하는 버그의 릴리스 노트입니다.

Symptom:
When a PIX or ASA firewall is configured for IGMP stub mode multicast reception and 
traffic from a multicast group is forwarded to more than one interface, if a host 
behind a receiving interface sends an IGMP Leave message for the group, it could 
temporarily interrupt the reception for that group on other interfaces of the firewall.

The problem is triggered when the firewall forwards the IGMP leave for the group 
towards the upstream device; that device then sends a IGMP query to determine if any 
other receivers exist out that interface towards the firewall, but the firewall does 
not report that it still has valid receivers.

Conditions:
The PIX or ASA must be configured for IGMP stub mode multicast. IGMP stub mode is a 
legacy multicast forwarding technique, whereby IGMP packets from receivers are forwarded 
through the firewall towards the source of the stream. It is recommended to use PIM 
multicast routing instead of stub igmp forwarding.

Workarounds:
1) Use PIM multicast routing instead of IGMP stub mode.
2) Decrease multicast IGMP query timers so that the receivers are queried more frequently, 
causing their IGMP reports to be forwarded towards the sender more frequently, thus 
restarting the stream quicker.

아웃바운드 액세스 목록의 보안 정책으로 인해 ASA가 멀티캐스트 패킷을 삭제합니다.

이 특정 문제로 인해 ASA는 멀티캐스트 패킷을 올바르게 삭제합니다(구성된 보안 정책에 따라). 그러나 네트워크 관리자가 패킷 삭제 사유를 식별하기 어렵습니다.이 경우 인터페이스에 대해 구성된 아웃바운드 access-list 때문에 ASA에서 패킷을 삭제합니다.해결 방법은 아웃바운드 access-list에서 멀티캐스트 스트림을 허용하는 것입니다.

이 경우 멀티캐스트 패킷이 삭제되고 ASP 드롭 카운터는 "FP no mcast output intrf (no-mcast-intrf)"가 됩니다.

멀티캐스트 스트림이 처음 시작될 때 ASA는 처음 몇 개의 패킷을 삭제합니다.

멀티캐스트 스트림의 첫 번째 패킷이 ASA에 도착하면 ASA는 해당 특정 멀티캐스트 연결 및 관련 mroute 항목을 구축하여 패킷을 전달해야 합니다.엔트리가 생성되고 있는 동안 멀티캐스트 패킷과 연결이 설정될 때까지 일부 멀티캐스트 패킷이 삭제될 수 있습니다(일반적으로 1초 미만 소요). 멀티캐스트 스트림 설정이 완료되면 패킷이 더 이상 제한되지 않습니다.

이러한 이유로 삭제된 패킷은 ASP 삭제 사유인 "(punt-rate-limit) Punt rate limit exceeded"가 됩니다. 다음은 show capture asp의 출력입니다(여기서 asp는 삭제된 패킷을 캡처하기 위해 ASA에 구성된 ASP 삭제 캡처임). 따라서 삭제된 멀티캐스트 패킷을 볼 수 있습니다.

ASA # sh capture asp
2 packets captured
   1: 16:14:49.419091 10.23.2.2.810 > 239.255.123.123.890:  udp 32 Drop-reason:
 (punt-rate-limit) Punt rate limit exceeded
   2: 16:14:49.919172 10.23.2.2.810 > 239.255.123.123.890:  udp 32 Drop-reason:
 (punt-rate-limit) Punt rate limit exceeded
2 packets shown