In cazul traficului unicast decizia de transmitere a unui pachet este in mod normal luata de fiecare router in parte tinand cont de adresa destinatie a fiecarui pachet. Tabela de rutare unicast este organizata in functie de clasele de adrese destinatie si astfel, cu ajutorul acesteia, pachetele sunt trimise de la sursa catre destinatie.

In cazul traficului multicast decizia de transmitere a unui pachet este luata in functie de adresa sursa si nu in functie de adresa destinatie ca in cazul traficului unicast. Daca un nod ar trimite implicit traficul multicast pe toate interfetele in afara de cea pe care traficul a venit, atunci ar aparea in mod inevitabil bucle.

Rolul algoritmului “Reverse Path Forwarding” (RPF) este sa asigure pentru traficul multicast un arbore de distributie lipsit de bucle. Fiecare router cauta adresa sursa a traficului multicast in tabela de rutare unicast pentru a determina interfata de iesire catre acea adresa. Daca interfata de iesire catre adresa sursa a traficului multicast este aceeasi cu interfata pe care traficul multicast a fost primit, atunci algoritmul RPF este validat. Pachetele multicast pentru care algoritmul RPF nu este validat vor fi inlaturate pentru ca interfata pe care au fost primite nu este parte din cea mai scurta cale catre sursa traficului multicast.

In continuare voi prezenta un caz practic in care ne propunem sa trimitem traficul multicast pe o anumita cale intre sursa si destinatie, cale care initial este si “best path” pentru traficul unicast, sa observam ce se intampla cand tabela de rutare unicast se modifica, este introdusa o noua cale “best path” intre sursa si destinatie, si sa gasim solutii pentru rezolvarea problemei generate.

Avem urmatoarea topologie de echipamente Cisco:

Initial calea R2<->R4 nu este functionala.

Router-ul R1 este sursa traficului multicast, NTP server (PIM Sparse-Dense Mode, Grup 224.0.1.1, Sursa 1.1.1.1), iar router-ul R5 este destinatia traficului multicast, NTP client (5.5.5.5). Traficul multicast intre sursa si destinatie va urma aceeasi cale ca si traficul unicast: R1->R2->R3->R4->R5.

PIM va fi configurat pe toate legaturile mai putin  pe legatura R2<->R4.

Ri(config)#ip multicast-routing
Ri(config-if)#ip pim sparse-dense-mode

Comanda “ip pim sparse-dense-mode” va fi data atat pentru interfetele Loopback 0, cat si pentru interfetele de interconectare.

Adresa IP a Rendezvous Point (RP)  este definita static ca fiind adresa IP a interfetei Loopback 0 de pe R2:

ip pim rp-address 2.2.2.2

Rezultatul comenzii “show ip mroute 224.0.1.1” data pe R5 arata ca:

1. router-ul R5, clientul multicast, a facut initial join la grupul multicast 224.0.1.1 folosind un arbore de distributie “shared” (*, 224.0.1.1) care are ca si radacina router-ul RP R2;

2. imediat dupa ce router-ul R5 a aflat despre adresa sursa a traficului multicast, acesta a facut join direct la sursa, iar traficul multicast este trimis acum direct de sursa R1 catre destinatia R5 pe calea cea mai “scurta” fara a implica RP-ul in distributie (flags: LFT, T – SPT-bit set);

3. RP-ul nu mai trimite traficul pentru 224.0.1.1 catre router-ul R5: (*, 224.0.1.1), 00:05:27/stopped, arborele de distributie a traficului multicast devine astfel din “Shared” un arbore SPT sau “Shortest Path Tree”.

R5#show ip mroute 224.0.1.1
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, F - Register flag, T - SPT-bit set, J - Join SPT
(*, 224.0.1.1), 00:05:27/stopped, RP 2.2.2.2, flags: SJCLF
Incoming interface: GigabitEthernet1/0, RPF nbr 192.168.0.13
Outgoing interface list:
Loopback0, Forward/Sparse-Dense, 00:05:27/00:02:16
(5.5.5.5, 224.0.1.1), 00:01:29/00:02:03, flags: LFT
Incoming interface: Loopback0, RPF nbr 0.0.0.0, Registering
Outgoing interface list:
GigabitEthernet1/0, Forward/Sparse-Dense, 00:01:29/00:02:59

Este interesant de observat ca vecinii RPF (RPF nbr) sunt diferiti pentru cele doua intrari din tabela de rutare. Este o greseala, ce anume explica aceasta diferenta?

Verificam daca algoritmul RPF este validat acum cand “best path” unicast corespunde cu calea definita pentru distributia traficului multicast:

R2#show ip mroute count
Forwarding Counts: Pkt Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 224.0.1.1, Source count: 2, Packets forwarded: 18, Packets received: 18
RP-tree: Forwarding: 13/0/100/0, Other: 13/0/0
Source: 192.168.0.14/32, Forwarding: 1/0/100/0, Other: 1/0/0
Source: 5.5.5.5/32, Forwarding: 4/0/100/0, Other: 4/0/0

Observam ca nici un pachet multicast primit de router-ul R2 nu a fost inlaturat (Packets forwarded: 18, Packets received: 18), iar algoritmul RPF a fost validat de fiecare data  (RPF failed = 0).

Ne propunem acum sa vedem ce se intampla cand legatura R2<->R4 este configurata pentru traficul unicast, insa nu si pentru traficul multicast, intrucat ne dorim ca traficul multicast sa fie trimis doar pe calea initiala R1->R2->R3->R4->R5.

Traficul unicast va avea acum o noua cale “best path” intre R1 si R5 si anume R1->R2->R4->R5.

Algortimul RPF nu va fi validat pe router-ul R4 pentru ca  “best path” in tabela de rutare unicast catre sursa traficului multicast este interfata router-ului R4 catre router-ul R2 iar traficul multicast este primit numai prin interfata router-ului R4 catre router-ul R3. Router-ul R4 nu va transmite traficul multicast catre clientul R5 (Incoming interface: Null).

R4#show ip mroute
(5.5.5.5, 224.0.1.1), 00:27:53/00:02:51, flags: PR
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

R4#show ip rpf  1.1.1.1
RPF information for ? (1.1.1.1) failed, no route exists

Ce solutii sunt totusi daca dorim sa avem cai distincte pentru traficul unicast si pentru cel multicast?

In situatia data cel mai rapid ar fi sa folosim rutarea statica astfel pe router-ul R4, acolo unde algoritmul RPF intrerupe transmiterea traficlului multicast:

R4(config)#ip mroute 0.0.0.0 0.0.0.0 192.168.0.9

prin care configuram R4 sa foloseasca pentru algoritmul RPF next-hop interfata catre R3 si nu interfata catre R2, interfata folosita in cazul traficului unicast.

Cum ar trebui sa rescriem comanda “ip mroute” daca am vrea sa fim specifici, considerand ca 0.0.0.0 are un caracter prea general?

Dupa folosirea rutei statice algoritmul RPF va fi validat:

R4#show ip rpf  1.1.1.1
RPF information for ? (1.1.1.1)
RPF interface: GigabitEthernet2/0
RPF neighbor: ? (192.168.0.9)
RPF route/mask: 0.0.0.0/0
RPF type: static

O a doua solutie pentru a permite traficului multicast sa foloseasca o cale distincta de cea folosita de traficul unicast este folosirea extensiei multicast a protocolului BGP, MBGP. Informatiile oferite de catre MBGP sunt folosite de catre algoritmul RPF pentru a valida/invalida o cale multicast.

In topologia prezentata aici este suficient sa configuram o sesiune MBGP intre R3 si R4, folosind ca si neighbori adresele Loopback 0 ale celor doua routere, prin care R3 sa anunte prefixul 1.1.1.1/32, sursa traficului multicast.

Configuratia router-ului R3 poate fi astfel:

router bgp 65535
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 4.4.4.4 remote-as 65535
neighbor 4.4.4.4 update-source Loopback0
!
address-family ipv4
no neighbor 4.4.4.4 activate
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 multicast
neighbor 4.4.4.4 activate
no auto-summary
network 1.1.1.1 mask 255.255.255.255
exit-address-family

Verificam apoi daca algoritmul RPF este validat de catre router-ul R4:

R4#show ip rpf 1.1.1.1
RPF information for ? (1.1.1.1)
RPF interface: GigabitEthernet2/0
RPF neighbor: ? (192.168.0.9)
RPF route/mask: 1.1.1.1/32
RPF type: mbgp

Rezultatul este cel asteptat, algoritmul RPF este validat, intre R1 si R5 traficul multicast va folosi calea R1->R2->R3->R4->R5, iar traficul unicast va folosi calea R1->R2->R4->R5. Configurarea extensiei multicast pentru protocolul BGP nu influenteaza traficul unicast.