De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
Dit document beschrijft multicast routing op de adaptieve security applicatie (ASA) en algemene problemen.
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 |
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.
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.
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:
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
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.
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:
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.
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
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
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
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
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 - ...
Deze sectie biedt een reeks werkelijke ASA multicast gerelateerde problemen
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.
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.
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
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
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
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.
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 kan hoge CPU ervaren en de multicast stroom kan pakketdalingen ervaren als al deze waar zijn over de multicast topologie:
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.
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
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.
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)".
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.
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.
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
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
1.0 |
03-Jan-2013 |
Eerste vrijgave |