Tags:


Notable Replies

  1. Will this issue not arise in tunnel intended to pass both Unicast and Multicast?

  2. Hello Deep

    First of all, one major difference between unicast and multicast routing is that for unicast routing, we only care about the destination and how to get there. For multicast routing, we care about the source as well. PIM uses the unicast routing table to check what interface will be used to reach the source. More on this can be found at this lesson.

    Now to your question. If a GRE tunnel is used only for multicast traffic, then there will be no unicast routing
    information concerning routes over the GRE tunnel. Therefore you will run into the RPF problem. If you do use unicast over the GRE tunnel, unicast routes will be available and you will not have the RPF problem.

    I hope this has been helpful!

    Laz

  3. PIM sparse solution:
    In R2 conf you have:

    ip mroute 192.168.1.0 255.255.255.0 192.168.12.1
    ip mroute 1.1.1.1 255.255.255.255 192.168.12.1
    ip route 0.0.0.0 0.0.0.0 192.168.23.3
    

    If you wouldn’t have “ip mroute 192.168.1.0 255.255.255.0 192.168.12.1” your unicast would go by the traditional path instead of the tunnel. Isn’t it? And in that way it wouldn’t work, am I right?

    Then in R1 you don’t have any ip mroute. Should we also route the unicast traffic by the tunnel?

    If we have a bidir multicast implementation with a GRE tunnel, would it work? But in that case my question about mroute in R1 would make sence, isn’t it?

  4. Hello Miguel

    First of all, remember that the mroute commands refer only to multicast traffic, so whether you implement the ip mroute 192.168.1.0 255.255.255.0 192.168.12.1 command or not will not affect the unicast traffic.

    This command is implemented in order to verify that the RPF check is passed. The RPF check essentially checks to see if the source IP address of the multicast traffic is reachable via a routing entry in the routing table that matches the interface via which the packet entered the router. If this check is not passed, the packet is dropped. In order for this check to be passed, the ip mroute 192.168.1.0 255.255.255.0 192.168.12.1 command is implemented, thus satisfying the requirements of the check.

    Once again, the mroute commands do not apply to unicast traffic. However, in order for unicast traffic to successfully traverse the tunnel, the appropriate routes must be installed in the routing table.

    Remember that the above command was implemented not to enable bidirectional multicast traffic, but to satisfy the RPF check. If the RPF check is satisfied, then multicast will function correctly over a GRE tunnel.

    I hope this has been helpful!

    Laz

  5. Thanks for your explanation.
    I understand better the use of ip mroute.

    But I still have 2 questions:

    1. In the case you have R1-R2-R3*(RP)-R4-R5, with senders and receivers in all R%, would you have to configure ip mroute in R1,R2,R4 and R5?

    In the case you have many senders and receivers in both sides R1 and R2, and a tunnel between them, would you recommend to implement pim sparse-dense mode or bidir multicat implementation?

    I have in the lab 2 L3 in this config:
    SW-R1-R2-SW2
    I have R1 and R2 with pim sparse-dense-mode + ip routing
    I used:

    ip routing
    ip multicast-routing distributed
    
    router eigrp 100
     network 0.0.0.0 0.0.0.0
     exit
    

    I didn’t use ip mroute. And even having senders and receivers in both sides they were communicating well in multicast.
    why didn’t I need ip mroute?

Continue the discussion forum.networklessons.com

3 more replies!

Participants