Difference between revisions of "Cisco PIM"

From HackerNet
Jump to: navigation, search
Line 1: Line 1:
−
IP Multicast är att skicka ett meddelande från en source till multipla destinationer i en ström över ett IP-nät. En multicast-IP är en destinationsadress och alla som ska ta del av trafiken måste gå med i samma multicastgrupp, dvs lyssna på den IPn och meddela det till intermediate systems. Utifrån IP-adress räknas multicast mac-adress fram så att enheterna vet vad de ska ta emot frames för utöver BIA. End systems och intermediate systems pratar IGMP med varandra för att ta reda på vem som är med i vilken multicastgrupp. 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.  
+
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_IGMP|IGMP]].
+
Se även [[Cisco_Multicast|Cisco Multicast]].
  
 
===Neighbor===
 
===Neighbor===
Line 23: Line 23:
  
 
==Dense Mode==
 
==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.
+
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.
  
−
Varje kombination av source och multicastgrupp är en SPT. <br/>
 
−
SPT = (S,G), t.ex. (10.0.0.10, 226.0.0.10)
 
 
  ip pim dense-mode
 
  ip pim dense-mode
 
  show ip mroute
 
  show ip mroute
Line 32: Line 30:
 
==Sparse Mode==
 
==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.  
 
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
 
  ip pim sparse-mode
 +
 +
==LAN==
 +
Detta gäller både PIM-DM och PIM-SM.
 +
 +
Prune Override <br/>
 +
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 <br/>
 +
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 <br/>
 +
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==
 
==Sparse Dense Mode==

Revision as of 20:23, 12 June 2016

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

Retrieved from "https://hackernet.se/index.php?title=Cisco_PIM&oldid=1861"