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 637 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

 

374 New Members signed up the last 30 days!

satisfaction-guaranteed

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


Forum Replies

  1. Hi Hussein,

    I first thought you would need ip pim nbma-mode on the hub tunnel interface but in reality, we don’t. For example, take this topology:

    https://networklessons.com/cisco/ccie-routing-switching/dmvpn-phase-3-ospf-routing/

    Then add these additional commands:

    Hub, Spoke1 & Spoke2
    (config)#ip multicast-routing
    
    (config)#interface Tunnel 0
    (config-if)#ip pim sparse-mode
    
    (config)#ip pim rp-address 1.1.1.1
    

    The loopback of the hub is the RP so I need PIM sparse mode there too, and we need NBMA mode on the tunnel:

    Hub(config)#interface Loopback 0
    Hub(config
    ... Continue reading in our forum

  2. Thanks @ReneMolenaar

    Now I know it’s working without PIM NBMA mode but I have something unintelligible about how the multicast traffic go directly from spoke to spoke since we do not have any multicast mapping between spokes routers so only unicast traffic are allowed between them ?? can you please explain what exactly happened behind the scene ??

  3. Hi Hussein,

    I had to think about this for awhile and do another lab…something interesting happened :smile: With the DMVPN topology that I usually use (switch in the middle), multicast traffic went directly from spoke1 to spoke2. Take a look at this Wireshark capture:

    https://cdn-forum.networklessons.com/uploads/default/original/1X/45c5f4cfbaf80921dc7da699241007f586549885.jpg

    The ICMP request from spoke1 isn’t encapsulated. The reply from spoke2 is.

    So I labbed this up again, replaced the switch in the middle with a router. When you do this, all multicast traffic from

    ... Continue reading in our forum

  4. Thank you again @ReneMolenaar,

    Now the logic of multicast mapping in my mind is Satisfied :smile:.
    But in this case you need to use pim-nbma mode in the tunnel interface of the hub router to disable RPF rule and solve the split horizon problem, and I did not see you configured it in the attached configuration in your comment.

    Second question come to my mind when I was typing this reply which is how can pim-nbma mode deal with pim prune message ??

    Also I was wondering when you are using the switch why the ICMP request from Spoke 1 are not encapsulated in GRE and use NB

    ... Continue reading in our forum

  5. Hi Hussein,

    I just redid this lab on some real hardware and I think this is some Cisco VIRL quirk. When I run it on VIRL, I don’t need to use PIM nbma mode. On real hardware, I do need it.

    Spoke1-VIRL#show version | include 15
    Cisco IOS Software, IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.6(3)M2, RELEASE SOFTWARE (fc2)
    Spoke1-REAL#show version | include 15
    Cisco IOS Software, 2800 Software (C2800NM-ADVENTERPRISEK9-M), Version 15.1(4)M7, RELEASE SOFTWARE (fc2)

    Let’s join a group:

    Spoke2(config)#interface gi0/0
    Spoke2(config-if)#ip igmp join-group 239.3.3
    ... Continue reading in our forum

10 more replies! Ask a question or join the discussion by visiting our Community Forum