Supported Platforms
Understanding Multiprotocol BGP
Multiprotocol BGP (MP-BGP) is an extension to BGP that enables BGP to carry routing information for multiple network layers and address families. MP-BGP can carry the unicast routes used for multicast routing separately from the routes used for unicast IP forwarding.
To enable MP-BGP, you configure BGP to carry network layer reachability information (NLRI) for address families other than unicast IPv4 by including the family inet statement:
To enable MP-BGP to carry NLRI for the IPv6 address family, include the family inet6 statement:
On routers only, to enable MP-BGP to carry Layer 3 virtual private network (VPN) NLRI for the IPv4 address family, include the family inet-vpn statement:
On routers only, to enable MP-BGP to carry Layer 3 VPN NLRI for the IPv6 address family, include the family inet6-vpn statement:
On routers only, to enable MP-BGP to carry multicast VPN NLRI for the IPv4 address family and to enable VPN signaling, include the family inet-mvpn statement:
To enable MP-BGP to carry multicast VPN NLRI for the IPv6 address family and to enable VPN signaling, include the family inet6-mvpn statement:
For more information about multiprotocol BGP-based multicast VPNs, see the Multicast Protocols Feature Guide for Routing Devices.
For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements.
 | Note: If you change the address family specified in the [edit protocols bgp family] hierarchy level, all current BGP sessions on the routing device are dropped and then reestablished. |
In Junos OS Release 9.6 and later, you can specify a loops value for a specific BGP address family.
By default, BGP peers carry only unicast routes used for unicast forwarding purposes. To configure BGP peers to carry only multicast routes, specify the multicast option. To configure BGP peers to carry both unicast and multicast routes, specify the any option.
When MP-BGP is configured, BGP installs the MP-BGP routes into different routing tables. Each routing table is identified by the protocol family or address family indicator (AFI) and a subsequent address family identifier (SAFI).
The following list shows all possible AFI and SAFI combinations:
- AFI=1, SAFI=1, IPv4 unicast
- AFI=1, SAFI=2, IPv4 multicast
- AFI=1, SAFI=128, L3VPN IPv4 unicast
- AFI=1, SAFI=129, L3VPN IPv4 multicast
- AFI=2, SAFI=1, IPv6 unicast
- AFI=2, SAFI=2, IPv6 multicast
- AFI=25, SAFI=65, BGP-VPLS/BGP-L2VPN
- AFI=2, SAFI=128, L3VPN IPv6 unicast
- AFI=2, SAFI=129, L3VPN IPv6 multicast
- AFI=1, SAFI=132, RT-Constrain
- AFI=1, SAFI=133, Flow-spec
- AFI=1, SAFI=134, Flow-spec
- AFI=3, SAFI=128, CLNS VPN
- AFI=1, SAFI=5, NG-MVPN IPv4
- AFI=2, SAFI=5, NG-MVPN IPv6
- AFI=1, SAFI=66, MDT-SAFI
- AFI=1, SAFI=4, labeled IPv4
- AFI=2, SAFI=4, labeled IPv6 (6PE)
Routes installed in the inet.2 routing table can only be exported to MP-BGP peers because they use the SAFI, identifying them as routes to multicast sources. Routes installed in the inet.0 routing table can only be exported to standard BGP peers.
The inet.2 routing table should be a subset of the routes that you have in inet.0, since it is unlikely that you would have a route to a multicast source to which you could not send unicast traffic. The inet.2 routing table stores the unicast routes that are used for multicast reverse-path-forwarding checks and the additional reachability information learned by MP-BGP from the NLRI multicast updates. An inet.2 routing table is automatically created when you configure MP-BGP (by setting NLRI to any).
When you enable MP-BGP, you can do the following:
Limiting the Number of Prefixes Received on a BGP Peer Session
You can limit the number of prefixes received on a BGP peer session, and log rate-limited messages when the number of injected prefixes exceeds a set limit. You can also tear down the peering when the number of prefixes exceeds the limit.
To configure a limit to the number of prefixes that can be received on a BGP session, include the prefix-limit statement:
For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.
For maximum number, specify a value in the range from 1 through 4,294,967,295. When the specified maximum number of prefixes is exceeded, a system log message is sent.
If you include the teardown statement, the session is torn down when the maximum number of prefixes is exceeded. If you specify a percentage, messages are logged when the number of prefixes exceeds that percentage of the specified maximum limit. After the session is torn down, it is reestablished in a short time (unless you include the idle-timeout statement). If you include the idle-timeout statement, the session can be kept down for a specified amount of time, or forever. If you specify forever, the session is reestablished only after the you issue a clear bgp neighbor command.
| Note: In Junos OS Release 9.2 and later, you can alternatively configure a limit to the number of prefixes that can be accepted on a BGP peer session. For more information, see Understanding Multiprotocol BGP. |
Limiting the Number of Prefixes Accepted on a BGP Peer Session
In Junos OS Release 9.2 and later, you can limit the number of prefixes that can be accepted on a BGP peer session. When that specified limit is exceeded, a system log message is sent. You can also specify to reset the BGP session if the limit to the number of specified prefixes is exceeded.
To configure a limit to the number of prefixes that can be accepted on a BGP peer session, include the accepted-prefix-limit statement:
For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.
For maximum number, specify a value in the range from 1 through 4,294,967,295.
Include the teardown statement to reset the BGP peer session when the number of accepted prefixes exceeds the configured limit. You can also include a percentage value from 1 through 100 to have a system log message sent when the number of accepted prefixes exceeds that percentage of the maximum limit. By default, a BGP session that is reset is reestablished within a short time. Include the idle-timeout statement to prevent the BGP session from being reestablished for a specified period of time. You can configure a timeout value from 1 through 2400 minutes. Include the forever option to prevent the BGP session from being reestablished until you issue the clear bgp neighbor command.
| Note: When nonstop active routing (NSR) is enabled and a switchover to a backup Routing Engine occurs, BGP peers that are down are automatically restarted. The peers are restarted even if the idle-timeout forever statement is configured. |
| Note: Alternatively, you can configure a limit to the number of prefixes that can be received (as opposed to accepted) on a BGP peer session. For more information, see Limiting the Number of Prefixes Received on a BGP Peer Session. |
Configuring BGP Routing Table Groups
When a BGP session receives a unicast or multicast NLRI, it installs the route in the appropriate table (inet.0 or inet6.0 for unicast, and inet.2 or inet6.2 for multicast). To add unicast prefixes to both the unicast and multicast tables, you can configure BGP routing table groups. This is useful if you cannot perform multicast NLRI negotiation.
To configure BGP routing table groups, include the rib-group statement:
For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.
Resolving Routes to PE Routing Devices Located in Other ASs
You can allow labeled routes to be placed in the inet.3 routing table for route resolution. These routes are then resolved for provider edge (PE) routing device connections where the remote PE is located across another autonomous system (AS). For a PE routing device to install a route in the VPN routing and forwarding (VRF) routing instance, the next hop must resolve to a route stored within the inet.3 table.
To resolve routes into the inet.3 routing table, include the resolve-vpn statement:
For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.
Allowing Labeled and Unlabeled Routes
You can allow both labeled and unlabeled routes to be exchanged in a single session. The labeled routes are placed in the inet.3 or inet6.3 routing table, and both labeled and unlabeled unicast routes can be sent to or received by the routing device.
To allow both labeled and unlabeled routes to be exchanged, include the rib statement:
For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.
