Supported Platforms
Related Documentation
- ACX, J, M, MX, SRX Series
- Understanding External BGP Peering Sessions
- BGP Configuration Overview
- M, MX, T Series
- Example: Configuring Flow Routes
Examples: Configuring Multiprotocol BGP
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 Configuration Guide.
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
- Limiting the Number of Prefixes Accepted on a BGP Peer Session
- Configuring BGP Routing Table Groups
- Resolving Routes to PE Routing Devices Located in Other ASs
- Allowing Labeled and Unlabeled Routes
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.
Example: Configuring IPv6 BGP Routes over IPv4 Transport
This example demonstrates how to export both IPv6 and IPv4 prefixes over an IPv4 connection where both sides are configured with an IPv4 interface.
Requirements
No special configuration beyond device initialization is required before you configure this example.
Overview
Keep the following in mind when exporting IPv6 BGP prefixes:
- BGP derives next-hop prefixes using the IPv4-compatible
IPv6 prefix. For example, the IPv4 next-hop prefix 10.19.1.1 translates to the IPv6 next-hop prefix ::ffff:10.19.1.1.
Note: There must be an active route to the IPv4-compatible IPv6 next hop to export IPv6 BGP prefixes.
- An IPv6 connection must be configured over the link. The connection must be either an IPv6 tunnel or a dual-stack configuration. Dual stacking is used in this example.
- When configuring IPv4-compatible IPv6 prefixes, use a mask that is longer than 96 bits.
- Configure a static route if you want to use normal IPv6 prefixes. This example uses static routes.
Figure 1 shows the sample topology.
Figure 1: Topology for Configuring IPv6 BGP Routes over IPv4 Transport
Configuration
CLI Quick Configuration
To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.
Device R1
Device R2
Device R3
Configuring Device R1
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To configure Device R1:
- Configure the interfaces, including both an IPv4 address
and an IPv6 address.[edit interfaces]user@R1# set fe-1/2/0 unit 1 family inet address 192.168.10.1/24user@R1# set fe-1/2/0 unit 1 family inet6 address ::ffff:192.168.10.1/120user@R1# set lo0 unit 1 family inet address 10.10.10.1/32
- Configure EBGP.[edit protocols bgp group ext]user@R1# set type externaluser@R1# set export send-directuser@R1# set export send-staticuser@R1# set peer-as 200user@R1# set neighbor 192.168.10.10
- Enable BGP to carry IPv4 unicast and IPv6 unicast routes.
.
IPv4 unicast routes are enabled by default. The configuration is shown here for completeness.
- Configure the routing policy.[edit policy-options]user@R1# set policy-statement send-direct term 1 from protocol directuser@R1# set policy-statement send-direct term 1 then acceptuser@R1# set policy-statement send-static term 1 from protocol staticuser@R1# set policy-statement send-static term 1 then accept
- Configure some static routes.[edit routing-options]user@R1# set rib inet6.0 static route ::ffff:192.168.20.0/120 next-hop ::ffff:192.168.10.10user@R1# set static route 192.168.20.0/24 next-hop 192.168.10.10
- Configure the autonomous system (AS) number.[edit routing-options]user@R1# set autonomous-system 100
Results
From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
If you are done configuring the device, enter commit from configuration mode. Repeat the configuration on Device R2 and Device R3, changing the interface names and IP addresses, as needed.
Verification
Confirm that the configuration is working properly.
Checking the Neighbor Status
Purpose
Make sure that BGP is enabled to carry IPv6 unicast routes.
Action
From operational mode, enter the show bgp neighbor command.
user@R2> show bgp neighbor Peer: 192.168.10.1+179 AS 100 Local: 192.168.10.10+54226 AS 200
Type: External State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-direct send-static ]
Options: <Preference AddressFamily PeerAS Refresh>
Address families configured: inet-unicast inet6-unicast
Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 10.10.10.1 Local ID: 10.10.0.1 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 0
BFD: disabled, down
Local Interface: fe-1/2/0.2
NLRI for restart configured on peer: inet-unicast inet6-unicast
NLRI advertised by peer: inet-unicast inet6-unicast
NLRI for this session: inet-unicast inet6-unicast
Peer supports Refresh capability (2)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
NLRI that restart is negotiated for: inet-unicast inet6-unicast
NLRI of received end-of-rib markers: inet-unicast inet6-unicast
NLRI of all end-of-rib markers sent: inet-unicast inet6-unicast
Peer supports 4 byte AS extension (peer-as 100)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 1
Received prefixes: 3
Accepted prefixes: 2
Suppressed due to damping: 0
Advertised prefixes: 4
Table inet6.0 Bit: 20000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 1
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 2
Last traffic (seconds): Received 24 Sent 12 Checked 60
Input messages: Total 132 Updates 6 Refreshes 0 Octets 2700
Output messages: Total 133 Updates 3 Refreshes 0 Octets 2772
Output Queue[0]: 0
Output Queue[1]: 0
Peer: 192.168.20.1+179 AS 300 Local: 192.168.20.21+54706 AS 200
Type: External State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-direct send-static ]
Options: <Preference AddressFamily PeerAS Refresh>
Address families configured: inet-unicast inet6-unicast
Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 10.10.20.1 Local ID: 10.10.0.1 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 1
BFD: disabled, down
Local Interface: fe-1/2/1.3
NLRI for restart configured on peer: inet-unicast inet6-unicast
NLRI advertised by peer: inet-unicast inet6-unicast
NLRI for this session: inet-unicast inet6-unicast
Peer supports Refresh capability (2)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
NLRI that restart is negotiated for: inet-unicast inet6-unicast
NLRI of received end-of-rib markers: inet-unicast inet6-unicast
NLRI of all end-of-rib markers sent: inet-unicast inet6-unicast
Peer supports 4 byte AS extension (peer-as 300)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 1
Received prefixes: 3
Accepted prefixes: 2
Suppressed due to damping: 0
Advertised prefixes: 4
Table inet6.0 Bit: 20000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 1
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 2
Last traffic (seconds): Received 1 Sent 15 Checked 75
Input messages: Total 133 Updates 6 Refreshes 0 Octets 2719
Output messages: Total 131 Updates 3 Refreshes 0 Octets 2734
Output Queue[0]: 0
Output Queue[1]: 0Meaning
The various occurrences of inet6-unicast in the output shows that BGP is enabled to carry IPv6 unicast routes.
Checking the Routing Table
Purpose
Make sure that Device R2 has BGP routes in its inet6.0 routing table.
Action
From operational mode, enter the show route protocol bgp inet6.0 command.
user@R2> show route protocol bgp table inet6.0inet6.0: 7 destinations, 10 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
::ffff:192.168.10.0/120 [BGP/170] 01:03:49, localpref 100, from 192.168.20.1
AS path: 300 I
> to ::ffff:192.168.20.21 via fe-1/2/1.3
::ffff:192.168.20.0/120 [BGP/170] 01:03:53, localpref 100, from 192.168.10.1
AS path: 100 I
> to ::ffff:192.168.10.10 via fe-1/2/0.2Enabling Layer 2 VPN and VPLS Signaling
You can enable BGP to carry Layer 2 VPN and VPLS NLRI messages.
To enable VPN and VPLS signaling, include the family statement:
For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.
To configure a maximum number of prefixes, 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.
When you set the maximum number of prefixes, a message is logged when that number is reached. If you include the teardown statement, the session is torn down when the maximum number of prefixes is reached. If you specify a percentage, messages are logged when the number of prefixes reaches that percentage. Once the session is torn down, it is reestablished in a short time. Include the idle-timeout statement to keep the session down for a specified amount of time, or forever. If you specify forever, the session is reestablished only after you use the clear bgp neighbor command.
Related Documentation
- ACX, J, M, MX, SRX Series
- Understanding External BGP Peering Sessions
- BGP Configuration Overview
- M, MX, T Series
- Example: Configuring Flow Routes
Published: 2013-01-22
Supported Platforms
Related Documentation
- ACX, J, M, MX, SRX Series
- Understanding External BGP Peering Sessions
- BGP Configuration Overview
- M, MX, T Series
- Example: Configuring Flow Routes
