Begrijp het PIM-testmechanisme

Inleiding

In dit document wordt het Protocol Independent Multicast (PIM)-instrumentarium beschreven, wordt de nadruk gelegd op de PIM-winningscriteria en wordt er dieper in bepaalde hoekgevallen ingegaan.

Voorwaarden

Vereisten

Cisco raadt u aan kennis te hebben van PIM-activeringsmechanisme.

Gebruikte componenten 

De informatie in dit document is gebaseerd op Cisco CSR1000V versie 16.4.1

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk levend is, zorg er dan voor dat u de mogelijke impact van om het even welke opdracht begrijpt.

Wat is het PIM Assert Mechanisme?

Wanneer er meerdere PIM-enabled routers op een gedeeld segment zijn, is het mogelijk dat deze routers in tweevoudig multicast verkeer reageren. Dit zou het geval kunnen zijn omdat twee of meer routers op hetzelfde gedeelde segment een geldige (S,G) of (*,G) ingang zouden kunnen hebben die de uitgaande interface naar het gedeelde segment voor dezelfde bron IP/doelgroep bevolkt.

Het PIM assert mechanisme wordt gebruikt om dubbel multicast verkeer op een gedeeld segment te detecteren en te elimineren. Het is van belang op te merken dat dit mechanisme dubbel werk niet voorkomt, maar dat het dubbel verkeer in multicast als aanjager gebruikt om dit mechanisme, dat voor deze stroom één enkele expediteur kiest, in werking te stellen.

Wanneer u dubbel multicast verkeer op een gedeeld segment hebt, kunt u ervan uitgaan dat er meerdere routers zijn die hetzelfde segment (S,G) of (*,G) op een gedeeld segment verzenden. Als u één router selecteert om deze stroom effectief door te sturen, elimineert dit duplicatie.

PIM gebruikt hefboomwerking op PIM antwoordberichten die worden geactiveerd wanneer u een multicast pakket op de Uitgaande Interface Lijst (OIL) ontvangt. Deze berichten bevatten parameters die vervolgens worden gebruikt om te berekenen wie er als winnaar uit de bus zal komen. Downstream routers op het LAN ontvangen ook PIM-berichten. Deze berichten worden dan gebruikt door stroomafwaartse apparaten om de juiste Join/Prune berichten naar de upstream router te sturen die de assert verkiezing won.

Scenario 1. LHR-motivering

Afbeelding 1.

In het netwerkdiagram is R3 de Laatste Hop Router (LHR), sluit R3 aan op zowel R2 als R1 via een gedeeld segment.

Wanneer u een IGMP-rapport (Internet Group Management Protocol) van de ontvanger ontvangt, controleert R3 wie de RPF-buur naar de RP is. In de topologie is R1 de RPF-buur naar de RP, waardoor R3 een (*,G) verbinding naar R1 stuurt. Zodra R1 de stroom aftrekt (ervan uitgaat dat de groep actief is) stuurt R3 een (S,G) aansluiting naar de bron en trekt de bronboom naar beneden. R2 is de RPF-buur naar de bronboom, wat betekent dat R3 de (S,G) verbinding naar R2 zal sturen. R3 heeft dezelfde RPF-interface naar zowel RP als de bron. Hier zie je de R3-routetabel voor groep 239.1.1.1.

R3#show ip mroute
IP Multicast Routing Table
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.1), 00:00:55/stopped, RP 192.168.0.100, flags: SJC
  Incoming interface: GigabitEthernet1, RPF nbr 192.168.3.1
  Outgoing interface list:
    GigabitEthernet4, Forward/Sparse, 00:00:55/00:02:04

(10.0.0.2, 239.1.1.1), 00:00:52/00:02:07, flags: JT
  Incoming interface: GigabitEthernet1, RPF nbr 192.168.3.2, Mroute
  Outgoing interface list:
    GigabitEthernet4, Forward/Sparse, 00:00:52/00:02:07

(*, 224.0.1.40), 00:01:22/00:02:09, RP 192.168.0.100, flags: SJPCL
  Incoming interface: GigabitEthernet1, RPF nbr 192.168.3.1

Zoals u kunt zien op R3 is de (*,G) RPF-buur 192.168.3.1 en de RPF-buur naar de (S,G) 192.168.3.2. Nu moet dit ertoe leiden dat R1 en R2 een geldige OLIE naar R3 hebben. Laten we deze cijfers bekijken:

R1#show ip mroute
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.1), 00:15:02/00:02:33, RP 192.168.0.100, flags: S
  Incoming interface: GigabitEthernet2, RPF nbr 192.168.5.2
  Outgoing interface list:
    GigabitEthernet1, Forward/Sparse, 00:15:02/00:02:33

(10.0.0.2, 239.1.1.1), 00:13:24/00:02:33, flags: PR
  Incoming interface: GigabitEthernet2, RPF nbr 192.168.5.2
  Outgoing interface list: Null

(*, 224.0.1.40), 00:29:17/00:02:51, RP 192.168.0.100, flags: SJCL
  Incoming interface: GigabitEthernet2, RPF nbr 192.168.5.2
  Outgoing interface list:
    GigabitEthernet1, Forward/Sparse, 00:16:06/00:02:51
  Outgoing interface list: Null

R2#show ip mroute
IP Multicast Routing Table
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.1), 00:08:00/stopped, RP 192.168.0.100, flags: SP
  Incoming interface: GigabitEthernet2, RPF nbr 192.168.4.1
  Outgoing interface list: Null

(10.0.0.2, 239.1.1.1), 00:00:03/00:02:56, flags: T
  Incoming interface: GigabitEthernet2, RPF nbr 192.168.4.1
  Outgoing interface list:
    GigabitEthernet1, Forward/Sparse, 00:00:03/00:03:26

(*, 224.0.1.40), 01:37:30/00:02:22, RP 192.168.0.100, flags: SJPL
  Incoming interface: GigabitEthernet2, RPF nbr 192.168.4.1

Zoals vermeld kan het argument worden geactiveerd wanneer er twee upstream routers zijn met een geldige OIL die op een gedeeld segment is bevolkt. Aangezien zowel R1 als R2 een geldige OIL hebben, controleer of er een actief mechanisme in pakketvastlegging is.

Deze pakketvastlegging is opgenomen op R3-interface Gi1 naar SW1.

Bij deze pakketvastlegging ziet u geen beurspakketten, zelfs al zijn er alle vereisten om duplicatie op het gedeelde segment tussen R1, R2 en R3 te maken. Waarom ziet u geen PIM-pakketten wanneer de (S,G) stream werd geactiveerd?

Het lijkt erop dat RFC 7761 het antwoord op deze vragen zou kunnen bevatten.

Aftrekking van RFC 7761 Sectie 4.2.2.

4.2.2.  Setting and Clearing the (S,G) SPTbit

   Basically, Update_SPTbit(S,G,iif) will set the SPTbit if we have the
   appropriate (S,G) join state, and if the packet arrived on the
   correct upstream interface for S, and if one or more of the following
   conditions apply:

   1.  The source is directly connected, in which case the switch to the
       SPT is a no-op.

   2.  The RPF interface to S is different from the RPF interface to the
       RP.  The packet arrived on RPF_interface(S), and so the SPT must
       have been completed.

   3.  No one wants the packet on the RP tree.

   4.  RPF'(S,G) == RPF'(*,G).  In this case, the router will never be
       able to tell if the SPT has been completed, so it should just
       switch immediately.  The RPF'(S,G) != NULL check ensures that the
       SPTbit is set only if the RPF neighbor towards S is valid.
 
 In the case where the RPF interface is the same for the RP and for S,
 but RPF'(S,G) and RPF'(*,G) differ, we wait for an Assert(S,G), which
 indicates that the upstream router with (S,G) state believes the SPT
 has been completed. 

Het (S,G) SPTbit wordt gebruikt om te onderscheiden of het een (*,G) of een (S,G) staat betreft. Wanneer u van de RP-boom naar de bronboom switch, is er een overgangsperiode wanneer gegevens aankomen als gevolg van de upstream (*,G)-status terwijl de upstream (S,G)-toestand is vastgesteld, moet de router op dat moment alleen doorgaan met (*,G)-status. Dit voorkomt tijdelijke zwarte gaten die zouden worden veroorzaakt door het verzenden van een Prune(S,G,rpt) voordat de stroomopwaarts (S,G) staat klaar is.

Hoewel het scenario lijkt te kunnen correleren met bovengenoemd laatste punt. In het geval dat de RPF-interface dezelfde is voor de RP en voor S,
Maar hoewel RPF's, G en RPF's (*,G) verschillen, wachten we op een Assert(S,G), die aangeeft dat de upstream router met (S,G) staat van mening is dat de SPT is voltooid. 

Om te willen geactiveerd worden, moet de router een dubbel pakket op zijn reeds bevolkte OIL voor de zelfde bron IP/doelgroep op het segment ontvangen. R3 is ook een LHR, wat betekent dat het is bestemd om te switches van (*,G) naar SPT (S,G) wanneer een pakje wordt ontvangen van (*,G).

In de pakketvastlegging zien we dat er geen aanmaningen worden geactiveerd. Hoewel we een prune zien verstuurd onmiddellijk na de eerste echo van het ICMP. 

Zoals u kunt zien, zodra het eerste ICMP-aanvraagpakket voor Internet Control Message Protocol (ICMP) op R3-interface G1 is ontvangen, wordt er een (*,G) SR-bit prune naar upstream-buurman 192.168.3.1 verzonden. Deze pompt (*,G) voor de specifieke gedefinieerde bron.

U kunt deze vlaggen ook zien instellen: (SR):

The S flag: indicates that the multicast group is a sparse mode group.
The R flag: The R flag is the RP-bit flag and indicates that the information in the (S, G) entry is applicable to the shared tree.  

In het tweede PIM pakket nr. 14, kunt u zien dat R3 probeert om zich aan te sluiten bij de (S,G) boom.

Zodra het eerste gegevensvliegtuig is ontvangen, wordt pakje R3 de (*,G) omgedraaid en bouwt de (S,G). Dit is de reden waarom u geen PIM-pakketten ziet bevestigen. Dit bepaalde scenario is van kracht wanneer u een LHR hebt die dezelfde RPF-interface heeft voor (S,G) en (*,G). Hoewel dit gedrag enigszins kan afwijken van RFC 7761, zou dit geen problemen mogen veroorzaken.

Laten we nu verder gaan met Scenario 2. Het schema van dit scenario is hier te zien:

Scenario 2. Selecteren pad

Afbeelding 2.

In deze topologie is er een andere router aangesloten op R3 die de LHR is. De LHR sluit rechtstreeks aan op de ontvanger. De bron en RP zijn beide hoger dan R2 en R1. De RPF-buis op R3 in de richting van de RP is R1 en de RPF-buur in de richting van de bron is R2.

Laten we de RPF-buur voor zowel de bron als de RP controleren.

Hier zie je de RPF-buur naar de RP: 192.168.0.100 is 192.168.3.1.

R3#show ip rpf 192.168.0.100
RPF information for ? (192.168.0.100)
  RPF interface: GigabitEthernet1
  RPF neighbor: ? (192.168.3.1)
  RPF route/mask: 192.168.0.100/32
  RPF type: unicast (ospf 1)
  Doing distance-preferred lookups across tables
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base

Hier ziet u de RPF-buur naar de bron: 10.0.0.2 is 192.168.3.2.

R3#show ip rpf 10.0.0.2
RPF information for ? (10.0.0.2)
  RPF interface: GigabitEthernet1
  RPF neighbor: ? (192.168.3.2)
  RPF route/mask: 10.0.0.0/24
  RPF type: unicast (ospf 1)
  Doing distance-preferred lookups across tables
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base

Voordat we de bron activeren, kijken we naar de route-tabel op R3, zoals je kunt zien dat er al (*,G) is voor groep 239.1.1.1. Dit komt doordat de ontvanger die verbonden is met LHR al om de gespecificeerde groep heeft gevraagd.

R3#show ip mroute
IP Multicast Routing Table
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.1), 00:00:57/00:02:32, RP 192.168.0.100, flags: S
  Incoming interface: GigabitEthernet1, RPF nbr 192.168.3.1
  Outgoing interface list:
    GigabitEthernet2, Forward/Sparse, 00:00:57/00:02:32

(*, 224.0.1.40), 00:11:24/00:02:41, RP 192.168.0.100, flags: SJCL
  Incoming interface: GigabitEthernet1, RPF nbr 192.168.3.1
  Outgoing interface list:
    GigabitEthernet2, Forward/Sparse, 00:02:02/00:02:41

Activeer de bron en neem de pakketten op de R3 interface Gi1.

Zoals u in deze pakketvastlegging kunt zien, stelt PIM dat de pakketten reeds aanwezig zijn.

Frame Relay 11:

Frame Relay 12:

Als je naar deze pakketten kijkt, moet je kunnen bepalen wie de winnaar is. Laten we nu eens kijken naar de PIM-selectie.

De metrische voorkeur is de Administratieve Afstand (AD). Dit verwijst naar de administratieve afstand van het routingprotocol dat de route in de routingtabel installeert, die wordt gebruikt om het bron-IP-adres op te zoeken en de metriek is de kosten van de route.

Er zijn ook andere eigenschappen die worden gebruikt om te bepalen wie de winnaar van de aanval is. U kunt deze details in RFC 7761 zien.

Aftrekking van RFC 7761 Sectie 4.6.3.

4.6.3.  Assert Metrics

   Assert metrics are defined as:

     struct assert_metric {
       rpt_bit_flag;
       metric_preference;
       route_metric;
       ip_address;
     };
   When comparing assert_metrics, the rpt_bit_flag, metric_preference,
   and route_metric fields are compared in order, where the first lower
   value wins.  If all fields are equal, the primary IP address of the
   router that sourced the Assert message is used as a tie-breaker, with
   the highest IP address winning.

Als deze velden gedefinieerd zijn en pad geselecteerd, kunt u bepalen wie de winnaar in dit scenario zal zijn. Als je de assert pakketten nog eens bekijkt, kan je zien dat metrische voorkeur niet vergeleken wordt omdat de beslissing gemaakt is op de allereerste selectiecriteria die rpt_bit_flag is.

In dit scenario wordt de vergelijking van R1 en R2 vergeleken. Beide routers sturen duidelijke berichten die eerder werden gezien en zodra beide apparaten de duidelijke boodschappen van elkaar zien, kunnen ze parameters tussen elkaar vergelijken om te bepalen wie de winnaar is.

Aangezien R2 een waarschuwingsbericht stuurt met de RP-boom: Als de waarde 0 is, is deze inderdaad lager dan de waarde die R1 met een RP-boom heeft verstuurd: True, met een waarde van 1. RP-boombit is ingesteld op 0 of 1.

RP-boombit bij instelling op 1 betekent dat u momenteel op de gedeelde boom staat; het RPT-bit gewist, geeft aan dat de zender van de bewering (S,G) een staat op een interface heeft laten verzenden.

Zoals ( S,G) beweert dat R2 voorrang heeft boven (*,G) en dat hij de hoofdwinnaar is. Zoals vermeld in het eerdere statement in RFC 7761 heeft de lagere waarde de voorkeur.

Laten we zowel R1 als R2 bekijken om te zien wie de winnaar is.

R2#show ip mroute
IP Multicast Routing Table
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.1), 00:42:52/stopped, RP 192.168.0.100, flags: SP
  Incoming interface: GigabitEthernet2, RPF nbr 192.168.4.1
  Outgoing interface list: Null

(10.0.0.2, 239.1.1.1), 00:42:52/00:01:40, flags: T
  Incoming interface: GigabitEthernet2, RPF nbr 192.168.4.1
  Outgoing interface list:
    GigabitEthernet1, Forward/Sparse, 00:42:52/00:03:07, A

(*, 224.0.1.40), 00:43:23/00:02:25, RP 192.168.0.100, flags: SJPL
  Incoming interface: GigabitEthernet2, RPF nbr 192.168.4.1
  Outgoing interface list: Null

In deze output kan je zien dat de (S,G) op R2 de A vlag op de OLIE heeft ingesteld die aangeeft dat de aanvaller winnaar is. Hier op R1 is geen OLIE op de (S,G) en is de P-vlag ingesteld, wat betekent dat de specifieke (S,G) is afgedrukt in dit geval: het is niet de echte winnaar .

Opmerking: Wanneer de claim op een gedeeld segment aanwezig is, sturen stroomafwaartse buren periodieke berichten naar de desbetreffende RPF-buur, d.w.z. de RPF-buur, zoals gewijzigd door het proefproces, naar Join(*,G) en Join(S,G). Ze worden niet altijd naar de VPF-buur gestuurd, zoals aangegeven door de MRIB.

R1#show ip mroute
IP Multicast Routing Table
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.1), 00:44:32/00:03:09, RP 192.168.0.100, flags: S
  Incoming interface: GigabitEthernet2, RPF nbr 192.168.5.2
  Outgoing interface list:
    GigabitEthernet1, Forward/Sparse, 00:44:32/00:03:09, A

(10.0.0.2, 239.1.1.1), 00:44:19/00:03:09, flags: PR
  Incoming interface: GigabitEthernet2, RPF nbr 192.168.5.2
  Outgoing interface list: Null

(*, 224.0.1.40), 00:44:50/00:02:53, RP 192.168.0.100, flags: SJCL
  Incoming interface: GigabitEthernet2, RPF nbr 192.168.5.2
  Outgoing interface list:
    GigabitEthernet1, Forward/Sparse, 00:43:56/00:02:53

Als het geval is dat zowel R1 als R2 RP-boommebit ingesteld op 1 hebben. U kunt dan de router met de laagste AD overwegen; als gelijk is, kijk dan eens naar de maatstaf. Als RP boom bit op beide routers waar is, wordt de metriek vergeleken in de richting van RP IP-adres. Als RP-boombit 0 is, wordt de metriek vergeleken met de bron van de multicast-stream.

Als al deze waarden het zelfde zijn, is het hoogste IP adres bron assert bericht de winnaar.

Samenvatting 

In scenario één, observeerde u geen pakketten, echter, per RFC zouden ze moeten worden geactiveerd. Zoals vermeld, was dit omdat R3 aan het snoeien was (*,G) voordat het bedieningspaneel voor S,G werd gebouwd.

Terwijl in scenario twee, ziet u het bevestigen van pakketten. Wanneer het eerste pakket op LHR werd ontvangen, stuurde het een (S,G) paar/zuigen naar R3 om de bron/groep te trekken. R3 zal dan een verbind/druk pakket naar R2 voor de zelfde bron/groep verzenden. Hierdoor zouden zowel R1 als R2 een geldige OLIE hebben. Nu is R3 alleen prunes (S,G) met RP-bit ingesteld wanneer de T-vlag is bevolkt op R3s (S,G)-toestand. Om dit te kunnen gebeuren, moet u een ander datapakket uit het gedeelde segment ontvangen. Omdat reeds een controlevliegtuig is gebouwd voor S,G, leidt dit vervolgens tot verdubbeling van het gedeelde segment, wat een waarschuwingsbericht doet ontstaan.