Problemen met ASA Multicast Common Problemen oplossen

Inleiding

Dit document beschrijft multicast routing op de adaptieve security applicatie (ASA) en algemene problemen.

Functieinformatie

• PIM sparse-mode (protocol onafhankelijke multicast: RFC 4601)
• IGMP stub-mode (Internet Group Management Protocol: RFC 2236)

PIM sparse-mode is de voorkeurskeuze omdat de ASA via een waar multicast routingprotocol (PIM) met zijn buren communiceert. IGMP Stub-mode was de enige multicast-configuratieoptie voordat ASA versie 7.0 werd uitgebracht. Deze optie werd bediend door IGMP-rapporten die van clients werden ontvangen eenvoudig naar upstream-routers door te sturen.

Componenten van Multicast

 In het algemeen bestaat een multicast-infrastructuur uit deze componenten:

Afzender => host- of netwerkapparaat dat de multicast-stroom genereert. De voorbeelden zijn server die video en/of audiostroom en netwerkapparaten verzendt die een Routing Protocol zoals EIGRP of OSPF in werking stellen. 

Ontvanger => host of apparaat dat de multicast-stroom ontvangt. Deze term wordt vaker gebruikt voor hosts die actief geïnteresseerd zijn in het verkeer en gebruik IGMP om de multicast groep in kwestie aan te sluiten of te verlaten.

Routers / ASA => Netwerkapparaten die verantwoordelijk zijn voor het verwerken en doorsturen van de multicast stream/het verkeer naar andere segmenten van het netwerk, indien nodig van de bron naar de client(s).

Multicast Routing Protocol => Protocol verantwoordelijk voor het doorsturen van de multicast pakketten. Het meest gebruikelijk is PIM (Protocol Independent Multicast), maar er zijn bijvoorbeeld anderen zoals MOSPF.

Internet Group Management Protocol (IGMP) => Proces dat door clients wordt gebruikt om een multicast-stroom van een bepaalde groep te ontvangen.

Bediening van PIM met reservemodus

• ASA ondersteunt de spaarstand PIM en de tweerichtingsmodus PIM.
• De opdrachten PIM sparse mode en IGMP stub-mode mogen niet tegelijkertijd worden geconfigureerd.

• Met PIM sparse-mode stroomt al multicast verkeer eerst naar het Rendezvous Point (RP), dan wordt doorgestuurd naar de ontvangers. Na enige tijd gaat de multicast stroom rechtstreeks van de bron naar de ontvangers (en omzeilt de RP).

Dit beeld illustreert een gemeenschappelijke plaatsing waar ASA multicast cliënten op één interface, en buren PIM op een andere heeft:

Configuratie PIM-reservemodus

1. Schakel multicast routing in (globale configuratiemodus).

ASA(config)# multicast-routing

 2. Bepaal het PIM Rendezvous-point adres.

ASA(config)# pim rp-address 172.18.123.3

 3. Sta de multicast-pakketten toe via de juiste interface (alleen nodig als het beveiligingsbeleid van de ASA de inkomende multicast-pakketten blokkeert).

access-list 105 extended permit ip any host 224.1.2.3
access-group 105 in interface outside

 Voorbeeld PIM Sparse Mode:

 Merk op dat de client IGMP registratie (stappen in rood) en de stream wordt ontvangen door de server (stappen in groen) zijn anders gekleurd, en dit werd gemaakt om aan te tonen dat beide proces onafhankelijk kunnen optreden.

Stappen clientregistratie (rode stappen):

1. De client verzendt een IGMP-rapport voor groep 239.1.1.7

2. De router verstuurt een PIM Join-bericht naar de statische RP geconfigureerd (10.1.1.1) voor groep 239.1.1.7.

3. ASA stuurt aan RP een PIM Join-bericht voor groep 239.1.1.7.

ASA toont PIM *,G-vermeldingen in de show route-opdrachtoutput:

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

Maar aangezien de bronserver geen stream heeft gestart, worden in de "show mfib"-uitvoer van de ASA geen ontvangen pakketten weergegeven:

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

Alvorens de server begint om het even welk verkeer naar de multicast groep te verzenden, toont RP slechts een "*.G"ingang zonder inkomende interface op de lijst, zoals bijvoorbeeld:

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

Zodra de server begint naar de multicast groep te streamen, maakt de RP een "S,G"-ingang en zet de interface naar de afzender op de inkomende interfacelijst en begint het verkeer stroomafwaarts naar de ASA te verzenden:

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

Gebruik deze opdrachten voor verificaties:

- toon route opdracht toont een "S,G" ingang

- toon mfib bevel toont voorwaartse pakkettellers

- toon conn bevel toont verbinding met betrekking tot multicast groep 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 - 

Opmerking: Zodra de client de multicast client-toepassing sluit, verstuurt de host een IGMP Query-bericht.

In het geval dat dit de enige host is die bekend is bij de router als een client de stream wil ontvangen, stuurt de router een IGMP Prune bericht naar de RP.

IGMP Stub-mode bediening

• In de IGMP Stub-modus werkt de ASA als een multicast-client en genereert of doorstuurt IGMP-rapporten (ook bekend als IGMP "joins") naar aangrenzende routers, om de ontvangst van multicast verkeer te activeren
• Routers sturen periodiek vragen naar de hosts om te zien of een knooppunt in het netwerk het multicast verkeer wil blijven ontvangen.
• IGMP Stub-mode wordt niet aanbevolen omdat PIM sparse-mode veel voordelen biedt via Stub-mode (met efficiëntere multicast verkeersstromen, mogelijkheid om deel te nemen aan PIM, etc).

Configuratie IGMP stub-modus

1. Schakel multicast routing in (globale configuratiemodus).

ASA(config)# multicast-routing

 2. Op de interface waarop de firewall de IGMP-rapporten ontvangt, configureer dan de IGMP voorwaartse interfaceopdracht. Door:sturen de pakketten uit de interface naar de bron van de stroom. In dit voorbeeld, worden de multicast ontvangers direct verbonden met de binneninterface, en de multicast bron is voorbij de buiteninterface.

!
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. Sta de multicast-pakketten toe via de juiste interface (alleen noodzakelijk als het beveiligingsbeleid van de ASA het inkomende multicast-verkeer ontkent).

ASA(config)# access-list 105 extended permit ip any host 224.1.2.3
ASA(config)# access-group 105 in interface outside

Vaak is er verwarring rond de verschillende igmp interface sub-mode opdrachten, en dit diagram beschrijft wanneer om elk te gebruiken:

Bidir PIM

In bidirectionele PIM, is er geen gedeelde boom (SPT). Dat betekent drie dingen:

1. De eerste hop router (verbonden met de afzender) verzendt geen PIM Register-pakketten naar de RP.

2. De referentieprijs stuurt geen PIM CONNECT-berichten om aan te sluiten bij de bronstructuur.

3. Routers in het pad naar de ontvanger sturen PIM-berichten naar de RP om zich bij de RPT aan te sluiten.

Dit betekent dat de ASA geen (S,G) genereert omdat apparaten niet bij de SPT aansluiten. Al multicast verkeer gaat door de RP. De ASA stuurt al het multicast verkeer door zolang er een (*,G) is. Als er geen (*,G) is, betekent dit dat de ASA nooit een PIM-samenvoegpakket heeft ontvangen. Als dat het geval is, moet ASA geen multicast-pakketten doorsturen.

Configuratie Bidir PIM

1. Schakel multicast routing in (globale configuratiemodus).

ASA(config)# multicast-routing

 2. Bepaal het PIM Rendezvous-point adres.

ASA(config)# pim rp-address 172.18.123.3 bidir

 3. Sta de multicast-pakketten toe via de juiste interface (alleen nodig als het beveiligingsbeleid van de ASA de inkomende multicast-pakketten blokkeert).

access-list 105 extended permit ip any host 224.1.2.3
access-group 105 in interface outside

Methodologie voor probleemoplossing

Informatie die moet worden verzameld bij het oplossen van multicastproblemen

Om een multicast-verzendprobleem op de ASA volledig te begrijpen en te diagnosticeren, is een deel van of al deze informatie nodig:

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

Handige opdrachtoutput tonen

De opdrachtoutput van de show-route toont de verschillende groepen en informatie over het doorsturen, en is zeer vergelijkbaar met de opdracht van de IOS show-route. De opdracht show mfib toont de status van de doorsturen van de verschillende multicastgroepen. Het is vooral belangrijk om de Forwarding pakketteller te observeren, evenals Andere (die dalingen aangeeft):

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# 

De opdracht clear mfib-tellers kan worden gebruikt om de tellers te wissen, wat zeer nuttig is tijdens de test:

ciscoasa# clear mfib counters

PacketCapture

Het ingebouwde pakketopnameprogramma is zeer nuttig voor probleemoplossing bij multicastproblemen. In dit voorbeeld worden alle ingangspakketten op de DMZ-interface die bestemd zijn voor 239.17.17.17.17, opgenomen:

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 
....

De output van de opdracht show capture x detail toont de TTL van de pakketten, wat vrij nuttig is. In deze uitvoer is de TTL van het pakket 1 (en de ASA geeft dit pakket door omdat het de TTL van IP-pakketten niet standaard afneemt) maar een downstream router zou de pakketten neerzetten:

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)

Packet-opnamen zijn ook nuttig om PIM- en IGMP-verkeer op te nemen. Deze opname laat zien dat de binnenkant van de interface een IGMP-pakket (IP-protocol 2) ontvangen heeft dat afkomstig is van 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#

Merk op dat de TTL van de pakketten te zien is met de opdracht 'show capture x detail'.

Hier kunnen we ASP drop-opnamen zien die de gedropte multicast-pakketten en de reden voor de dalingen tonen (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

Voorbeeld ASA PIM Sparse-Mode Multicast-implementatie

Deze diagrammen illustreren hoe de ASA interageert met buurapparaten in de dun-mode PIM.

De netwerktopologie begrijpen

Bepaal precies de locatie van de afzenders en ontvangers van de specifieke multicast stream. Bepaal ook het IP-adres van de multicastgroep en de locatie van het rendez-vous point.

 In dit geval kunnen de gegevens worden ontvangen op de buiteninterface van de ASA en doorgestuurd naar de multicastontvanger op de binneninterface. Omdat de ontvanger zich in hetzelfde IP-subnet bevindt als de interne interface van de ASA, verwacht u een IGMP-rapport te zien dat wordt ontvangen op de interne interface wanneer de client verzoekt om de stream te ontvangen. Het IP-adres van de afzender is 192.168.1.50.

Controleer dat de ASA het IGMP-rapport van de ontvanger ontvangt

In dit voorbeeld wordt het IGMP-rapport gegenereerd door de ontvanger en verwerkt door de ASA.

Packet-opnamen en de uitvoer van debug-igmp kunnen worden gebruikt om te verifiëren dat de ASA het IGMP-bericht heeft ontvangen en verwerkt.

Controleer of de ASA een PIM-samenvoegingsbericht naar het rendez-vous-punt stuurt

ASA interpreteert het IGMP-rapport en genereert een PIM-samenvoegbericht en stuurt het vervolgens de interface naar de RP.

Deze uitvoer is afkomstig van debug-timergroep 24.1.2.3 en toont aan dat de ASA met succes het PIM-samenvoegingsbericht verstuurt. De afzender van de multicaststroom is 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

Controleer dat de ASA de multicast-stroom ontvangt en doorstuurt

ASA begint multicast verkeer op de buiteninterface te ontvangen (geïllustreerd door de groene pijlen), en het door:sturen aan de ontvangers aan de binnenkant.

De show route en toon mfib opdrachten, evenals pakketopnamen, kunnen worden gebruikt om te verifiëren ASA ontvangt en verstuurt de multicast pakketten.

Een verbinding wordt gebouwd in de verbindingslijst om de multicast stroom te vertegenwoordigen:

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

Gegevensanalyse

Vaak voorkomende problemen

Deze sectie biedt een reeks werkelijke ASA multicast gerelateerde problemen

ASA kan wegens HSRP geen PIM-berichten naar upstream-routers verzenden

Wanneer dit probleem zich voordoet, kan de ASA geen PIM-berichten via een interface verzenden. Dit diagram laat zien dat de ASA geen PIM-berichten naar de afzender kan sturen, maar hetzelfde probleem kan worden waargenomen wanneer de ASA een PIM-bericht naar de RP moet sturen.

De output van debug pim bevel toont aan dat ASA niet het PIM bericht naar de stroomopwaartse volgende-hoprouter kan verzenden:

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

 Deze kwestie is niet specifiek voor de ASA en heeft ook gevolgen voor routers. Het probleem wordt geactiveerd door de combinatie van de configuratie van de routeringstabel en de HSRP-configuratie die door de PIM-buren wordt gebruikt.

De routeringstabel verwijst naar de HSRP IP 10.0.0.1 als het volgende-hopapparaat:

ciscoasa# show run route
route outside 0.0.0.0 0.0.0.0 10.0.0.1 1

 De PIM-buurrelatie wordt echter gevormd tussen de fysieke IP-interfaceadressen van de routers en niet tussen de HSRP 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)

Raadpleeg "Waarom werkt PIM Sparse Mode niet met een statische route naar een HSRP-adres?" voor meer informatie.

Een uittreksel uit het document:

Waarom verstuurt de router het Join/Prune-bericht niet? RFC 2362 stelt dat "een router een periodiek Join/Prune-bericht verstuurt naar elke afzonderlijke RPF-buur die aan elke (S,G), (*,G) en (*,*,RP) ingang is gekoppeld. Berichten worden alleen verstuurd als de RPF-buur een PIM-buur is."

Om het probleem te verhelpen, voeg een statische routeingang op ASA voor het verkeer in kwestie toe. Zorg ervoor dat het aan één van de twee IP-adressen van de routerinterface wijst (10.0.0.2 of 10.0.0.3). In dit geval kan de ASA met deze opdracht PIM-berichten verzenden die naar de multicast-afzender op 172.16.1.2 zijn gericht:

ciscoasa(config)# mroute 172.16.1.2 255.255.255.255 10.0.0.3

 Zodra dit wordt gedaan, treedt de multicast routeringstabel de unicast routeringstabel van de ASA met voeten, en de ASA verstuurt de PIM-berichten rechtstreeks naar de 10.0.0.3-buur.

ASA negeert IGMP-rapporten omdat dit niet de aangewezen router op het LAN-segment is

Voor dit probleem ontvangt de ASA een IGMP-rapport van een direct aangesloten multicast ontvanger, maar deze negeert dit. Geen debug-uitvoer wordt gegenereerd en het pakket wordt simpelweg gedropt, en de stream-ontvangst mislukt.

Voor dit probleem negeert de ASA het pakket omdat het niet de door PIM geselecteerde aangewezen router is op het LAN-segment waar de clients verblijven.

Deze ASA CLI-uitvoer toont aan dat een ander apparaat de aangewezen router (aangeduid met "DR") is op het interne interfacenetwerk:

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)

Standaard is PIM ingeschakeld op alle ASA interfaces wanneer het multicast-routing commando aan de configuratie wordt toegevoegd. Als er andere PIM-buren (andere routers of ASA's) zijn op de binnenkant van de ASA (waar de clients zich bevinden) en een van die buren is gekozen omdat de DR voor dat segment, dan zetten andere, niet-DR-routers IGMP-rapporten. De oplossing is om PIM op de interface uit te schakelen (met de opdracht geen pim op de interface in kwestie), of om de ASA de DR voor het segment te maken via de opdracht van de pim dr-prioriteitsinterface.

IGMP-rapporten worden ontkend door de firewall wanneer de IGMP-interfacelimiet wordt overschreden

Standaard staat ASA 500 actieve verbindingen (rapporten) op een interface toe. Dit is de maximumwaarde die configureerbaar is. Als een groot aantal multicaststromen door clients van een interface wordt gevraagd, kan het maximum van 500 actieve joins worden bereikt en kan de ASA extra inkomende IGMP-rapporten van de multicast-ontvangers negeren.

Om te bevestigen als dit de oorzaak van een multicast mislukking is, geef het bevel uit "tonen igmp interface interfacenaam"en zoek de "IGMP grens"informatie voor de interface.

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 kan multicast verkeer in het 232.x.x/8-bereik niet doorsturen

Dit adresbereik is bedoeld voor gebruik met Source Specific Multicast (SSM), die momenteel niet door de ASA wordt ondersteund.

De output van het debug igmp bevel toont deze fout:

IGMP: Exclude report on inside ignored for SSM group 232.179.89.253

De ASA laat vallen multicast pakketten toe te schrijven aan omgekeerde weg die controle door:sturen

In dit geval ontvangt de ASA multicast-verkeer op een interface, maar wordt het niet doorgestuurd naar de ontvanger. Pakketten worden door de ASA laten vallen omdat ze niet voldoen aan de RPF-beveiligingscontrole (Reverse Path Forwarding). RPF wordt toegelaten op alle interfaces voor multicast verkeer en kan niet worden onbruikbaar gemaakt (voor unicastpakketten is de controle niet door gebrek, en wordt toegelaten met ip verifieert omgekeerd-weg interfacebevel).

Vanwege de RPF-controle wanneer multicast verkeer wordt ontvangen op een interface, controleert de ASA om te zien dat er een route is terug naar de bron van het multicast verkeer (het controleert de unicast en multicast routeringstabel) op die interface. Als het geen route aan de afzender heeft, laat het het pakket vallen. Deze druppels kunnen worden gezien als een teller in de output van 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

ciscoasa(config)# mroute 172.16.1.2 255.255.255.255 outside

ASA genereert geen PIM-verbinding tijdens de PIM-overschakeling naar de bronstructuur

Aanvankelijk, stromen PIM sparse-mode multicast pakketten van de multicast afzender aan RP, dan van RP aan de ontvanger via een gedeelde multicast boom. Zodra de geaggregeerde bitsnelheid echter een bepaalde drempel bereikt, probeert de router die het dichtst bij de multicast-ontvanger staat verkeer via de bronspecifieke boom te ontvangen. Deze router genereert een nieuwe PIM-koppeling voor de groep en stuurt deze naar de afzender van de multicast-stroom (en niet naar de RP, zoals voorheen).

De afzender van het multicast verkeer kan zich op een andere ASA-interface bevinden dan de RP. Wanneer de ASA de PIM-verbinding met de switch naar de bronspecifieke structuur ontvangt, moet de ASA een route naar het IP-adres van de afzender hebben. Als deze route niet wordt gevonden, wordt het pakket PIM Josef gelaten vallen en wordt dit bericht gezien in de output van debug PIM

 NO RPF Neighbor to send J/P

De oplossing voor dit probleem is om een statische routeingang voor de afzender van de stroom toe te voegen, die op de ASA interface wijst waarvan de afzender verblijft.

ASA laat multicast-pakketten vallen vanwege overschrijding van time to live (TTL)

In dit geval mislukt multicastverkeer omdat het TTL van de pakketten te laag is. Hierdoor laat de ASA of een ander apparaat in het netwerk ze vallen.

Vaak multicast-pakketten hebben de IP TTL-waarde zeer laag ingesteld door de toepassing die ze heeft verzonden. Soms wordt dit standaard gedaan om ervoor te zorgen dat het multicast verkeer niet te ver door het netwerk gaat. Standaard is de video bijvoorbeeld LAN Clienttoepassing (een populaire multicast zender en testtool) stelt de TTL in het IP-pakket standaard in op 1.

ASA ervaart hoog CPU-gebruik en verlaagde pakketten vanwege specifieke multicast-topologie

ASA kan hoge CPU ervaren en de multicast stroom kan pakketdalingen ervaren als al deze waar zijn over de multicast topologie:

1. De ASA fungeert als de RP.
2. ASA is de eerste hopontvanger van de multicast stroom. Dit betekent dat de multicast afzender in hetzelfde IP-subnet als de ASA-interface staat.
3. ASA is de laatste hoprouter van de multicast stroom. Dit betekent dat een multicast-ontvanger zich in hetzelfde IP-subnet bevindt als een ASA-interface.

Indien alle genoemde symptomen zich voordoen, dan wegens een ontwerpbeperking wordt ASA gedwongen om switch het multicast verkeer te verwerken. Dit resulteert in hoge gegevenssnelheid multicast streams om pakketdruppels te ervaren. De teller van de show asp dat de stappen wanneer deze pakketten worden gelaten vallen punt-rate-limit is.

Voltooi de volgende stappen om te bepalen of een ASA dit probleem heeft:

Stap 1: Controleer of de ASA de RP is:

show run pim
show pim tunnel

Stap 2: Controleer of de ASA de laatste hoprouter is:

show igmp group <mcast_group_IP>

Stap 3: Controleer of de ASA de eerste hoprouter is:

show mroute <mcast_group_IP>

Deze stappen kunnen worden genomen om dit probleem te verlichten:

- De topologie wijzigen zodat de ASA niet de RP is. U kunt ook de zender of ontvanger maken die niet rechtstreeks met de ASA is verbonden

- In plaats van PIM, gebruik IGMP stub-mode voor multicast-doorsturen.

ASA laat de eerste pakketten vallen wanneer een multicaststroom voor het eerst wordt gestart

Wanneer de eerste pakketten van een multicast stroom bij ASA aankomen, moet ASA die bepaalde multicast verbinding en de bijbehorende routeingang bouwen om de pakketten door:sturen. Terwijl de ingang tijdens verwezenlijking is, kunnen sommige multicast pakketten worden gelaten vallen tot de route en de verbindingen zijn gevestigd (gewoonlijk vergt dit minder dan een seconde). Zodra de multicast stream setup is voltooid, zijn de pakketten niet langer aan snelheidsbeperking onderhevig.

De pakketten die om deze reden zijn gedropt hebben de ASP reden van "(punt-rate-limit) de grens van het punttarief overschreden". Dit is de output van 'show capture asp' (waar asp een ASP drop-opname is die op de ASA is geconfigureerd om gedropte pakketten op te nemen) en u kunt de multicast-pakketten zien die om deze reden zijn gedropt:

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

Een afbrekende multicastontvanger onderbreekt de ontvangst van multicast groepen op andere interfaces

Alleen ASA's die werken in IGMP Stub-mode ervaren dit probleem. ASA's die deelnemen aan PIM multicast routing worden niet beïnvloed.

Het probleem wordt geïdentificeerd door de Cisco bug-id CSCeg48235 IGMP-verlof op één interface onderbreekt multicast verkeer op andere interfaces.

Dit is de release note van de bug, wat het probleem verklaart:

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.

De ASA Drops Multicast-pakketten vanwege het beveiligingsbeleid van de uitgaande toegangslijst

Met deze specifieke kwestie laat de ASA multicast-pakketten vallen (per geconfigureerd beveiligingsbeleid). Het is echter moeilijk voor de netwerkbeheerder om de reden voor de pakketdalingen te achterhalen. In dit geval laat de ASA pakketten vallen vanwege de uitgaande toegangslijst die voor een interface is geconfigureerd. De tijdelijke oplossing is om de multicast stroom in de uitgaande toegang-lijst toe te laten.

Wanneer dit voorkomt, worden multicast pakketten gelaten vallen met de de dalingsteller van het ASPIS "FP geen gietvormoutput intrf (geen-mcast-intrf)".

De ASA laat continu een aantal pakketten (maar niet alle) in een multicast-stroom vallen vanwege snelheidsbeperking op controlepunten

Het verkeer is zeer waarschijnlijk beperkt door het controlepunt als gevolg van punt-rate-limit. Bekijk de output en opnamen van de asp drop om te bevestigen:

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

De mfib ingang toont aan dat al verkeer procesgeschakeld is:

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

De multicast routertabel toont een (*,G) maar geen (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

Het probleem hier is dat TTL van de pakketten multicast gegevenspakketten die bij ASA aankomen 1 is. ASA stuurt deze pakketten door naar het stroomafwaartse apparaat (omdat het TTL niet afneemt), maar de router stroomafwaarts laat vallen de pakketten. Dientengevolge, verzendt de stroomafwaartse router geen PIM (S, G) toetreedt (een bron-specifieke toetreedt) naar ASA naar de afzender. ASA bouwt geen (S,G) ingang tot het deze PIM ontvangt toetreedt. Omdat de (S,G) niet is gebouwd, is al het multicast verkeer procesgeschakeld dat resulteert in snelheidslimiet.

De oplossing voor dit probleem is ervoor te zorgen dat de TTL van de pakketten niet 1 is, dat het stroomafwaartse apparaat toestaat om de bronspecifieke verbinding naar de afzender te verzenden; dit veroorzaakt ASA om een bron-specifieke route in de lijst te installeren, en dan zijn alle pakketten snel-geschakeld (in plaats van verwerkte geschakeld) en het verkeer moet door ASA zonder probleem stromen.

De multicast stream wordt gestopt vanwege een PIM ASSERT-bericht

Als twee netwerkapparaten dezelfde multicast-pakketten doorsturen naar dezelfde subnetprocessor, dan is het ideaal dat een van deze apparaten moet stoppen met het doorsturen van de pakketten (omdat het een verspilling is om de stream te dupliceren). Als routers die PIM uitvoeren detecteren dat ze dezelfde pakketten ontvangen die ze ook genereren op dezelfde interface, genereren ze ASSERT-berichten op die LAN om te selecteren welk netwerkapparaat stopt met het doorsturen van de stream.

Meer informatie over dit bericht is te vinden in een deel van RFC 4601 dat betrekking heeft op het ASSERT-proces.

De debugs tonen aan dat de ASA een IGMP-rapport ontvangt voor groep 239.1.1.227, maar het negeert het rapport vanwege het assert bericht dat het ontvangt van een naburige router:

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)

 Dit probleem werd waargenomen in een productienetwerk waar twee plaatsen per ongeluk werden overbrugd bij Layer-2, zodat LAN waar de multicast ontvangers was op twee apparaten had die multicast verkeer naar hen doorsturen. Als gevolg van een ander netwerkprobleem konden de ASA en een ander apparaat elkaar niet detecteren via PIM hellos, en daarom namen beide de toegewezen routerrol voor de LAN over. Dit zorgde ervoor dat het multicast verkeer een tijdje werkte en vervolgens faalde wanneer de ASSERT-berichten door de apparaten werden verzonden. Om het probleem op te lossen, werd de onjuiste verbinding die de apparaten bij Layer 2 overbrugde uitgeschakeld, en toen werd het probleem opgelost.

ASA verzendt PIM Join maar het wordt niet verwerkt door Neighbour vanwege pakketgrootte groter dan MTU

Dit werd waargenomen in 629575899. ASA werd geconfigureerd voor Jumboframes en de 4900 niet. Wanneer de client meer dan 73 multicaststromen vroeg, zouden bepaalde multicaststromen niet werken. 73 SGs zou een PIM Join bericht van grootte 1494 creëren, dat nog binnen MTU was. 74SGs zou tot een PIM Join bericht groter dan 1500 leiden, die de 4900M ertoe bracht om het pakket inbound te laten vallen.

De oplossing voor dit probleem was:

1. Zorg ervoor dat Jumboframes wereldwijd zijn ingeschakeld op de 4900M

2. Configureer zowel de fysieke interface als SVI met een MTU van 9216