PIM NBMA mode

Hi all,

Can u pls help me understand:


Q. Why should we configure ip pim nbma-mode on frame-relay
serial interface?

Q. Why PIM nbma-mode is not recommended for sparse-dense-mode?

Q. Should we configure ip nbma-mode only on FR Hub router?

 

Thanks,

Ashish

 

Comments

  • ashse,

    ip pim nbma-mode is intended to overcome the default split-horizon policy that prevents forwarding packets out the same interface they were received on. This is a loop prevention method.

    ip pim nbma-mode operates like OSPF's point-to-multipoint mode, where the connection from the HUB to each SPOKE is treated like a separate point-to-point link, and separate mroute entries are created in the HUB's multicast routing table.

    There is no reason to configure this mode on a SPOKE router - the SPOKE router only has a single connection to the HUB router, and no direct connections to any other router in the hub and spoke environment.

    Hi all,

    Can u pls help me understand:

     

    Q. Why should we configure ip pim nbma-mode on frame-relay
    serial interface?

    Q. Why PIM nbma-mode is not recommended for sparse-dense-mode?

    Q. Should we configure ip nbma-mode only on FR Hub router?

     

     

    Thanks,

    Ashish

     

     

  • The purpose of ip pim nbma-mode, first try to understand the effect of split-horizon on RIP and EIGRP in HUB and SPOKE topology.

     

    When HUB router gets the multicast feeds from one SPOKE, doesn't forward through the same interface  to other SPOKE (because outgoing interface is same as incoming interface).

    If you try to use ip pim nbma-mode command in dense-mode, you will get error message because dense-mode works differently than sparse-mode (DENSE mode works on push technology but sparse on pull technology).

     

    When you enable the ip pim nbma-mode in sparse-mode, (it's like disabling the split-horizon on RIP and EIGRP), HUB forwards the mutlicast feeds received from one SPOKE to another SPOKE (even incoming and outgoing interface is same).

    We can resolve this issue in different ways as well instead of using the ip pim nbma-mode.

     

    1. Instead of multipoint, create point-to-point to all SPOKE

    2. Configure static multicast route

    3. Configure tunnel and enable multicast

     

    You can refere this document as well:

    http://www.cisco.com/en/US/docs/ios/12_2/ipmulti/command/reference/1rfmult2.html#wp1090395

  • 2. Configure static multicast route

     

    Do you mean to reach the spokes via non-FR path in case such one is available?

    I wonder how it can help if spokes have only FR connectivity.

     

  • I mean create tunnel interface on HUB and SPOKE, enable multicast on tunnel after that create static mutlicast route.

     

    I took some lines form Petr's blog:

    By default, when you configure a static mroute, its admin distance is zero. For example, if you have a static default mroute ip mroute 0.0.0.0 0.0.0.0
    it will always be used over any longer-matching unicast prefix, since
    it matches everything and has the AD of zero. As another example, assume
    that you want prefix 192.168.1.0/24 to be RPF checked again unicast
    table while the rest against addresses matched against the default
    mroute. You may configure something like this:

    ip mroute 192.168.1.0 255.255.255.0 null 0 255
    ip mroute 0.0.0.0 0.0.0.0 Tunnel 0

    Give few minutes to this blog as well
    http://blog.ine.com/2011/07/31/understanding-static-multicast-routes/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+ine+(INE+CCIE+Blog)

    HAPPY :)
Sign In or Register to comment.