MBGP Deployment

General Guidelines for MBGP

The topology of inter-domain IPv4 multicast forwarding is determined by BGPv4 policy with multiprotocol extension (MBGP).

MBGP is an extension to the existing BGP protocol; it allows BGP to carry more than just IPV4 route prefixes.

The new attributes MP_REACH_NLRI and MP_UNREACH_NRLI make it possible to distinguish the NRLI.

• IPv4 prefixes for Unicast routing
• IPv4 prefixes for Multicast RPF checking
• IPv6 prefixes for Unicast routing
• IPv6 prefixes for Multicast RPF checking.

The definition of reachability is different for IPv4 unicast (NLRI=unicast, SAFI=1), IPv4 multicast (NLRI=Multicast, SAFI=2) and combined (SAFI=3).

(NLRI=unicast, SAFI=1):

• The conventional network reachability advertisement.
• NRLI is used for unicast routing.

(NLRI=Multicast, SAFI=2):

• NRLI is used for multicast RPF check.

(combined multicast and unicast advertisements SAFI=3): 

• NRLI is used for both unicast routing and multicast RPF check.

MBGP provides a method to distinguish which routes or prefixes are used for performing either unicast routing or multicast RPF (Reverse Path Forwarding) checks between autonomous systems.

On the routers two routing tables are maintained separately:

• The Unicast RIB which will be populated by NRLI "unicast" => SAFI 1&3
• The Multicast RIB which will be populated by NRLI "multicast" => SAFI 2&3

GÉANT2-Specific Guidelines

All BGP peers should be configured to exchange the unicast routes that are being used by multicast for resolving the RPF check. On Juniper routers, replacing the unicast keyword with any to the group family inet statements of every BGP peer does this.

Full MBGP routing tables should be announced filtering according to the GÉANT2 routing policy:

• Exact matches based on the RIPE database are accepted
• Networks with a netmask longer than /25 are not propagated in GÉANT - must be verified 
• Networks with a netmask longer than /24 are not propagated towards US peers - must be verified.

For each peer, two policy statements will be created: import and export:

• The import policy statement will define routes that can be accepted from that peer.
• The export policy statement will define routes that will be sent to that peer.

For iMBGP peering there is no filtering.

The iMBGP peering is always performed using the Loopback address.

eMBGP peering is always performed using the interface-assigned address.

Examples

Juniper Example

bgp { 
       local-address MY-LOOPBACK-ADDRESS; 
       group INTERNAL-PEER1 { 
            description "Peering with remote PoP1"; 
            family inet { 
                any; 
            } 
            peer-as DANTE-AS; 
            neighbor REMOTE-LOOPBACK-ADDRESS; 
       } 
 ... 
      group NREN1-PEER { 
            description "Peering with NREN1"; 
            local-address MY-INTERFACE-ADDRESS; 
            family inet { 
                any; 
            } 
            peer-as REMOTE-AS; 
            neighbor REMOTE-INTERFACE-ADDRESS { 
                import FROM-NREN1; 
                export TO-NREN1; 
            } 
        } 
}