Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Controller-Based BGP Multicast Signaling

Network controllers that are aware of the network topology and the events within the topology can calculate end-to-end explicit paths. This calculation results in optimum multicast trees between the source and the receivers. A network controller uses the programmable routing protocol daemon (PRPD) and BGP signaling to signal each router on the multicast tree to set up and program multicast forwarding states.

The controller uses PRPD APIs to program BGP multicast network layer reachability information (NLRI). All the routers are programmed either directly or through a route reflector. A route reflector also propagates the NLRI to all the routers on the trees. Based on the NLRI received, the routers set up appropriate forwarding states.

In the following sections of this topic we use controller to mean network controller.

Benefits of Controller-Based BGP Multicast Signaling

Traditional multicast deployments have inherent drawbacks. Controller-based BGP signaling eliminates drawbacks such as the following:

  • In hop-by-hop multicast protocols such as Protocol Independent Multicast (PIM), among other limitations, the any-source multicast mode needs periodic refreshing and is complex to configure. PIM source-specific multicast and PIM-Port mode have similar drawbacks.

  • Data centers that use BGP as their primary routing protocol avoid deploying multicast, because this deployment requires additional protocols and creates associated complexities.

Transit Router Programming Based on PRPD

With the help of a provisioning server or orchestrator, the controller is aware of the multicast flow information of the source, groups, and receivers. The controller calculates an optimum tree to forward the source traffic to all the interested receivers for a group.

Figure 1: Transit Router Programming Based on PRPDTransit Router Programming Based on PRPD

After calculating the multicast tree, the controller uses the PRPD interface to program each transit router on the tree with the BGP multicast Leaf Auto Discovery (AD) NLRI. The Leaf AD route contains the source, group, and upstream information.

The Leaf AD NLRI also carries a tunnel encapsulation attribute (TEA) that has information about the downstream routers to which traffic needs to be replicated. TEA is a transitive BGP path attribute that specifies the encapsulation protocols and any additional information required to use those protocols correctly.

Using this information, a router can program the multicast forwarding states to forward traffic.

Route Reflector Programming Based on PRPD and Traffic Transmission Using BGP

At times, the controller may not have PRPD connections to all the transit routers. But if BGP is running on the network, the controller needs only a single PRPD connection to a route reflector or a virtual route reflector (vRR). Using the multicast information about the source, group, and receivers, the controller programs the BGP multicast NLRI intended for all the routers on the multicast tree on the route reflector. The route reflector further propagates the BGP multicast NLRI through BGP signaling to all its neighbors which eventually reaches all the routers on the multicast tree.

Figure 2: Route Reflector Programming Based on PRPDRoute Reflector Programming Based on PRPD

If the route target associated with the NLRI has the router ID of the intended router, the router accepts the route and an appropriate forwarding state is programmed on the router.

Note:

The route target resolution RIB by default is inet.3. For BGP multicast to work, you need to explicitly set the rib resolution to inet.0 in the configuration by using this command:

set routing-options resolution rib bgp.rtarget.0 resolution-ribs inet.0

You can also apply route target constraints to filter the routes from the route reflector.

Related Documentation