Difference between revisions of "Cisco PIM"

From HackerNet
Jump to: navigation, search
Line 113: Line 113:
  
 
==BSR==
 
==BSR==
PIM Bootstrap Router
+
En annan metod för att automatiskt hitta RP är PIM Bootstrap Router och fungerar på liknande sätt som Auto-RP. BSR fungerar som mapping agent i Auto-RP, de får in information från RPs som de sedan distribuerar vidare. Dock väljer inte BSR någon bästa RP utan information om alla skickas ut och övriga får välja själv vilken som är bäst. BSR floodar detta till all-PIM-routers (224.0.0.13). PIM-SM routrar floodar bootstrap messages på alla non-RPF interfaces vilket leder till att alla multicast-routrar får informationen. Kommer det in bootstrap message på non-RPF interface discardas det vilket förhindrar loopar. Alla c-RP kan berätta för BSR att de är RP och vilka grupper den är med i tack vare att alla vet unicast-adressen till BSR eftersom den har floodats till alla. RPs skickar c-RP Advertisments till BSR. Man kan ha redundanta RPs och redundanta BSRs. Dock kan endast en vara preferred BSR och skicka bootstrap messages, de övriga lyssnar och tar över när preferred BSR tystnar. Den som blir preferred avgörs av högst prio och sedan högst IP.
 +
 
 +
BSR, default prio är 0.
 +
interface lo0
 +
  ip pim sparse-mode
 +
ip pim bsr-candidate Loopback0 0
 +
RP
 +
interface lo0
 +
  ip pim sparse-mode
 +
ip pim rp-candidate Loopback0
 +
 
 +
Debug
 
  debug ip pim bsr
 
  debug ip pim bsr
  

Revision as of 19:57, 30 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). Med IPv6 körs PIM default på alla interface när man slår igång ipv6 multicast-routing.

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

Global enable. På vissa enheter är kommandot ip multicast-routing distributed

ip multicast-routing

Default konfiguration (detta kan skilja mellan IOS-version)

Global

ip pim dm-fallback
ip pim autorp
ip pim bidir-offer-interval 100 msec
ip pim bidir-offer-limit 3
ip pim v1-rp-reachability
ip pim log-neighbor-changes

Per interface

ip pim join-prune-interval 60
ip pim dr-priority 1
ip pim query-interval 30

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

Limiting
Global multicast mroute limit

ip multicast limit cost <ACL> <cost>

Maximum number of multicast routes

ip multicast route-limit 100

Multipath

ip multicast multipath
ip multicast multipath s-g-hash 

Annars kommer RPF-check att faila.

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

Multicast on 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 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. Med IPv6 finns endast Sparse mode. Default är att inte skicka vidare paket downstream om man 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 downstream har begärt trafik för gruppen. Multicast forwardas sålänge det kommer Join-meddelanden. 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.

När en Source host skickar multicast-trafik första gången kommer routern som tar emot det att enkapsulera paketet i ett PIM Register och skicka det med unicast till RP. Känner inte RP till någon downstream som begärt denna ström kommer den att svara med ett Register-Stop meddelande och den första routern ska inte forwarda denna multicast-ström. Register-Suppression timer startar då och router väntar 1 minut minus 5 sekunder sedan frågar den RP igen men denna gång utan det enkapsulerade mc-paketet utan Null-Register biten är satt istället. Däremot om RP känner till någon som vill ha multicast-strömmen kommer den att dekapsulera paketet och forwarda det. På så sätt fungerar multicast tills registration process är klar. När en PIM-SM router längs vägen får in ett PIM Join sätts interfacet i forwarding för den multicastgruppen. För att multicast ska fortsätta forwardas måste routrar forsätta skicka PIM Joins annars blir gruppen pruned. En router fortsätter med detta om den själv får in Joins eller någon host på ett directly connected interface svarar på IGMP Queries. Prune timer är default 3 minuter.

Med sparse mode används shared trees som betecknas (*,G). RP kommer att gå med både i (*,G) men också (S,G) där S är source för strömmen. Finns det flera källor till strömmen kommer det först att gå till RP för att sedan forwardas ut shared distribution tree / root-path tree. Det finns även möjlighet för en PIM-SM router att bygga SPT direkt med källan. Ifall man har närmre till källan är det onödigt att all trafik ska gå igenom RP först. Då kan routern faktiskt meddela RP med ett Prune message att multicast-strömmen inte behöver skickas till den längre. Ciscoroutrar gör detta byte direkt efter första paketet, detta går att ändra med ip pim spt-threshold infinity.

På alla enheter (static RP):

ip multicast-routing
ip pim rp-address 10.0.0.10

interface gi2
 ip pim sparse-mode
interface gi3
 ip pim sparse-mode

På Rendezvous Point utöver det ovan

interface lo0
 ip address 10.0.0.10 255.255.255.0
 ip pim sparse-mode

En router vet om att den är RP om den har ett interface med den konfigurerade rp-adressen. Man måste kör PIM på det interface man annonserar som RP.

Verify

show ip mroute
show ip pim rp mapping

Auto-RP

I Sparse mode måste alla multicast-routrar känna till RP, i större nät blir detta mödosamt att konfigurera. Det finns två mekanismer för att upptäcka RP automatiskt, Auto-RP och BSR (se nästa stycke). Auto-RP är ett Ciscoproperitärt som använder 224.0.1.39 och 224.0.1.40 för kommunikation, dvs multicast som routas. Enheter som kör Auto-RP skickar först ut RP-Announce till 224.0.1.39 med sig själv satt som RP. Det skickas ut var 60:e sekund och det innehåller vilka multicast-grupper man är RP för. Detta leder till att olika routrar kan vara RP för olika grupper vilket ger lastdelning. Sedan måste någon vara mapping agent (vanligtvis samma enhet) som lär sig alla RPs och vilka grupper de är med i. Genom att gå med i 224.0.1.39 får man all info från RP. Mapping agent skickar sedan ut RP-Discovery till 224.0.1.40 och alla kan lära sig var RP finns. Alla Cisco-enheter som är konfigurerade för Auto-RP och Sparse mode går med i 224.0.1.40. Finns det flera RPs för samma grupp väljs den med högst RP-IP.

Allow AutoRP packets across sparse mode interface

ip pim autorp listener

Verify

show ip pim rp mapping

Lista tillåtna RPs

ip pim rp-announce-filter rp-list <access-list> group-list <access-list>

Sparse Dense Mode

Multicast magging agent, 224.0.1.39-40, UDP 496

ip pim send-rp-discovery INT scope TTL interval Seconds

requires pim sparse-dense-mode

Sparse-dense mode är som sparse mode fast grupper som lyckas registrera med RP blir dense mode.

ip pim sparse-dense-mode

BSR

En annan metod för att automatiskt hitta RP är PIM Bootstrap Router och fungerar på liknande sätt som Auto-RP. BSR fungerar som mapping agent i Auto-RP, de får in information från RPs som de sedan distribuerar vidare. Dock väljer inte BSR någon bästa RP utan information om alla skickas ut och övriga får välja själv vilken som är bäst. BSR floodar detta till all-PIM-routers (224.0.0.13). PIM-SM routrar floodar bootstrap messages på alla non-RPF interfaces vilket leder till att alla multicast-routrar får informationen. Kommer det in bootstrap message på non-RPF interface discardas det vilket förhindrar loopar. Alla c-RP kan berätta för BSR att de är RP och vilka grupper den är med i tack vare att alla vet unicast-adressen till BSR eftersom den har floodats till alla. RPs skickar c-RP Advertisments till BSR. Man kan ha redundanta RPs och redundanta BSRs. Dock kan endast en vara preferred BSR och skicka bootstrap messages, de övriga lyssnar och tar över när preferred BSR tystnar. Den som blir preferred avgörs av högst prio och sedan högst IP.

BSR, default prio är 0.

interface lo0
 ip pim sparse-mode
ip pim bsr-candidate Loopback0 0

RP

interface lo0
 ip pim sparse-mode
ip pim rp-candidate Loopback0 

Debug

debug ip pim bsr

Source Specific Multicast

Med SSM kan hostarna själva välja source för trafikströmmen ifall det finns flera. Adresser: 232.0.0.0-232.255.255.255.

Source Specific Multicast kräver IGMPv3.

ip igmp version 3

Bidirectional PIM

Måste konfigureras på alla PIM-interface.

ip pim bidir-enable

MSDP

Multicast Source Discovery Protocol används för inter-domain multicasting och för att låta RPs i ett enskilt AS dela information om de kör anycast RP.

ip msdp peer [peer_unique_address] connect-source [local_unique_interface]
ip msdp originator-id [unique_address_interface]