Inhoud

Inleiding

Functieinformatie

Afkortingen/acroniemen

Componenten van Multicast

Bediening van PIM met reservemodus

Configuratie PIM-reservemodus

Voorbeeld PIM Sparse Mode:

IGMP Stub-mode bediening

Configuratie IGMP stub-modus

Bidir PIM

Configuratie Bidir PIM

Methodologie voor probleemoplossing

Informatie die moet worden verzameld bij het oplossen van multicastproblemen

Handige opdrachtoutput tonen

PacketCapture

Voorbeeld ASA PIM Sparse-Mode Multicast-implementatie

Gegevensanalyse

Vaak voorkomende problemen

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

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

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

ASA kan multicast verkeer in het 232.x.x/8-bereik niet doorsturen

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

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

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

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

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

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

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

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

De multicast stream wordt gestopt vanwege een PIM ASSERT-bericht

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

Inleiding

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

Functieinformatie

Opmerking: voor een bijgewerkte inhoud over de multicast routing op de adaptieve security applicatie (ASA), Firepower Threat Defence (FTD) of Secure Firewall Threat Defence (FTD) raadpleegt u deze artikelen:

Probleemoplossing voor Firepower Threat Defense IGMP en Multicast Basics

Probleemoplossing voor Firepower Threat Defence en ASA Multicast PIM

Afkortingen/acroniemen

Acroniemen

Toelichting

FHR

First-hop router - een hop die rechtstreeks is verbonden met de bron van het multicast verkeer.

LHR

Last-Hop Router - een hop die rechtstreeks is verbonden met de ontvangers van het multicast verkeer.

RP

rendez-point

DR

Aangewezen router

NBP

Shortest-Path boom

RPT

Rendezvous-Point (RP)-structuur, gedeelde structuur

RPF

Doorsturen van pad omkeren

OLIE

Uitgaande interfacelijst

MIRIB

Multicast-routing informatiebasis

MFIB

Multicast Forwarding Information Base

ASM

Any-bron multicast

BSR

Bootstrap router

SSM

Source-Specific Multicast

FP

Snel pad

SP

Langzaam pad

CP

Controlepunt

PS

Pakket per seconde

Multicast op de ASA kan op twee manieren worden geconfigureerd:

- 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. Definieer het PIM-rendez-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).

Dit beeld illustreert de basiswerking van een ASA die voor IGMP Stub-mode is geconfigureerd:

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 de igmp voorwaarts-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. Definieer het PIM-rendez-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:

· Een beschrijving van de netwerktopologie, de plaats van de multicast afzenders, ontvangers, en rendez-point.

· Het specifieke IP-adres van de groep en de gebruikte poorten en protocollen.

· Syslogs die door ASA worden gegenereerd op het moment dat de multicast stream problemen heeft.

· Specifieke output van het showbevel van de ASA interface van de opdrachtregel:

show mroute

show mfib

show pim neighbor

show route

show tech-support

· Packet vangt op om aan te tonen of de multicast gegevens bij de ASA aankomen en of de pakketten door de ASA worden verzonden ( neem nota van de IP Time to Live (TTL) van het pakket. Dit kan worden gezien met de opdracht 'toon opname x detail')

· Packet Captures voor IGMP- en/of PIM-pakketten. Voorbeeld:

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

· Informatie van aangrenzende multicast apparaten (routers) zoals "toon route" en "toon mfib".

· Packet legt opdrachten vast en/of toont deze om te bepalen of de ASA de multicast pakketten laat vallen. De 'show asp' opdracht kan worden gebruikt om te bepalen als de ASA de pakketten laat vallen. Bovendien, pakket vangt van type "asp-daling"kan worden gebruikt om alle pakketten op te nemen ASA daalt, dan onderzocht om te zien of zijn de multicast pakketten aanwezig in de daling vangen.

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 (punt-rate-limit) tonen:

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

Eén optie is om een route toe te voegen voor de afzender van het verkeer. In dit voorbeeld, wordt het routebevel gebruikt om aan de RPF controle voor multicast verkeer te voldoen dat uit 172.16.1.2 wordt voortgekomen dat op de buiteninterface wordt ontvangen:

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