08-16-2015 11:07 AM - edited 03-08-2019 01:22 AM
Hello,
I created a PIM Sparse Multicast lab in GNS3.
Between the RP and my VLC Receiver, i got 2 routers for redundancy.
The whole topology is using EIGRP.
My VLC receiver is joining multicast group 224.4.4.4
My topology looks like this:
_R1_
/ \
MCast Server ----RP---- ----R4----VLC Receiver
\_R5_/
Running a "show ip mroute 224.4.4.4" on the RP, display the following information:
"
(*, 224.4.4.4), 00:00:04/stopped, RP 3.3.3.3, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet1/0, Forward/Sparse, 00:00:04/00:03:25
(192.168.56.10, 224.4.4.4), 00:00:04/00:03:25, flags: T
Incoming interface: FastEthernet0/0, RPF nbr 192.168.23.2
Outgoing interface list:
FastEthernet1/0, Forward/Sparse, 00:00:04/00:03:25
"
As you can see above multicast traffic to the VLC receiver is going out of interface FastEthernet1/0, which is towards R1.
Now my questions is, what makes it choose FastEthernet1/0 towards R1, instead of FastEthernet2/0 towards R5?
It will only choose FastEthernet2/0 if i shutdown R1.
Solved! Go to Solution.
08-16-2015 02:55 PM
Also when looking at the post about PIM Assert, it seems its only used with PIM Dense mode, my lab is PIM sparse mode.
They can occur with sparse mode as well but this is not what is happening here.
R4 sees two equal cost paths to both the RP and the source. With your topology even though it switches to an SPT, which is the default Cisco behaviour, the SPT actually still goes via the RP so the choice of path is really the same thing.
With Cisco if there are multiple equal cost paths then the router requesting the stream will send the join to the neighbor with the highest IP address which in your case is R1 ie. 40.40.40.x.
That is why the RP always sees the outgoing interface to R1 for both the shared tree and the SPT.
Jon
08-16-2015 12:01 PM
Hello
"Now my questions is, what makes it choose FastEthernet1/0 towards R1, instead of FastEthernet2/0 towards R5?"
This link explains assert concept better then I ever could?
http://blog.ine.com/2010/03/20/multicast-pim-assert-mechanism/
res
Paul
08-16-2015 01:19 PM
Hi Paul
I may well be wrong as multicast is a confusing subject but I don't think that's why the RP is choosing one path over the other because the RP is only sending one copy of that stream to R1.
Edit - the diagram doesn't match up with the explanation so it may be that you understood it better than me.
Jon
08-16-2015 01:19 PM
Hello Paul driver, I already tried chancing the metrics, but it did not make any difference.
Also when looking at the post about PIM Assert, it seems its only used with PIM Dense mode, my lab is PIM sparse mode.
Hello Jon, your right about the topoplogy seeming confusing. Becasue actually I have a Router betweem the McastServer and the RP, and thats why you see the IP 192.168.23.2.
So the real topology looks like this:
_R1_
/ \
MCast Server---R2----RP--- R4----VLC Receiver
\_R5_/
Here is a picture of my GNS3 toplogy with IP addresses and interfaces, and a show ip route on the RP:
http://imgur.com/lMJH4qV
Yes, R4 sees 2 paths with same metric to the Source of the stream.
08-16-2015 02:55 PM
Also when looking at the post about PIM Assert, it seems its only used with PIM Dense mode, my lab is PIM sparse mode.
They can occur with sparse mode as well but this is not what is happening here.
R4 sees two equal cost paths to both the RP and the source. With your topology even though it switches to an SPT, which is the default Cisco behaviour, the SPT actually still goes via the RP so the choice of path is really the same thing.
With Cisco if there are multiple equal cost paths then the router requesting the stream will send the join to the neighbor with the highest IP address which in your case is R1 ie. 40.40.40.x.
That is why the RP always sees the outgoing interface to R1 for both the shared tree and the SPT.
Jon
08-16-2015 04:16 PM
Your right, I actually got it working now.
Before I wrote here I had tried changing the metric(and the highest ip address) on incoming routes on R3 from R1 and R5, that didnt do the job.
But changing the metric(or highest ip address) on R4, made me able to change the path in both directions.
08-16-2015 04:42 PM
Hello
Apologies -my mistake, I misunderstood the topology , I took the first posting as the source
Given your answer Jon I guess then this is down to DR election and the highest ip of the interface wins if DR priorites are equal ?
res
Paul
08-16-2015 05:13 PM
Hi Paul
As far as I understand it, and I am by no means an expert on multicast, it is not related to the DR because R1, R4 and R5 do not share a common IP subnet. .
If they did then the DR would come into play.
But if you look at the topology they are actually separate links.
So R1 and R5 do not not exchange PIM hellos and do not see each other as neighbors.
It is just that R4 has two equal costs paths so it simply picks the next hop with the highest IP address and sends the join to that router.
I may lab this up tomorrow just to make sure I am not giving you misleading information.
Jon
08-16-2015 12:46 PM
The topology and the output are a little confusing ie.
your source seems to be connected directly to the RP and has an IP of 192.168.56.10.
But your mroute output from the RP shows an RPF neighbor of 192.168.23.2.
What is that IP address ?
In addition you say the RP uses different interfaces to R1 and R5 but your diagram doesn't show that.
Can you be more specific in terms of the actual interfaces connecting the routers to each other and provide the IP addresses.
Does R4 see two equal cost paths back to the source of the stream ?
Jon
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: