목차

소개

기능 정보

약어/약어

멀티캐스트의 구성 요소

PIM 스파스 모드 작업

PIM Sparse-mode 샘플 컨피그레이션

PIM 스파스 모드 예:

IGMP 스텁 모드 작업

IGMP 스텁 모드 컨피그레이션

비디르 PIM

Bidir PIM 컨피그레이션

문제 해결 방법론

멀티캐스트 문제 해결 시 수집하기 위한 정보

유용한 Show 명령 출력

패킷 캡처

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

데이터 분석

일반적인 문제

ASA에서 HSRP로 인해 업스트림 라우터로 PIM 메시지를 전송하지 못했습니다

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

IGMP 인터페이스 제한이 초과되면 방화벽에서 IGMP 보고서를 거부함

ASA에서 232.x.x.x/8 범위의 멀티캐스트 트래픽을 전달하지 못했습니다.

ASA에서 역방향 경로 전달 확인으로 인해 멀티캐스트 패킷을 삭제합니다

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

TTL(Time To Live) 초과로 인해 ASA에서 멀티캐스트 패킷을 삭제합니다

특정 멀티캐스트 토폴로지로 인해 ASA에서 높은 CPU 사용량이 발생하고 삭제된 패킷이 발생합니다

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

연결을 끊는 멀티캐스트 수신기가 다른 인터페이스에서 멀티캐스트 그룹 수신을 중단합니다

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

ASA는 제어 지점 속도 제한으로 인해 멀티캐스트 스트림의 일부 패킷(전부는 아님)을 지속적으로 삭제합니다

PIM ASSERT 메시지로 인해 멀티캐스트 스트림이 중단되었습니다

ASA에서 PIM 참가를 전송하지만 패킷 크기가 MTU보다 크기 때문에 네이버에서 처리하지 않습니다

소개

이 문서에서는 ASA(Adaptive Security Appliance)에서의 멀티캐스트 라우팅 및 일반적인 문제에 대해 설명합니다.

기능 정보

firepower 참고: ASA(Adaptive Security Appliance), FTD(Monitoring Threat Defense) 또는 FTD(Secure Firewall Threat Defense)의 멀티캐스트 라우팅에 대한 업데이트된 내용은 다음 문서를 참조하십시오.

firepower 위협 방어 IGMP 및 멀티캐스트 기본 문제 해결

firepower 위협 방어 및 ASA Multicast PIM 문제 해결

약어/약어

약어

설명

FHR

First-Hop Router - 멀티캐스트 트래픽의 소스에 직접 연결된 홉입니다.

LHR

Last-Hop Router - 멀티캐스트 트래픽의 수신자에 직접 연결된 홉입니다.

RP

랑데부 지점

박사

전용 라우터

SPT

최단 경로 트리

RPT

RP(Rendezvous-Point) 트리, 트리 공유

RPF

역방향 경로 전달

석유

발송 인터페이스 목록

MRIB

멀티캐스트 라우팅 정보 기반

MFIB

멀티캐스트 전달 정보 베이스

ASM

Any-Source 멀티캐스트

BSR

부트스트랩 라우터

SSM

소스별 멀티캐스트

FP

빠른 경로

SP

느린 경로

CP

제어 지점

PPS

패킷/초 비율

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

- PIM sparse-mode(Protocol Independent Multicast: RFC 4601)

- IGMP Stub-mode(Internet Group Management Protocol: RFC 2236)

ASA가 진정한 PIM(Multicast Routing Protocol)을 통해 네이버와 통신하므로 PIM sparse-mode가 선호됩니다. IGMP Stub-mode는 ASA 버전 7.0이 릴리스되기 전의 유일한 멀티캐스트 컨피그레이션 옵션이며, 클라이언트에서 수신한 IGMP 보고서를 업스트림 라우터로 전달하는 것만으로 작동합니다.

멀티캐스트의 구성 요소

일반적으로 멀티캐스트 인프라는 다음 구성 요소로 구성됩니다.

Sender => 멀티캐스트 스트림을 시작하는 호스트 또는 네트워크 디바이스. EIGRP 또는 OSPF와 같은 라우팅 프로토콜을 실행하는 네트워크 디바이스 및 비디오 및/또는 오디오 스트림을 전송하는 서버를 예로 들 수 있습니다.

Receiver => 멀티캐스트 스트림을 수신하는 호스트 또는 디바이스 이 용어는 트래픽에 적극적으로 관심이 있는 호스트에서 더 자주 사용되며 IGMP를 사용하여 문제의 멀티캐스트 그룹에 가입하거나 탈퇴합니다.

라우터/ASA => 소스에서 클라이언트로 필요할 때 멀티캐스트 스트림/트래픽을 처리하고 네트워크의 다른 세그먼트로 전달하는 네트워크 장치입니다.

Multicast Routing Protocol => 멀티캐스트 패킷 전달을 담당하는 프로토콜입니다. 가장 일반적인 방법은 PIM(Protocol Independent Multicast)이지만 MOSPF와 같은 다른 기능도 있습니다.

IGMP(Internet Group Management Protocol) => 클라이언트가 특정 그룹에서 멀티캐스트 스트림을 수신하는 데 사용하는 프로세스입니다.

PIM 스파스 모드 작업

- ASA는 PIM sparse-mode 및 PIM 양방향 모드를 지원합니다.

- PIM sparse-mode 및 IGMP stub-mode 명령은 동시에 구성할 수 없습니다.

- PIM sparse-mode에서는 모든 멀티캐스트 트래픽이 처음에 RP(Rendezvous Point)로 이동한 다음 수신기로 전달됩니다. 일정 시간이 지나면 멀티캐스트 흐름이 소스에서 수신기로 직접 이동합니다(그리고 RP를 우회합니다).

이 그림에서는 ASA가 하나의 인터페이스에 멀티캐스트 클라이언트가 있고 다른 인터페이스에 PIM 인접 디바이스가 있는 일반적인 구축을 보여줍니다.

PIM Sparse-mode 샘플 컨피그레이션

1. 멀티캐스트 라우팅을 활성화합니다(글로벌 컨피그레이션 모드).

ASA(config)# multicast-routing

2. PIM Rendezvous-point 주소를 정의합니다.

ASA(config)# pim rp-address 172.18.123.3

3. 해당 인터페이스에서 멀티캐스트 패킷을 허용합니다(ASA의 보안 정책이 인바운드 멀티캐스트 패킷을 차단하는 경우에만 필요함).

access-list 105 extended permit ip any host 224.1.2.3

access-group 105 in interface outside

PIM 스파스 모드 예:

클라이언트 IGMP 등록(빨간색 단계)과 서버에서 수신하는 스트림(녹색 단계)은 서로 다른 색상으로 표시되어 있으며, 이러한 방식으로 두 프로세스가 모두 독립적으로 발생할 수 있음을 입증했습니다.

클라이언트 등록 단계(빨간색 단계):

1. 클라이언트가 그룹 239.1.1.77에 대한 IGMP 보고서를 보냅니다.

2. 라우터가 그룹 239.1.1.77에 대해 구성된 고정 RP(10.1.1.1)에 PIM 조인 메시지를 보냅니다.

3. ASA가 그룹 239.1.1.77에 대한 PIM Join 메시지를 RP에 보냅니다.

ASA는 show mroute 명령 출력에 PIM *,G 항목을 표시합니다.

ciscoasa# show mroute 239.1.1.77

Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,

C - Connected, L - Local, I - Received Source Specific Host Report,

P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,

J - Join SPT

Timers: Uptime/Expires

Interface state: Interface, State

(*, 239.1.1.77), 00:03:43/00:02:41, RP 10.1.1.1, flags: S

Incoming interface: outside

RPF nbr: 10.38.111.240

Immediate Outgoing interface list:

inside, Forward, 00:03:43/00:02:41

그러나 소스 서버에서 어떤 스트림도 시작하지 않았으므로 ASA의 "show mfib" 출력에는 수신된 패킷이 표시되지 않습니다.

ciscoasa# show mfib 239.1.1.77

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

(*,239.1.1.77) Flags: C K

Forwarding: 0/0/0/0, Other: 0/0/0

outside Flags: A

inside Flags: F NS

Pkts: 0/0

서버가 멀티캐스트 그룹에 트래픽을 전송하기 전에 RP는 목록에 수신 인터페이스가 없는 "*.G" 항목만 표시합니다. 예를 들면 다음과 같습니다.

CRSv#show ip mroute 239.1.1.77

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

Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.77), 00:00:02/00:03:27, RP 10.1.1.1, flags: S

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

GigabitEthernet2, Forward/Sparse-Dense, 00:00:02/00:03:27

서버가 멀티캐스트 그룹으로 스트리밍하기 시작하면 RP는 "S,G" 항목을 생성하고 인터페이스를 수신 인터페이스 목록의 발신자에게 보내고 트래픽을 ASA로 다운스트림 보내기 시작합니다.

CRSv#show ip mroute 239.1.1.77

...

(*, 239.1.1.77), 00:03:29/stopped, RP 10.1.1.1, flags: SF

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

GigabitEthernet2, Forward/Sparse-Dense, 00:03:29/00:02:58

(10.38.118.10, 239.1.1.77), 00:00:07/00:02:52, flags: FT

Incoming interface: GigabitEthernet1, RPF nbr 0.0.0.0

Outgoing interface list:

GigabitEthernet2, Forward/Sparse-Dense, 00:00:07/00:03:22

확인에 다음 명령을 사용합니다.

- show mroute 명령은 "S,G" 항목을 표시합니다.

- show mfib 명령은 전달 패킷 카운터를 표시합니다.

- show conn 명령은 멀티캐스트 그룹 ip와 관련된 연결을 표시합니다.

ciscoasa# show mroute 239.1.1.77

Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,

C - Connected, L - Local, I - Received Source Specific Host Report,

P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,

J - Join SPT

Timers: Uptime/Expires

Interface state: Interface, State

(*, 239.1.1.77), 00:06:22/00:02:50, RP 10.1.1.1, flags: S

Incoming interface: outside

RPF nbr: 10.38.111.240

Immediate Outgoing interface list:

inside, Forward, 00:06:22/00:02:50

(10.38.118.10, 239.1.1.77), 00:03:00/00:03:28, flags: ST

Incoming interface: outside

RPF nbr: 10.38.111.240

Immediate Outgoing interface list:

inside, Forward, 00:03:00/00:03:26

ciscoasa# show mfib 239.1.1.77

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

(*,239.1.1.77) Flags: C K

Forwarding: 15/0/1271/0, Other: 0/0/0

outside Flags: A

inside Flags: F NS

Pkts: 0/15

(10.38.118.10,239.1.1.77) Flags: K

Forwarding: 7159/34/1349/360, Other: 0/0/0

outside Flags: A

inside Flags: F NS

Pkts: 7159/5

ciscoasa# show conn all | i 239.1.1.77

UDP outside  10.38.118.10:58944 inside  239.1.1.77:5004, idle 0:00:00, bytes 10732896, flags -

UDP outside  10.38.118.10:58945 inside  239.1.1.77:5005, idle 0:00:01, bytes 2752, flags -

UDP outside  10.38.118.10:58944 NP Identity Ifc  239.1.1.77:5004, idle 0:00:00, bytes 0, flags -

UDP outside  10.38.118.10:58945 NP Identity Ifc  239.1.1.77:5005, idle 0:00:01, bytes 0, flags -

참고: 클라이언트가 멀티캐스트 클라이언트 애플리케이션을 닫으면 호스트가 IGMP 쿼리 메시지를 전송합니다.

클라이언트가 스트림을 수신하고자 할 때 라우터가 아는 유일한 호스트인 경우 라우터는 RP에 IGMP Prune 메시지를 보냅니다.

IGMP 스텁 모드 작업

- IGMP 스텁 모드에서는 ASA가 멀티캐스트 클라이언트 역할을 하며, 멀티캐스트 트래픽 수신을 트리거하기 위해 IGMP 보고서(IGMP "조인"이라고도 함)를 인접 라우터로 생성하거나 전달합니다

- 라우터는 정기적으로 호스트에 쿼리를 보내 네트워크의 노드가 멀티캐스트 트래픽을 계속 수신하기를 원하는지 확인합니다.

- PIM sparse-mode가 Stub-mode보다 많은 이점을 제공하므로 IGMP Stub-mode는 권장되지 않습니다(보다 효율적인 멀티캐스트 트래픽 흐름, PIM에 참여할 수 있는 기능 등).

이 그림에서는 IGMP 스텁 모드에 대해 구성된 ASA의 기본 작업을 보여줍니다.

IGMP 스텁 모드 컨피그레이션

1. 멀티캐스트 라우팅(전역 구성 모드)을 활성화합니다.

ASA(config)# multicast-routing

2. 방화벽이 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

!

3. 해당 인터페이스에서 멀티캐스트 패킷을 허용합니다(ASA의 보안 정책이 인바운드 멀티캐스트 트래픽을 거부하는 경우에만 필요함).

ASA(config)# access-list 105 extended permit ip any host 224.1.2.3

ASA(config)# access-group 105 in interface outside

종종 여러 igmp interface 하위 모드 명령 주위에 혼란이 있으며, 이 다이어그램에서는 각 명령을 사용하는 시기를 설명합니다.

비디르 PIM

양방향 PIM에서는 SPT(Shared Tree)가 없습니다. 이는 세 가지를 의미합니다.

1. 첫 번째 홉 라우터(발신자에 연결됨)가 RP에 PIM 레지스터 패킷을 전송하지 않습니다.

2. RP는 소스 트리에 참여하기 위해 PIM JOIN 메시지를 보내지 않습니다.

3. 수신기 경로의 라우터가 RP를 향해 PIM 조인 메시지를 전송하여 RPT에 조인합니다.

이는 디바이스가 SPT에 조인하지 않기 때문에 ASA에서 (S,G)를 생성하지 않음을 의미합니다. 모든 멀티캐스트 트래픽은 RP를 통과합니다. ASA는 (*,G)가 있는 한 모든 멀티캐스트 트래픽을 전달합니다. (*,G)가 없으면 ASA에서 PIM 조인 패킷을 수신하지 않은 것입니다. 이 경우 ASA는 멀티캐스트 패킷을 전달해서는 안 됩니다.

Bidir PIM 컨피그레이션

1. 멀티캐스트 라우팅을 활성화합니다(글로벌 컨피그레이션 모드).

ASA(config)# multicast-routing

2. PIM Rendezvous-point 주소를 정의합니다.

ASA(config)# pim rp-address 172.18.123.3 bidir

3. 해당 인터페이스에서 멀티캐스트 패킷을 허용합니다(ASA의 보안 정책이 인바운드 멀티캐스트 패킷을 차단하는 경우에만 필요함).

access-list 105 extended permit ip any host 224.1.2.3

access-group 105 in interface outside

문제 해결 방법론

멀티캐스트 문제 해결 시 수집하기 위한 정보

ASA에서 멀티캐스트 포워딩 문제를 완전히 파악하고 진단하려면 다음 정보 중 일부 또는 전부가 필요합니다.

· 네트워크 토폴로지, 멀티캐스트 발신자, 수신자 및 랑데부 포인트에 대한 설명

· 특정 그룹 IP 주소, 사용된 포트 및 프로토콜.

· 멀티캐스트 스트림에 문제가 있을 때 ASA에서 생성된 Syslog.

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

show mroute

show mfib

show pim neighbor

show route

show tech-support

· 패킷이 캡처되어 멀티캐스트 데이터가 ASA에 도착하는지, 그리고 패킷이 ASA를 통해 전달되는지 보여줍니다(패킷 의 IP TTL(Time to Live)을 기록해 둡니다. 이는 'show capture x detail' 명령을 통해 확인할 수 있습니다.)

· IGMP 및/또는 PIM 패킷의 패킷 캡처 예:

capture cap1 interface outside match ip any host 239.1.1.77  >>> This captures the multicast traffic itself

capture cappim1 interface inside match pim any any           >>> This captures PIM Join/Prune messages

capture capigmp interface inside match igmp any any          >>> This captures IGMP Report/Query messages

· "show mroute" 및 "show mfib"와 같은 인접 멀티캐스트 디바이스(라우터)의 정보.

· 패킷 캡처 및/또는 show 명령을 사용하여 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

패킷 캡처

온보드 패킷 캡처 유틸리티는 멀티캐스트 문제를 해결하는 데 매우 유용합니다. 이 예에서는 239.17.17.17로 향하는 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

....

show capture x detail 명령의 출력에는 패킷의 TTL이 표시되며 이는 매우 유용합니다. 이 출력에서 패킷의 TTL은 1이지만(ASA는 기본적으로 IP 패킷의 TTL을 감소시키지 않으므로 이 패킷을 전달함) 다운스트림 라우터는 패킷을 삭제합니다.

ASA# show cap capout detail

453 packets captured

...

1: 14:40:39.427147 c062.6baf.8dc3 0100.5e7f.02c3 0x8100 Length: 1362

802.1Q vlan#1007 P0 10.4.2.95.1806 > 239.255.2.195.5000:  [udp sum ok] udp 1316 (DF) [ttl 1] (id 0)

패킷 캡처는 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#

패킷의 TTL은 'show capture x detail' 명령을 통해 확인할 수 있습니다.

여기서는 삭제된 멀티캐스트 패킷과 삭제 이유를 표시하는 ASP 삭제 캡처를 볼 수 있습니다(punt-rate-limit).

ASA#  show cap capasp det

12: 14:37:26.538332 c062.6baf.8dc3 0100.5e7f.02c3 0x8100 Length: 1362

802.1Q vlan#1007 P0 10.76.4.95.1806 > 239.255.2.195.5000:  [udp sum ok] udp 1316 (DF) [ttl 1] (id 0) Drop-reason: (punt-rate-limit) Punt rate limit exceeded

13: 14:37:26.538439 c062.6baf.8dc3 0100.5e7f.02c3 0x8100 Length: 1362

802.1Q vlan#1007 P0 10.76.4.95.1806 > 239.255.2.195.5000:  [udp sum ok] udp 1316 (DF) [ttl 1] (id 0) Drop-reason: (punt-rate-limit) Punt rate limit exceeded

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

이 다이어그램은 ASA가 PIM 스파스 모드에서 인접 디바이스와 상호 작용하는 방법을 보여줍니다.

네트워크 토폴로지 이해

특정 멀티캐스트 스트림의 발신자 및 수신자의 위치를 정확하게 확인합니다. 또한 멀티캐스트 그룹 IP 주소 및 랑데부 지점의 위치를 결정합니다.

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

ASA가 수신기에서 IGMP 보고서를 수신하는지 확인합니다

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

패킷 캡처 및 디버그 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.50

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

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

패킷 캡처와 함께 show mroute 및 show mfib 명령을 사용하여 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 멀티캐스트 관련 문제를 제공합니다

ASA에서 HSRP로 인해 업스트림 라우터로 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에만 국한되지 않으며 라우터에도 영향을 미칩니다. 이 문제는 라우팅 테이블 컨피그레이션과 PIM 네이버에서 사용하는 HSRP 컨피그레이션의 조합에 의해 트리거됩니다.

라우팅 테이블은 다음 홉 디바이스로 HSRP IP 10.0.0.1을 가리킵니다.

ciscoasa# show run route

route outside 0.0.0.0 0.0.0.0 10.0.0.1 1

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

ciscoasa# show 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 인접 디바이스에 주기적인 Join/Prune 메시지를 보냅니다. Join/Prune 메시지는 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 출력은 다른 디바이스가 내부 인터페이스 네트워크의 Designated Router("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)

기본적으로 PIM은 multicast-routing 명령이 컨피그레이션에 추가될 때 모든 ASA 인터페이스에서 활성화됩니다. ASA(클라이언트가 상주하는)의 내부 인터페이스에 다른 PIM 네이버(다른 라우터 또는 ASA)가 있고 해당 세그먼트의 DR로 인해 이러한 네이버 중 하나가 선택된 경우 다른 비 DR 라우터는 IGMP 보고서를 삭제합니다. 해결 방법은 인터페이스에서 PIM을 비활성화하거나(인터페이스에 no pim 명령 사용) pim dr-priority interface 명령을 통해 ASA를 세그먼트의 DR로 만드는 것입니다.

IGMP 인터페이스 제한이 초과되면 방화벽에 의해 IGMP 보고서가 거부됨

기본적으로 ASA에서는 인터페이스에서 추적된 500개의 현재 활성 조인(보고서)을 허용합니다. 구성 가능한 최대값입니다. 인터페이스에서 벗어난 클라이언트에서 많은 멀티캐스트 스트림을 요청하는 경우 최대 500개의 활성 조인이 발생할 수 있으며, ASA는 멀티캐스트 수신기에서 추가로 들어오는 IGMP 보고서를 무시할 수 있습니다.

이것이 멀티캐스트 오류의 원인인지 확인하려면 'show igmp interface interfacename' 명령을 실행하고 인터페이스의 'IGMP limit' 정보를 확인합니다.

ASA# show igmp interface inside

Hosting-DMZ is up, line protocol is up

Internet address is 10.11.27.13/24

IGMP is enabled on interface

Current IGMP version is 2

IGMP query interval is 125 seconds

IGMP querier timeout is 255 seconds

IGMP max query response time is 10 seconds

Last member query response interval is 1 seconds

Inbound IGMP access group is:

IGMP limit is 500, currently active joins: 500

Cumulative IGMP activity: 7018 joins, 6219 leaves

IGMP querying router is 10.11.27.13 (this system)

DEBUG - IGMP: Group x.x.x.x limit denied on outside

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

한 가지 옵션은 트래픽의 발신자에 대한 mroute를 추가하는 것입니다. 이 예에서는 mroute 명령을 사용하여 외부 인터페이스에서 수신된 172.16.1.2에서 소싱된 멀티캐스트 트래픽에 대한 RPF 검사를 충족합니다.

ciscoasa(config)# mroute 172.16.1.2 255.255.255.255 outside

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

초기에 PIM 스파스 모드 멀티캐스트 패킷은 멀티캐스트 발신자에서 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 클라이언트 애플리케이션(널리 사용되는 멀티캐스트 송신기 및 테스트 도구)은 기본적으로 IP 패킷의 TTL을 1로 설정합니다.

특정 멀티캐스트 토폴로지로 인해 ASA에서 높은 CPU 사용량이 발생하고 삭제된 패킷이 발생합니다

ASA는 높은 CPU를 경험할 수 있으며, 멀티캐스트 토폴로지에 대해 이러한 모든 사항이 참인 경우 멀티캐스트 스트림에서 패킷 삭제를 경험할 수 있습니다.

1. ASA는 RP 역할을 합니다.

2. ASA는 멀티캐스트 스트림의 첫 번째 홉 수신기입니다. 이는 멀티캐스트 발신자가 ASA 인터페이스와 동일한 IP 서브넷에 있음을 의미합니다.

3. ASA는 멀티캐스트 스트림의 마지막 홉 라우터입니다. 즉, 멀티캐스트 수신자가 ASA 인터페이스와 동일한 IP 서브넷에 있습니다.

언급된 모든 증상이 발생하면 설계 제한으로 인해 ASA는 멀티캐스트 트래픽을 강제로 전환해야 합니다. 따라서 데이터 속도가 빠른 멀티캐스트 스트림이 패킷 삭제를 경험하게 됩니다. 이러한 패킷이 삭제될 때 증가하는 show asp drop 카운터는 punt-rate-limit입니다.

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

1단계: ASA가 RP인지 확인:

show run pim

show pim tunnel

2단계: ASA가 마지막 홉 라우터인지 확인합니다.

show igmp group <mcast_group_IP>

3단계: ASA가 첫 번째 홉 라우터인지 확인합니다.

show mroute <mcast_group_IP>

이 문제를 완화하기 위해 다음 단계를 수행할 수 있습니다.

- ASA가 RP가 되지 않도록 토폴로지를 수정합니다. 또는 발신자 또는 수신자를 ASA에 직접 연결하지 않도록 설정합니다

- PIM 대신 멀티캐스트 전달에 IGMP stub-mode를 사용합니다.

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

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

이러한 이유로 삭제된 패킷의 ASP 삭제 사유는 "(punt-rate-limit) Punt rate limit exceeded"입니다. 이는 'show capture asp'의 출력입니다(여기서 asp는 삭제된 패킷을 캡처하도록 ASA에 구성된 ASP 삭제 캡처입니다). 이러한 이유로 삭제된 멀티캐스트 패킷을 확인할 수 있습니다.

ASA # show 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

연결을 끊는 멀티캐스트 수신기가 다른 인터페이스에서 멀티캐스트 그룹 수신을 중단합니다

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

이 문제는 Cisco 버그 ID CSCeg로 식별됩니다48235 한 인터페이스에서 IGMP Leave는 다른 인터페이스의 멀티캐스트 트래픽을 중단합니다.

버그의 릴리스 노트로, 문제를 설명합니다.

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 the 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, so their IGMP reports are forwarded towards the sender more frequently, thus restarting the stream quicker.

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

이 특정 문제와 함께 ASA는 구성된 보안 정책에 따라 멀티캐스트 패킷을 삭제합니다. 그러나 네트워크 관리자가 패킷 삭제의 원인을 파악하기는 어렵습니다. 이 경우 ASA는 인터페이스에 대해 구성된 아웃바운드 액세스 목록으로 인해 패킷을 삭제합니다. 해결 방법은 아웃바운드 access-list에서 멀티캐스트 스트림을 허용하는 것입니다.

이 경우 ASP 삭제 카운터 "FP no mcast output intf (no-mcast-intf)"를 사용하여 멀티캐스트 패킷이 삭제됩니다.

ASA는 제어 지점 속도 제한으로 인해 멀티캐스트 스트림의 일부 패킷(전부는 아님)을 지속적으로 삭제합니다

punt-rate-limit로 인해 트래픽이 제어 지점에 의해 속도 제한되는 경우가 가장 많습니다. asp 삭제 출력 및 캡처를 확인하여 다음을 확인합니다.

ASA# show asp drop

Frame drop:

Punt rate limit exceeded (punt-rate-limit)                             1492520

ASA#  show cap capasp det

12: 14:37:26.538332 c062.6baf.8dc3 0100.5e7f.02c3 0x8100 Length: 1362

802.1Q vlan#1007 P0 10.76.4.95.1806 > 239.255.2.195.5000:  [udp sum ok] udp 1316 (DF) [ttl 1] (id 0) Drop-reason: (punt-rate-limit) Punt rate limit exceeded

mfib 항목은 모든 트래픽이 프로세스 스위칭됨을 보여줍니다.

ASA(config)# show mfib  239.255.2.1195

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

(*,239.255.2.195) Flags: C K

Forwarding: 4278/50/1341/521, Other: 0/0/0

Outside-1007 Flags: A

RDEQ-to-Corporate Flags: F NS

Pkts: 0/4278                               <---- HERE

멀티캐스트 라우팅 테이블에는 (*,G)가 표시되지만 (S,G)는 표시되지 않습니다.

ASA(config)# show mroute  239.255.2.1195

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,

C - Connected, L - Local, I - Received Source Specific Host Report,

P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,

J - Join SPT

Timers: Uptime/Expires

Interface state: Interface, State

(*, 239.255.2.195), 00:44:03/00:02:44, RP 10.1.135.10, flags: S

Incoming interface: Outside-1007

RPF nbr: 10.100.254.18

Immediate Outgoing interface list:

RDEQ-to-Corporate, Forward, 00:44:03/00:02:44

여기서 문제는 ASA에 도착하는 멀티캐스트 데이터 패킷의 TTL이 1이라는 점입니다. ASA는 이러한 패킷을 다운스트림 디바이스로 전달하지만(TTL이 감소하지 않기 때문) 라우터 다운스트림에서 패킷을 삭제합니다. 따라서 다운스트림 라우터는 PIM(S,G) 조인(소스별 조인)을 ASA로 발신자에게 전송하지 않습니다. ASA는 이 PIM 조인을 수신할 때까지 (S,G) 항목을 작성하지 않습니다. (S,G)가 구축되지 않았으므로 모든 멀티캐스트 트래픽이 프로세스 스위칭되어 속도 제한이 발생합니다.

이 문제의 해결 방법은 패킷의 TTL이 1이 아닌 경우 다운스트림 디바이스에서 발신자를 향해 소스별 조인을 보낼 수 있도록 하는 것입니다. 그러면 ASA에서 테이블에 소스별 경로를 설치한 다음 모든 패킷이 빠른 전환(처리된 전환 대신)되고 트래픽이 문제 없이 ASA를 통과해야 합니다.

PIM ASSERT 메시지로 인해 멀티캐스트 스트림이 중단되었습니다

두 네트워크 디바이스가 동일한 멀티캐스트 패킷을 동일한 서브넷에 전달하는 경우, 이상적으로는 그 중 하나가 패킷 전달을 중지해야 합니다(스트림을 복제하는 것은 낭비이므로). PIM을 실행 중인 라우터가 동일한 인터페이스에서 생성하는 동일한 패킷을 받으면 해당 LAN에서 ASSERT 메시지를 생성하여 어떤 네트워크 디바이스가 스트림 전달을 중지할지 선택합니다.

이 메시지에 대한 자세한 내용은 ASSERT 프로세스와 관련된 RFC 4601 단원에 나와 있습니다.

디버그는 ASA가 그룹 239.1.1.227에 대한 IGMP 보고서를 수신하지만, 인접 라우터에서 수신하는 assert 메시지로 인해 보고서를 무시한다는 것을 보여줍니다.

IPv4 PIM: (*,239.1.1.227) Periodic J/P scheduled in 50 secs

IPv4 PIM: (*,239.1.1.227) J/P adding Join on outside

IPv4 PIM: (10.99.41.205,239.1.1.227)RPT J/P adding Prune on outside

IPv4 PIM: (10.99.41.253,239.1.1.227)RPT J/P adding Prune on outside

IGMP: Received v2 Report on inside from 10.20.213.204 for 239.1.1.227

IGMP: Updating EXCLUDE group timer for 239.1.1.227

IPv4 PIM: (10.99.41.253,239.1.1.227) Received [15/110] Assert from 10.20.13.2 on inside

IPv4 PIM: (10.99.41.253,239.1.1.227) Assert processing message wins

IPv4 PIM: (10.99.41.253,239.1.1.227) inside Update assert timer (winner 10.20.13.2)

이 문제는 두 개의 사이트가 레이어 2에 실수로 연결된 프로덕션 네트워크에서 관찰되었습니다. 따라서 멀티캐스트 수신자가 있는 LAN에는 두 개의 디바이스가 멀티캐스트 트래픽을 포워딩했습니다. 또 다른 네트워크 문제로 인해 ASA와 다른 디바이스가 PIM Hello를 통해 서로를 감지할 수 없으므로 둘 다 LAN에 대한 Designated Router 역할을 맡았습니다. 이로 인해 멀티캐스트 트래픽이 잠시 동안 작동한 다음 디바이스에서 ASSERT 메시지를 전송하면 실패합니다. 문제를 해결하기 위해 레이어 2에서 디바이스를 연결하는 잘못된 연결을 비활성화한 다음 문제를 해결했습니다.

ASA에서 PIM 참가를 전송하지만 패킷 크기가 MTU보다 크기 때문에 네이버에서 처리하지 않습니다

이는 629575899년에 관찰되었습니다. ASA가 점보 프레임으로 구성되었지만 4900은 구성되지 않았습니다. 클라이언트가 73개가 넘는 멀티캐스트 스트림을 요청하면 특정 멀티캐스트 스트림이 작동하지 않습니다. 73개의 SG는 크기가 1494(아직 MTU 내에 있음)인 PIM 조인 메시지를 생성합니다. 74개의 SG는 1500보다 큰 PIM 조인 메시지를 생성합니다. 이로 인해 4900M은 패킷 인바운드를 삭제합니다.

이 문제의 해결 방법:

1. 점보 프레임이 4900M에서 전역적으로 활성화되었는지 확인합니다.

2. MTU 9216으로 물리적 인터페이스와 SVI를 모두 구성합니다