La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
Questo documento descrive il routing multicast su Adaptive Security Appliance (ASA) e i problemi comuni.
Acronimi |
Spiegazione |
FHR |
Router del primo hop: hop connesso direttamente all'origine del traffico multicast. |
LHR |
Router dell'ultimo hop: hop collegato direttamente ai destinatari del traffico multicast. |
RP |
Rendezvous-Point |
DR. |
Router designato |
SPT |
Albero del percorso più breve |
RPT |
Struttura ad albero di Rendezvous-Point (RP), albero condiviso |
RPF |
Inoltro percorso inverso |
PETROLIO |
Elenco interfacce in uscita |
MRIB |
Base informazioni routing multicast |
MFIB |
Base informazioni inoltro multicast |
ASM |
Multicast Any-Source |
BSR |
Bootstrap Router |
SSM |
Multicast specifico dell'origine |
FP |
Percorso rapido |
SP |
Percorso lento |
PC |
Punto di controllo |
PPS |
Frequenza pacchetti al secondo |
La modalità sparse del PIM è la scelta preferita perché l'ASA comunica con i router adiacenti tramite un vero protocollo PIM (Multicast Routing Protocol). La modalità Stub IGMP era l'unica opzione di configurazione multicast prima del rilascio di ASA versione 7.0 e funzionava semplicemente inoltrando i report IGMP ricevuti dai client verso i router upstream.
In generale, un'infrastruttura multicast è composta dai seguenti componenti:
Mittente => Host o dispositivo di rete da cui proviene il flusso multicast. Ad esempio, un server che invia flussi video e/o audio e dispositivi di rete che eseguono un protocollo di routing, quale EIGRP o OSPF.
Receiver => Host o dispositivo che riceve il flusso multicast. Questo termine viene utilizzato più di frequente per gli host attivamente interessati al traffico e utilizza IGMP per unirsi o uscire dal gruppo multicast in questione.
Router / ASA => Dispositivi di rete responsabili dell'elaborazione e dell'inoltro del traffico/flusso multicast ad altri segmenti della rete quando necessario, dall'origine ai client.
Protocollo di routing multicast => Protocollo responsabile dell'inoltro dei pacchetti multicast. Il più comune è PIM (Protocol Independent Multicast), ma ce ne sono altri come MOSPF per esempio.
IGMP (Internet Group Management Protocol) => Processo utilizzato dai client per ricevere un flusso multicast da un determinato gruppo.
Con la modalità sparse del PIM tutto il traffico multicast inizialmente fluisce verso il punto di rendering (RP), quindi viene inoltrato verso i ricevitori. Dopo qualche tempo il flusso multicast passa direttamente dalla sorgente ai ricevitori (e bypassa l'RP).
In questa immagine viene illustrata una distribuzione comune in cui l'ASA ha client multicast su un'interfaccia e vicini PIM su un'altra interfaccia:
1. Abilitare il routing multicast (modalità di configurazione globale).
ASA(config)# multicast-routing
2. Definire l'indirizzo del punto di rendering PIM.
ASA(config)# pim rp-address 172.18.123.3
3. Consentire l'ingresso dei pacchetti multicast sull'interfaccia appropriata (necessario solo se i pacchetti multicast in entrata sono bloccati dai criteri di sicurezza dell'ASA).
access-list 105 extended permit ip any host 224.1.2.3 access-group 105 in interface outside
Si noti che la registrazione IGMP del client (passaggi in rosso) e il flusso ricevuto dal server (passaggi in verde) sono stati colorati in modo diverso, e questo è stato fatto in questo modo per dimostrare che entrambi i processi possono verificarsi in modo indipendente.
Fasi della registrazione del client (fasi rosse):
1. Il client invia un report IGMP per il gruppo 239.1.1.77
2. Il router invia un messaggio di unione PIM all'RP statica configurata (10.1.1.1) per il gruppo 239.1.1.77.
3. L'ASA invia all'RP un messaggio di unione PIM per il gruppo 239.1.1.77.
ASA visualizza la voce PIM *,G sull'output del comando show mroute:
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
Tuttavia, poiché il server di origine non ha avviato alcun flusso, l'output "show mfib" sull'appliance ASA non visualizza i pacchetti ricevuti:
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
Prima che il server inizi a inviare traffico al gruppo multicast, nell'RP viene visualizzata solo una voce "*.G" senza alcuna interfaccia in ingresso nell'elenco, ad esempio:
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
Quando il server inizia a inviare lo streaming al gruppo multicast, l'RP crea una voce "S,G" e inserisce l'interfaccia rivolta al mittente nell'elenco delle interfacce in arrivo e inizia a inviare il traffico a valle all'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
Utilizzare i seguenti comandi per le verifiche:
- show mroute visualizza una voce "S,G"
- show mfib, comando visualizza i contatori dei pacchetti in avanti
- il comando show conn visualizza la connessione correlata all'ip del gruppo multicast
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 -
Nota: dopo che il client ha chiuso l'applicazione client multicast, l'host invia un messaggio di query IGMP.
Nel caso in cui questo sia l'unico host conosciuto dal router come il client desideri ricevere il flusso, il router invia un messaggio IGMP Prune all'RP.
1. Abilitare il routing multicast (modalità di configurazione globale).
ASA(config)# multicast-routing
2. Configurare il comando igmp forward-interface sull'interfaccia su cui il firewall riceve i rapporti igmp. Inoltra i pacchetti dall'interfaccia verso l'origine del flusso. In questo esempio, i ricevitori multicast sono collegati direttamente all'interfaccia interna e la sorgente multicast è esterna.
! 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. Consentire l'ingresso dei pacchetti multicast sull'interfaccia appropriata (solo se i criteri di sicurezza dell'ASA negano il traffico multicast in entrata).
ASA(config)# access-list 105 extended permit ip any host 224.1.2.3 ASA(config)# access-group 105 in interface outside
Spesso i diversi comandi dell'interfaccia igmp in modalità secondaria sono confusi e questo diagramma descrive quando utilizzarli:
Nel PIM bidirezionale non è presente alcun albero condiviso (SPT). Questo significa tre cose:
1. Il primo router hop (collegato al mittente) non invia i pacchetti del registro PIM al punto di ripristino.
2. L'RP non invia messaggi di JOIN PIM per unirsi all'albero di origine.
3. I router nel percorso verso il destinatario inviano messaggi di join PIM all'RP per unirsi all'RPT.
Ciò significa che l'ASA non genera un (S,G) in quanto i dispositivi non si uniscono all'SPT. Tutto il traffico multicast passa attraverso il RP. L'ASA inoltra tutto il traffico multicast finché è presente un (*,G). Se non c'è (*,G), l'ASA non ha mai ricevuto un pacchetto di unione PIM. In questo caso, l'ASA non deve inoltrare pacchetti multicast.
1. Abilitare il routing multicast (modalità di configurazione globale).
ASA(config)# multicast-routing
2. Definire l'indirizzo del punto di rendering PIM.
ASA(config)# pim rp-address 172.18.123.3 bidir
3. Consentire l'ingresso dei pacchetti multicast sull'interfaccia appropriata (necessario solo se i pacchetti multicast in entrata sono bloccati dai criteri di sicurezza dell'ASA).
access-list 105 extended permit ip any host 224.1.2.3 access-group 105 in interface outside
Per comprendere e diagnosticare completamente un problema di inoltro multicast sull'appliance ASA, è necessario fornire alcune o tutte le informazioni seguenti:
show mroute show mfib show pim neighbor show route show tech-support
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
L'output del comando show mroute visualizza i vari gruppi e le informazioni di inoltro ed è molto simile al comando show mroute di IOS. Il comando show mfib visualizza lo stato di inoltro dei vari gruppi multicast. È particolarmente importante osservare il contatore del pacchetto di inoltro, nonché Altro (che indica le cadute):
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#
Il comando clear mfib counters può essere usato per cancellare i contatori, il che è molto utile durante il test:
ciscoasa# clear mfib counters
L'utilità di acquisizione pacchetti integrata è molto utile per risolvere i problemi relativi al multicast. Nell'esempio, vengono acquisiti tutti i pacchetti in entrata sull'interfaccia DMZ destinati alla versione 239.17.17.17:
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 ....
L'output del comando show capture x detail visualizza il valore TTL dei pacchetti, che è abbastanza utile. In questo output, il valore TTL del pacchetto è 1 (e l'ASA trasmette il pacchetto poiché non diminuisce il valore TTL dei pacchetti IP per impostazione predefinita), ma un router downstream scarta i pacchetti:
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)
Le acquisizioni dei pacchetti sono utili anche per acquisire il traffico PIM e IGMP. Questa acquisizione mostra che l'interfaccia interna ha ricevuto un pacchetto IGMP (protocollo IP 2) proveniente da 10.0.0.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#
Il valore TTL dei pacchetti può essere visualizzato con il comando "show capture x detail".
Qui è possibile vedere le clip acquisite da ASP che mostrano i pacchetti multicast scartati e il motivo per cui sono stati scartati (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
Nei diagrammi viene mostrata l'interazione dell'ASA con i dispositivi adiacenti in modalità sparse PIM.
Informazioni sulla topologia di rete
Determina esattamente la posizione dei mittenti e dei destinatari del flusso multicast specifico. Determinare inoltre l'indirizzo IP del gruppo multicast e la posizione del punto di rendering.
|
In questo caso, i dati possono essere ricevuti sull'interfaccia esterna dell'appliance ASA e inoltrati al ricevitore multicast sull'interfaccia interna. Poiché il ricevitore si trova nella stessa subnet IP dell'interfaccia interna dell'ASA, quando il client richiede di ricevere il flusso, deve essere visualizzato un report IGMP ricevuto sull'interfaccia interna. L'indirizzo IP del mittente è 192.168.1.50.
Verificare che l'appliance ASA riceva il report IGMP dal destinatario
In questo esempio, il report IGMP viene generato dal destinatario ed elaborato dall'ASA.
Le acquisizioni dei pacchetti e l'output del comando debug igmp possono essere usati per verificare che l'appliance ASA abbia ricevuto ed elaborato correttamente il messaggio IGMP.
Verificare che l'ASA invii un messaggio di join PIM verso il punto di rendering
L'ASA interpreta il report IGMP e genera un messaggio di join PIM, quindi lo invia all'interfaccia verso l'RP.
Questo output viene generato dal gruppo pim di debug 24.1.2.3 e mostra che l'ASA ha inviato correttamente il messaggio di join PIM. Il mittente del flusso multicast è 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
Verificare che l'appliance ASA riceva e inoltri il flusso multicast
L'ASA inizia a ricevere il traffico multicast sull'interfaccia esterna (illustrata dalle frecce verdi) e a inoltrarlo ai ricevitori all'interno.
I comandi show mroute e show mfib e le acquisizioni dei pacchetti possono essere usati per verificare che l'ASA riceva e inoltri i pacchetti multicast.
Nella tabella delle connessioni viene creata una connessione per rappresentare il flusso multicast:
ciscoasa# show conn 59 in use, 29089 most used ... UDP outside:192.168.1.50/52075 inside:224.1.2.3/1234 flags - ...
Questa sezione fornisce una serie di problemi correlati al multicast ASA reali
Quando si verifica questo problema, l'ASA non riesce a inviare alcun messaggio PIM all'esterno di un'interfaccia. Il diagramma mostra che l'ASA non può inviare messaggi PIM al mittente, ma lo stesso problema si verifica quando l'ASA deve inviare un messaggio PIM all'RP.
L'output del comando debug pim mostra che l'ASA non può inviare il messaggio PIM al router upstream dell'hop successivo:
IPv4 PIM: Sending J/P to an invalid neighbor: outside 10.0.0.1
Questo problema non riguarda solo l'appliance ASA, ma anche i router. Il problema viene attivato dalla combinazione della configurazione della tabella di routing e della configurazione HSRP utilizzata dai vicini PIM.
La tabella di routing punta all'IP 10.0.0.1 dell'HSRP come dispositivo dell'hop successivo:
ciscoasa# show run route route outside 0.0.0.0 0.0.0.0 10.0.0.1 1
Tuttavia, tra gli indirizzi IP dell'interfaccia fisica dei router e non tra l'indirizzo IP dell'HSRP si forma la relazione PIM adiacente:
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)
Per ulteriori informazioni, vedere "Perché la modalità sparse del PIM non funziona con un percorso statico a un indirizzo HSRP?".
Ecco un estratto del documento:
Perché il router non invia il messaggio di aggiunta/eliminazione? La RFC 2362 afferma che "un router invia un messaggio di join/eliminazione periodico a ogni singolo router adiacente RPF associato a ciascuna voce (S,G), (*,G) e (*,*,RP). I messaggi di unione/eliminazione vengono inviati solo se il router adiacente RPF è un router adiacente PIM."
Per risolvere il problema, aggiungere una voce relativa al percorso statico sull'appliance ASA per il traffico in questione. Accertarsi che punti a uno dei due indirizzi IP dell'interfaccia del router (10.0.0.2 o 10.0.0.3). In questo caso, il comando permette all'ASA di inviare messaggi PIM diretti al mittente multicast all'indirizzo 172.16.1.2:
ciscoasa(config)# mroute 172.16.1.2 255.255.255.255 10.0.0.3
Al termine, la tabella di routing multicast sostituisce la tabella di routing unicast dell'ASA e l'ASA invia i messaggi PIM direttamente alla versione adiacente 10.0.0.3.
Per questo problema, l'ASA riceve un report IGMP da un ricevitore multicast connesso direttamente, ma lo ignora. Non viene generato alcun output di debug e il pacchetto viene semplicemente scartato e la ricezione del flusso non riesce.
Per questo problema, l'ASA ignora il pacchetto perché non è il router PIM scelto sul segmento LAN in cui risiedono i client.
Questo output dell'ASA CLI mostra che un dispositivo diverso è il router designato (indicato da "DR") sulla rete dell'interfaccia interna:
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)
per impostazione predefinita, quando si aggiunge il comando multicast-routing alla configurazione, il protocollo PIM è abilitato su tutte le interfacce ASA. Se sull'interfaccia interna dell'ASA (dove risiedono i client) sono presenti altri router PIM adiacenti (altri router o appliance ASA) e uno di questi router adiacenti è stato scelto a causa del DR per il segmento in questione, gli altri router non DR eliminano i report IGMP. La soluzione è disabilitare il protocollo PIM sull'interfaccia (con il comando no pim sull'interfaccia interessata) o fare in modo che l'ASA venga usata come DR per il segmento tramite il comando pim dr-priority dell'interfaccia.
Per impostazione predefinita, l'ASA supporta 500 join attivi correnti (report) tracciati su un'interfaccia. Questo è il valore massimo configurabile. Se i client richiedono un numero elevato di flussi multicast da un'interfaccia, è possibile rilevare un massimo di 500 join attivi e l'ASA potrebbe ignorare altri report IGMP in arrivo dai ricevitori multicast.
Per verificare se questa è la causa di un errore multicast, usare il comando 'show igmp interface interface name' e cercare le informazioni 'IGMP limit' per l'interfaccia.
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
Questo intervallo di indirizzi deve essere usato con il multicast (SSM) specifico dell'origine che attualmente non è supportato dall'ASA.
L'output del comando debug igmp visualizza questo errore:
IGMP: Exclude report on inside ignored for SSM group 232.179.89.253
In questo caso, l'ASA riceve il traffico multicast su un'interfaccia, ma non viene inoltrata al destinatario. I pacchetti vengono scartati dall'ASA perché non superano il controllo di sicurezza RPF (Reverse Path Forwarding). L'RPF è abilitato su tutte le interfacce per il traffico multicast e non può essere disabilitato (per i pacchetti unicast il controllo non è abilitato per impostazione predefinita ed è abilitato con il comando ip verify-path interface).
A causa del controllo RPF, quando il traffico multicast viene ricevuto su un'interfaccia, l'ASA controlla che disponga di una route verso l'origine del traffico multicast (controlla la tabella di routing unicast e multicast) su quell'interfaccia. Se non ha un percorso verso il mittente, scarta il pacchetto. Queste gocce possono essere viste come un contatore nell'output di 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
Un'opzione consiste nell'aggiungere una route per il mittente del traffico. Nell'esempio, il comando mroute viene usato per verificare che RPF abbia generato traffico multicast proveniente da 172.16.1.2 ricevuto sull'interfaccia esterna:
ciscoasa(config)# mroute 172.16.1.2 255.255.255.255 outside
Inizialmente, i pacchetti multicast in modalità sparse del PIM passano dal mittente multicast all'RP, quindi dall'RP al destinatario tramite una struttura multicast condivisa. Tuttavia, quando la velocità in bit aggregata raggiunge una determinata soglia, il router più vicino al ricevitore multicast cerca di ricevere il traffico lungo la struttura specifica dell'origine. Questo router genera un nuovo join PIM per il gruppo e lo invia al mittente del flusso multicast (e non verso l'RP, come prima).
Il mittente del traffico multicast può risiedere su un'interfaccia ASA diversa da quella dell'RP. Quando l'ASA riceve il join PIM per passare all'albero specifico dell'origine, deve avere una route all'indirizzo IP del mittente. Se la route non viene trovata, il pacchetto di unione PIM viene scartato e questo messaggio viene visualizzato nell'output del pim di debug
NO RPF Neighbor to send J/P
Per risolvere questo problema, aggiungere una voce di route statica per il mittente del flusso che indichi l'interfaccia ASA da cui risiede il mittente.
In questo caso, il traffico multicast non riesce perché il valore TTL dei pacchetti è troppo basso. In questo modo, l'ASA, o un altro dispositivo della rete, li scarta.
Spesso i pacchetti multicast hanno un valore TTL IP impostato molto basso dall'applicazione che li ha inviati. A volte questa operazione viene eseguita per impostazione predefinita per evitare che il traffico multicast passi troppo lontano attraverso la rete. Per impostazione predefinita, ad esempio, la scheda Video LAN Per impostazione predefinita, l'applicazione client (un comune trasmettitore e strumento di prova multicast) imposta il valore TTL nel pacchetto IP su 1.
L'ASA può sperimentare una CPU elevata e il flusso multicast può sperimentare perdite di pacchetti se tutte le seguenti affermazioni sulla topologia multicast sono vere:
Se si riscontrano tutti i sintomi menzionati, A causa di una limitazione della progettazione, l'ASA è costretta a elaborare lo switch per il traffico multicast. Il risultato sono flussi multicast ad alta velocità di trasmissione dei dati che causano la perdita dei pacchetti. Il contatore show asp drop che aumenta quando questi pacchetti vengono scartati è punt-rate-limit.
Per stabilire se un'appliance ASA ha questo problema, attenersi alla seguente procedura:
Passaggio 1: verificare se l'ASA è l'RP:
show run pim show pim tunnel
Passaggio 2: verificare che l'ASA sia l'ultimo router hop:
show igmp group <mcast_group_IP>
Passaggio 3: verificare che l'ASA sia il router del primo hop:
show mroute <mcast_group_IP>
Per risolvere il problema, è possibile effettuare le seguenti operazioni:
- Modificare la topologia in modo che l'ASA non sia l'RP. In alternativa, verificare che il mittente o il destinatario non siano collegati direttamente all'appliance ASA
- Anziché PIM, utilizzare la modalità stub IGMP per l'inoltro multicast.
Quando i primi pacchetti di un flusso multicast arrivano all'appliance ASA, questa deve creare la connessione multicast e la voce del percorso associata per inoltrare i pacchetti. Mentre la voce è in fase di creazione, alcuni pacchetti multicast possono essere scartati fino a quando il routing e le connessioni non sono stati stabiliti (generalmente questa operazione richiede meno di un secondo). Una volta completata la configurazione del flusso multicast, i pacchetti non hanno più limiti di velocità.
I pacchetti scartati per questo motivo hanno il motivo di rilascio ASP per il superamento del limite di velocità Punt (punt-rate-limit). Questo è l'output di 'show capture asp' (dove asp è un'operazione di drop capture ASP configurata sull'appliance ASA per acquisire i pacchetti scartati). È possibile visualizzare i pacchetti multicast scartati per questo motivo:
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
Questo problema si verifica solo per le appliance ASA in modalità stub IGMP. Le appliance ASA che partecipano al routing multicast PIM non sono interessate.
Il problema è identificato dall'ID bug Cisco CSCeg48235 Il comando IGMP Leave su un'interfaccia interrompe il traffico multicast su altre interfacce.
Questa è la nota sulla versione del bug, che spiega il problema:
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.
Con questo problema specifico, l'ASA scarta i pacchetti multicast (in base ai criteri di sicurezza configurati). Tuttavia, è difficile per l'amministratore di rete identificare il motivo per cui il pacchetto viene scartato. In questo caso, l'ASA scarta i pacchetti a causa dell'elenco degli accessi in uscita configurato per un'interfaccia. Per ovviare al problema, è necessario autorizzare il flusso multicast nell'elenco degli accessi in uscita.
In questo caso, i pacchetti multicast vengono scartati con il contatore di rilascio ASP "FP no mcast output intrf (no-mcast-intrf)".
Il traffico è più probabile che la velocità sia limitata dal punto di controllo a causa del limite della velocità di punt. Osservare l'output del rilascio dell'asp e le acquisizioni per confermare:
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
La voce mfib mostra che tutto il traffico è commutato in base al processo:
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
Nella tabella di routing multicast viene visualizzato un asterisco (*,G) ma no (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
Il problema in questo caso è che il valore TTL dei pacchetti di dati multicast che arrivano all'appliance ASA è 1. L'ASA inoltra i pacchetti al dispositivo downstream (in quanto non riduce il valore TTL), ma il router downstream scarta i pacchetti. Di conseguenza, il router a valle non invia un join PIM (S,G) (un join specifico dell'origine) all'appliance ASA verso il mittente. L'ASA non crea una voce (S,G) finché non riceve questo join PIM. Poiché (S,G) non è generato, tutto il traffico multicast viene commutato in base al processo e ciò determina un limite di velocità.
Per risolvere questo problema, verificare che il valore TTL dei pacchetti non sia 1, in modo da consentire al dispositivo a valle di inviare il join specifico all'origine verso il mittente; in questo modo, l'ASA installa un percorso specifico all'origine nella tabella e tutti i pacchetti vengono commutati rapidamente (anziché commutati) e il traffico deve passare attraverso l'ASA senza alcun problema.
Se due dispositivi di rete inoltrano gli stessi pacchetti multicast sulla stessa subnet, uno di essi deve interrompere l'inoltro dei pacchetti (in quanto la duplicazione del flusso costituisce uno spreco). Se i router che eseguono PIM rilevano di ricevere gli stessi pacchetti generati anche sulla stessa interfaccia, generano messaggi ASSERT sulla LAN per selezionare il dispositivo di rete che arresta l'inoltro del flusso.
Per ulteriori informazioni su questo messaggio, consultare una sezione della RFC 4601 relativa al processo ASSERT.
I debug mostrano che l'ASA riceve un report IGMP per il gruppo 239.1.1.227, ma ignora il report a causa del messaggio di asserzione che riceve da un router adiacente:
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)
Questo problema è stato osservato in una rete di produzione in cui due siti sono stati involontariamente collegati al layer 2, in modo che la LAN su cui si trovavano i ricevitori multicast disponesse di due dispositivi che inoltravano il traffico multicast verso di essi. A causa di un altro problema di rete, l'ASA e un altro dispositivo non sono stati in grado di rilevarsi a vicenda tramite gli helper PIM e quindi entrambi hanno assunto il ruolo di router designato per la LAN. Il traffico multicast è rimasto in funzione per un certo periodo di tempo, quindi non è riuscito quando i dispositivi hanno inviato i messaggi ASSERT. Per risolvere il problema, la connessione errata che collegava i dispositivi al layer 2 è stata disabilitata e quindi il problema è stato risolto.
Questo è stato osservato in 629575899. L'ASA era stata configurata per i frame jumbo, mentre la 4900 non lo era. Quando il client ha richiesto più di 73 flussi multicast, alcuni flussi multicast non funzionerebbero. 73 SG creavano un messaggio di unione PIM di dimensioni 1494, che era ancora all'interno dell'MTU. 74SG creavano un messaggio di unione PIM di dimensioni maggiori di 1500, che causava il rifiuto del pacchetto da parte del 4900M.
Correzione del problema:
1. Assicurarsi che i frame jumbo siano abilitati globalmente sullo switch 4900M
2. Configurare sia l'interfaccia fisica che la SVI con una MTU di 9216
Revisione | Data di pubblicazione | Commenti |
---|---|---|
1.0 |
03-Jan-2013 |
Versione iniziale |