Cisco PIM

From HackerNet
Revision as of 20:23, 12 June 2016 by Helikopter (talk | contribs)
Jump to: navigation, search

För att routrar ska kunna veta vilken server på vilket nät som är med i vilken grupp för multicast används något routingprotokoll (control plane), DVMRP, MOSPF eller PIM. Multicast använder class D adresser, 224.0.0.0 - 239.255.255.255, och är UDP baserat. För loop prevention används RPF, inga paket forwarderas utan att klara denna check. Det som skiljer Protocol Independent Multicast från DVMRP och MOSPF är att det använder unicast RIBen för RPF-checken, de andra protokollen bygger sina egna tabeller och kör RPF mot. Varje kombination av source och multicastgrupp är en SPT, det skrivs (S,G), t.ex. (10.0.0.10, 226.0.0.10).

Se även Cisco Multicast.

Neighbor

PIM formar adjacencies och använder 224.0.0.13 neighbor discovery (Hellos) och updates. PIMv2 Hellos skickas default var 30:e sekund på interface konfigurerade för PIM. Hello innehåller holdtime som brukar vara 3 ggr Hello time. Det äldre PIMv1 använde inte Hellos utan skickade Queries till 224.0.0.2.

Konfiguration

ip multicast-routing

Gå med i grupp manuellt

ip igmp join-group 224.10.0.10

Verify

show ip multicast
show ip mroute
show ip pim interface
show ip pim neighbor
show ip rpf x.x.x.x 

Att begränsa multicast kan göras med TTL scoping eller Administrative scoping

ip multicast boundary

Dense Mode

Dense mode utgår ifrån att alla subnät har någon som vill ta emot multicast-trafik därför kommer paketen att forwarderas ut på alla interface som är konfigurerade för multicast utom det som det kom in på. Alla routrar gör samma sak och alla subnät får strömmen, detta kallas source-based distribution tree eller shortest-path tree. Det finns dock möjlighet för routrar att begära att inte få paket för vissa multicast-grupper om man inte har någon router downstream som är aktiv i gruppen samt ej heller någon enhet på ett directly connected interface som är med i gruppen. Då skickas ett Prune message upstream för att berätta detta. Prune har timeout 3 minuter, sedan återgår interfacet till forwarding. För att förhindra pendlandet mellan Pruned och Forwarding kom PIMv2 med en feature som kallas State refresh. Om downstream fortfarande inte vill vara med i multicastströmmen kan den skicka ett State refresh upstream för att nollställa Prune timer, detta skickas var 60:e sekund. Behöver en router plötsligt lyssna på en multicastgrupp (för att den fått in IGMP Join) kan den "unprune" genom att skicka ett Graft message upstream som gäller så fort det kommer fram vilket sänker konvergeringstiden. Det ackas med Graft Ack.

ip pim dense-mode
show ip mroute

Sparse Mode

Det är inte säkert att alla nät har någon mottagare av multicast, därför finns Sparse mode som inte använder lika mycket nätverksresurser som Dense mode. Den stora skillnaden är deras default-beteende. Sparse mode skickar inte vidare paket downstream om den inte fått ett Join meddelande som begär paket för en viss multicast-grupp. Detta händer när det har kommit in ett IGMP Join message på ett directly connected interface eller en annan router har begärt trafik för gruppen. Vem som ska ha vad hålls koll på av en Rendezvous Point som alla måste känna till. I små nät görs detta manuellt och i större nät kan detta göras automatiskt. För Dense mode kan olika routingprotokoll användas.

ip pim sparse-mode

LAN

Detta gäller både PIM-DM och PIM-SM.

Prune Override
Om det finns flera routrar i samma L2-segment som vill ha multicast kommer det att sluta funka när en av dem ber upstream router att pruna en multicastgrupp. Därför kommer den som på multiaccess-segment tar emot Prune att vänta 3 sekunder innan den slutar forwarda multicastströmmen på sitt interfacet. Eftersom Prune går till 224.0.0.13 så får alla PIM-routrar det och de som vill fortsätta få strömmen kan skicka ett vanligt Join-meddelande igen då kommer inte upstream sluta forwarda, detta kallas Prune Override.

Assert Message
Om det finns flera routrar på ett LAN-segment som är aktiva i en multicastgrupp kommer det att skickas in dubbel trafikström till hostarna, detta är onödigt. Därför används en förhandlingsmekansim som jämför avståndet till källan för SPT där endast vinnaren kommer att forwarda multicastströmmen in på LANet. Först jämförs AD på routingprotokollet som har lärt vägen till källan sedan kollas på IGP-metricen för att skilja. Är detta också lika går man på högst IP-adress på interface.

Designated Router
Med IGMPv1 finns det inget inbyggt sätt för hostarna att avgöra vem som ska stå för Queries. Därför väljer routrarna en som blir DR och den kommer att skicka IGMP Queries. Routern med högst IP vinner.

Sparse Dense Mode

ip pim sparse-dense-mode

Source Specific Multicast

232.0.0.0-232.255.255.255

Bidirectional PIM

MSDP

Multicast Source Discovery Protocol