Difference between revisions of "Cisco PIM"
Helikopter (talk | contribs) |
Helikopter (talk | contribs) |
||
| Line 6: | Line 6: | ||
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. | 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= | + | ==Konfiguration== |
| + | Global enable | ||
ip multicast-routing | ip multicast-routing | ||
| + | På vissa enheter är kommandot ''ip multicast-routing distributed'' | ||
Gå med i grupp manuellt | Gå med i grupp manuellt | ||
| Line 22: | Line 24: | ||
ip multicast boundary | ip multicast boundary | ||
| − | + | '''Limiting''' <br/> | |
| + | Global multicast mroute limit | ||
| + | ip multicast limit cost <ACL> <cost> | ||
| + | Maximum number of multicast routes | ||
| + | ip multicast route-limit 100 | ||
| + | |||
| + | =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. | 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. | ||
| Line 28: | Line 36: | ||
show ip mroute | 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. | + | 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. 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. |
| + | |||
| + | På alla enheter | ||
| + | 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. | ||
| + | |||
| + | ==Sparse Dense Mode== | ||
| + | ip pim sparse-dense-mode | ||
| + | |||
| + | ==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. | ||
| − | ip | + | Source Specific Multicast kräver IGMPv3. |
| + | ip igmp version 3 | ||
==LAN== | ==LAN== | ||
| Line 44: | Line 74: | ||
Designated Router <br/> | 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. | 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. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==Bidirectional PIM== | ==Bidirectional PIM== | ||
| + | ip pim bidir-enable | ||
==MSDP== | ==MSDP== | ||
Revision as of 17:30, 18 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.
Contents
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
ip multicast-routing
På vissa enheter är kommandot ip multicast-routing distributed
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
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. 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.
På alla enheter
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.
Sparse Dense Mode
ip pim sparse-dense-mode
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
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.
Bidirectional PIM
ip pim bidir-enable
MSDP
Multicast Source Discovery Protocol
