We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 644 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

466 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags:


Forum 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.

    https://networklessons.com/cisco/ccie-routing-switching-written/multicast-rpf-reverse-path-forwarding/

    Now to your question. If a GRE tunnel is used only for multicast traffic, then there will be no u

    ... Continue reading in our forum

  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

    ... Continue reading in our forum

  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.

    ... Continue reading in our forum

  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

    ... Continue reading in our forum

1 more reply! Ask a question or join the discussion by visiting our Community Forum