BGP Route Reflectors
Understanding BGP Route Reflectors
This topic discusses using route reflectors to simplify configuration
and aid in scaling. A further way to reduce the workload on a route
reflector that is not in the traffic-forwarding path is to use the no-install statement at the [edit protocols bgp family family-name] hierarchy level. Starting in Junos OS Release 15.1, the no-install statement eliminates interaction between the routing protocols daemon
(rpd) and other components in the Junos system such as the kernel
or the distributed firewall daemon (dfwd). This interaction is eliminated by prohibiting any routes in the
associated rpd routing information bases (RIBs), also known as routing
tables, from being published to those components.
In releases previous to Junos OS Release 15.1, you can reduce the workload on a route reflector that is not in the traffic-forwarding path by using a forwarding-table export policy that rejects routes learned from BGP.
Because of the internal BGP (IBGP) full-mesh requirement, most networks use route reflectors to simplify configuration. The formula to compute the number of sessions required for a full mesh is v * (v - 1)/2, where v is the number of BGP-enabled devices. The full-mesh model does not scale well. Using a route reflector, you group routers into clusters, which are identified by numeric identifiers unique to the autonomous system (AS). Within the cluster, you must configure a BGP session from a single router (the route reflector) to each internal peer. With this configuration, the IBGP full-mesh requirement is met.
To use route reflection in an AS, you designate one or more routers as a route reflector—typically, one per point of presence (POP). Route reflectors have the special BGP ability to readvertise routes learned from an internal peer to other internal peers. So rather than requiring all internal peers to be fully meshed with each other, route reflection requires only that the route reflector be fully meshed with all internal peers. The route reflector and all of its internal peers form a cluster, as shown in Figure 1.
For some Juniper Networks devices, you must have an Advanced BGP Feature license installed on each device that uses a route reflector. For license details, see the Software Installation and Upgrade Guide.
Figure 1 shows Router RR configured as the route reflector for Cluster 127. The other routers are designated internal peers within the cluster. BGP routes are advertised to Router RR by any of the internal peers. RR then readvertises those routes to all other peers within the cluster.
You can configure multiple clusters and link them by configuring a full mesh of route reflectors (see Figure 2).
Figure 2 shows Route Reflectors RR 1, RR 2, RR 3, and RR 4 as fully meshed internal peers. When a router advertises a route to RR 1, RR 1 readvertises the route to the other route reflectors, which, in turn, readvertise the route to the remaining routers within the AS. Route reflection allows the route to be propagated throughout the AS without the scaling problems created by the full mesh requirement.
A route reflector that supports multiple clusters does not accept a route with the same cluster ID from a non-client router. Therefore, you must configure a different cluster ID for a redundant RR to reflect the route to other clusters.
However, as clusters become large, a full mesh with a route reflector becomes difficult to scale, as does a full mesh between route reflectors. To help offset this problem, you can group clusters of routers together into clusters of clusters for hierarchical route reflection (see Figure 3).
Figure 3 shows RR 2, RR 3, and RR 4 as the route reflectors for Clusters 127, 19, and 45, respectively. Rather than fully mesh those route reflectors, the network administrator has configured them as part of another cluster (Cluster 6) for which RR 1 is the route reflector. When a router advertises a route to RR 2, RR 2 readvertises the route to all the routers within its own cluster, and then readvertises the route to RR 1. RR 1 readvertises the route to the routers in its cluster, and those routers propagate the route down through their clusters.
See Also
Example: Configuring a Route Reflector
This example shows how to configure a route reflector.
Requirements
No special configuration beyond device initialization is required before you configure this example.
Overview
Generally, internal BGP (IBGP)-enabled devices need to be fully
meshed, because IBGP does not readvertise updates to other IBGP-enabled
devices. The full mesh is a logical mesh achieved through configuration
of multiple neighbor statements on each IBGP-enabled device.
The full mesh is not necessarily a physical full mesh. Maintaining
a full mesh (logical or physical) does not scale well in large deployments.
Figure 4 shows an IBGP network with Device A acting as a route reflector. Device B and Device C are clients of the route reflector. Device D and Device E are outside the cluster, so they are nonclients of the route reflector.
On Device A (the route reflector), you must form peer relationships
with all of the IBGP-enabled devices by including the neighbor statement for the clients (Device B and Device C) and
the nonclients (Device D and Device E). You must also include
the cluster statement and a cluster identifier. The cluster
identifier can be any 32-bit value. This example uses the loopback
interface IP address of the route reflector.
On Device B and Device C, the route reflector clients, you only
need one neighbor statement that forms a peer relationship
with the route reflector, Device A.
On Device D and Device E, the nonclients, you need a neighbor statement for each nonclient device (D-to-E and E-to-D). You also
need a neighbor statement for the route reflector (D-to-A
and E-to-A). Device D and Device E do not need neighbor statements for the client devices (Device B and Device C).
Device D and Device E are considered to be nonclients because
they have explicitly configured peer relationships with each other.
To make them RRroute reflector clients, remove the neighbor 192.168.5.5 statement from the configuration on Device D, and remove the neighbor 192.168.0.1 statement from the configuration on Device
E.
Configuration
Procedure
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 A
set interfaces fe-0/0/0 unit 1 description to-B set interfaces fe-0/0/0 unit 1 family inet address 10.10.10.1/30 set interfaces fe-0/0/1 unit 3 description to-D set interfaces fe-0/0/1 unit 3 family inet address 10.10.10.9/30 set interfaces lo0 unit 1 family inet address 192.168.6.5/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.6.5 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers cluster 192.168.6.5 set protocols bgp group internal-peers neighbor 192.163.6.4 set protocols bgp group internal-peers neighbor 192.168.40.4 set protocols bgp group internal-peers neighbor 192.168.0.1 set protocols bgp group internal-peers neighbor 192.168.5.5 set protocols ospf area 0.0.0.0 interface lo0.1 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.1 set protocols ospf area 0.0.0.0 interface fe-0/0/1.3 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.6.5 set routing-options autonomous-system 17
Device B
set interfaces fe-0/0/0 unit 2 description to-A set interfaces fe-0/0/0 unit 2 family inet address 10.10.10.2/30 set interfaces fe-0/0/1 unit 5 description to-C set interfaces fe-0/0/1 unit 5 family inet address 10.10.10.5/30 set interfaces lo0 unit 2 family inet address 192.163.6.4/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.163.6.4 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols ospf area 0.0.0.0 interface lo0.2 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.2 set protocols ospf area 0.0.0.0 interface fe-0/0/1.5 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.163.6.4 set routing-options autonomous-system 17
Device C
set interfaces fe-0/0/0 unit 6 description to-B set interfaces fe-0/0/0 unit 6 family inet address 10.10.10.6/30 set interfaces lo0 unit 3 family inet address 192.168.40.4/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.40.4 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols ospf area 0.0.0.0 interface lo0.3 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.6 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.40.4 set routing-options autonomous-system 17
Device D
set interfaces fe-0/0/0 unit 4 description to-A set interfaces fe-0/0/0 unit 4 family inet address 10.10.10.10/30 set interfaces fe-0/0/1 unit 7 description to-E set interfaces fe-0/0/1 unit 7 family inet address 10.10.10.13/30 set interfaces lo0 unit 4 family inet address 192.168.0.1/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.0.1 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols bgp group internal-peers neighbor 192.168.5.5 set protocols ospf area 0.0.0.0 interface lo0.4 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.4 set protocols ospf area 0.0.0.0 interface fe-0/0/1.7 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.0.1 set routing-options autonomous-system 17
Device E
set interfaces fe-0/0/0 unit 8 description to-D set interfaces fe-0/0/0 unit 8 family inet address 10.10.10.14/30 set interfaces lo0 unit 5 family inet address 192.168.5.5/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.5.5 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.0.1 set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols ospf area 0.0.0.0 interface lo0.5 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.8 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.5.5 set routing-options autonomous-system 17
Step-by-Step Procedure
Configuring the Route Reflector
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 Junos OS CLI User Guide.
To configure IBGP in the network using Juniper Networks Device A as a route reflector:
Configure the interfaces.
[edit interfaces] user@A# set fe-0/0/0 unit 1 description to-B user@A# set fe-0/0/0 unit 1 family inet address 10.10.10.1/30 user@A# set fe-0/0/1 unit 3 description to-D user@A# set fe-0/0/1 unit 3 family inet address 10.10.10.9/30 user@A# set lo0 unit 1 family inet address 192.168.6.5/32
Configure BGP, including the cluster identifier and neighbor relationships with all IBGP-enabled devices in the autonomous system (AS).
Also apply the policy that redistributes OSPF routes into BGP.
[edit protocols bgp group internal-peers] user@A# set type internal user@A# set local-address 192.168.6.5 user@A# set export send-ospf user@A# set cluster 192.168.6.5 user@A# set neighbor192.163.6.4 user@A# set neighbor 192.168.40.4 user@A# set neighbor 192.168.0.1 user@A# set neighbor 192.168.5.5
Configure static routing or an interior gateway protocol (IGP).
This example uses OSPF.
[edit protocols ospf area 0.0.0.0] user@A# set interface lo0.1 passive user@A# set interface fe-0/0/0.1 user@A# set interface fe-0/0/1.3
Configure the policy that redistributes OSPF routes into BGP.
[edit policy-options policy-statement send-ospf term 2] user@A# set from protocol ospf user@A# set then accept
Configure the router ID and the autonomous system (AS) number.
[edit routing-options] user@A# set router-id 192.168.6.5 user@A# set autonomous-system 17
Results
From configuration mode, confirm your configuration
by entering the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration,
repeat the instructions in this example to correct the configuration.
user@A# show interfaces
fe-0/0/0 {
unit 1 {
description to-B;
family inet {
address 10.10.10.1/30;
}
}
}
fe-0/0/1 {
unit 3 {
description to-D;
family inet {
address 10.10.10.9/30;
}
}
}
lo0 {
unit 1 {
family inet {
address 192.168.6.5/32;
}
}
}
user@A# show protocols
bgp {
group internal-peers {
type internal;
local-address 192.168.6.5;
export send-ospf;
cluster 192.168.6.5;
neighbor 192.163.6.4;
neighbor 192.168.40.4;
neighbor 192.168.0.1;
neighbor 192.168.5.5;
}
}
ospf {
area 0.0.0.0 {
interface lo0.1 {
passive;
}
interface fe-0/0/0.1;
interface fe-0/0/1.3;
}
}
user@A# show policy-options
policy-statement send-ospf {
term 2 {
from protocol ospf;
then accept;
}
}
user@A# show routing-options router-id 192.168.6.5; autonomous-system 17;
If you are done configuring the device, enter commit from configuration mode.
Repeat these steps for each nonclient BGP peer within the cluster that you are configuring, if the other nonclient devices are from Juniper Networks. Otherwise, consult the device’s documentation for instructions.
Configuring Client Peers
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 Junos OS CLI User Guide.
To configure client peers:
Configure the interfaces.
[edit interfaces] user@B# set fe-0/0/0 unit 2 description to-A user@B# set fe-0/0/0 unit 2 family inet address 10.10.10.2/30 user@B# set fe-0/0/1 unit 5 description to-C user@B# set fe-0/0/1 unit 5 family inet address 10.10.10.5/30 user@B# set lo0 unit 2 family inet address 192.163.6.4/32
Configure the BGP neighbor relationship with the route reflector.
Also apply the policy that redistributes OSPF routes into BGP.
[edit protocols bgp group internal-peers] user@B# set type internal user@B# set local-address 192.163.6.4 user@B# set export send-ospf user@B# set neighbor 192.168.6.5
Configure OSPF.
[edit protocols ospf area 0.0.0.0] user@B# set interface lo0.2 passive user@B# set interface fe-0/0/0.2 user@B# set interface fe-0/0/1.5
Configure the policy that redistributes OSPF routes into BGP.
[edit policy-options policy-statement send-ospf term 2] user@B# set from protocol ospf user@B# set then accept
Configure the router ID and the AS number.
[edit routing-options] user@B# set router-id 192.163.6.4 user@B# set autonomous-system 17
Results
From configuration mode, confirm your configuration
by entering the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration,
repeat the instructions in this example to correct the configuration.
user@B# show interfaces
fe-0/0/0 {
unit 2 {
description to-A;
family inet {
address 10.10.10.2/30;
}
}
}
fe-0/0/1 {
unit 5 {
description to-C;
family inet {
address 10.10.10.5/30;
}
}
}
lo0 {
unit 2 {
family inet {
address 192.163.6.4/32;
}
}
}
user@B# show protocols
bgp {
group internal-peers {
type internal;
local-address 192.163.6.4;
export send-ospf;
neighbor 192.168.6.5;
}
}
ospf {
area 0.0.0.0 {
interface lo0.2 {
passive;
}
interface fe-0/0/0.2;
interface fe-0/0/1.5;
}
}
user@B# show policy-options
policy-statement send-ospf {
term 2 {
from protocol ospf;
then accept;
}
}
user@B# show routing-options router-id 192.163.6.4; autonomous-system 17;
If you are done configuring the device, enter commit from configuration mode.
Repeat these steps for each client BGP peer within the cluster that you are configuring if the other client devices are from Juniper Networks. Otherwise, consult the device’s documentation for instructions.
Configuring Nonclient Peers
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 Junos OS CLI User Guide.
To configure nonclient peers:
Configure the interfaces.
[edit interfaces] user@D# set fe-0/0/0 unit 4 description to-A user@D# set fe-0/0/0 unit 4 family inet address 10.10.10.10/30 user@D# set fe-0/0/1 unit 7 description to-E user@D# set fe-0/0/1 unit 7 family inet address 10.10.10.13/30 user@D# set lo0 unit 4 family inet address 192.168.0.1/32
Configure the BGP neighbor relationships with the RRroute reflector and with the other nonclient peers.
Also apply the policy that redistributes OSPF routes into BGP.
[edit protocols bgp group internal-peers] user@D# set type internal user@D# set local-address 192.168.0.1 user@D# set export send-ospf user@D# set neighbor 192.168.6.5 user@D# set neighbor 192.168.5.5
Configure OSPF.
[edit protocols ospf area 0.0.0.0] user@D# set interface lo0.4 passive user@D# set interface fe-0/0/0.4 user@D# set interface fe-0/0/1.7
Configure the policy that redistributes OSPF routes into BGP.
[edit policy-options policy-statement send-ospf term 2] user@D# set from protocol ospf user@D# set then accept
Configure the router ID and the AS number.
[edit routing-options] user@D# set router-id 192.168.0.1 user@D# set autonomous-system 17
Results
From configuration mode, confirm your configuration
by entering the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration,
repeat the instructions in this example to correct the configuration.
user@D# show interfaces
fe-0/0/0 {
unit 4 {
description to-A;
family inet {
address 10.10.10.10/30;
}
}
}
fe-0/0/1 {
unit 7 {
description to-E;
family inet {
address 10.10.10.13/30;
}
}
}
lo0 {
unit 4 {
family inet {
address 192.168.0.1/32;
}
}
}
user@D# show protocols
bgp {
group internal-peers {
type internal;
local-address 192.168.0.1;
export send-ospf;
neighbor 192.168.6.5;
neighbor 192.168.5.5;
}
}
ospf {
area 0.0.0.0 {
interface lo0.4 {
passive;
}
interface fe-0/0/0.4;
interface fe-0/0/1.7;
}
}
user@D# show policy-options
policy-statement send-ospf {
term 2 {
from protocol ospf;
then accept;
}
}
user@D# show routing-options router-id 192.168.0.1; autonomous-system 17;
If you are done configuring the device, enter commit from configuration mode.
Repeat these steps for each nonclient BGP peer within the cluster that you are configuring if the other nonclient devices are from Juniper Networks. Otherwise, consult the device’s documentation for instructions.
Verification
Confirm that the configuration is working properly.
- Verifying BGP Neighbors
- Verifying BGP Groups
- Verifying BGP Summary Information
- Verifying Routing Table Information
Verifying BGP Neighbors
Purpose
Verify that BGP is running on configured interfaces and that the BGP session is established for each neighbor address.
Action
From operational mode, enter the show bgp neighbor command.
user@A> show bgp neighbor
Peer: 192.163.6.4+179 AS 17 Local: 192.168.6.5+62857 AS 17
Type: Internal State: Established (route reflector client)Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-ospf ]
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.163.6.4 Local ID: 192.168.6.5 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 0
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 17)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 6
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 5 Sent 3 Checked 19
Input messages: Total 2961 Updates 7 Refreshes 0 Octets 56480
Output messages: Total 2945 Updates 6 Refreshes 0 Octets 56235
Output Queue[0]: 0
Peer: 192.168.0.1+179 AS 17 Local: 192.168.6.5+60068 AS 17
Type: Internal State: Established (route reflector client)Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-ospf ]
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.0.1 Local ID: 192.168.6.5 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 3
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 17)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 6
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 18 Sent 20 Checked 12
Input messages: Total 15 Updates 5 Refreshes 0 Octets 447
Output messages: Total 554 Updates 4 Refreshes 0 Octets 32307
Output Queue[0]: 0
Peer: 192.168.5.5+57458 AS 17 Local: 192.168.6.5+179 AS 17
Type: Internal State: Established (route reflector client)Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-ospf ]
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.5.5 Local ID: 192.168.6.5 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 2
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 17)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 7
Accepted prefixes: 7
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 17 Sent 3 Checked 9
Input messages: Total 2967 Updates 7 Refreshes 0 Octets 56629
Output messages: Total 2943 Updates 6 Refreshes 0 Octets 56197
Output Queue[0]: 0
Peer: 192.168.40.4+53990 AS 17 Local: 192.168.6.5+179 AS 17
Type: Internal State: Established (route reflector client)Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-ospf ]
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.40.4 Local ID: 192.168.6.5 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 1
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 17)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 7
Accepted prefixes: 7
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 5 Sent 23 Checked 52
Input messages: Total 2960 Updates 7 Refreshes 0 Octets 56496
Output messages: Total 2943 Updates 6 Refreshes 0 Octets 56197
Output Queue[0]: 0Verifying BGP Groups
Purpose
Verify that the BGP groups are configured correctly.
Action
From operational mode, enter the show bgp group command.
user@A> show bgp group Group Type: Internal AS: 17 Local AS: 17 Name: internal-peers Index: 0 Flags: <> Export: [ send-ospf ] Options: <Cluster> Holdtime: 0 Total peers: 4 Established: 4 192.163.6.4+179 192.168.40.4+53990 192.168.0.1+179 192.168.5.5+57458 inet.0: 0/26/16/0 Groups: 1 Peers: 4 External: 0 Internal: 4 Down peers: 0 Flaps: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 26 0 0 0 0 0
Verifying BGP Summary Information
Purpose
Verify that the BGP configuration is correct.
Action
From operational mode, enter the show bgp summary command.
user@A> show bgp summary Groups: 1 Peers: 4 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 26 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 192.163.6.4 17 2981 2965 0 0 22:19:15 0/6/1/0 0/0/0/0 192.168.0.1 17 36 575 0 0 13:43 0/6/1/0 0/0/0/0 192.168.5.5 17 2988 2964 0 0 22:19:10 0/7/7/0 0/0/0/0 192.168.40.4 17 2980 2964 0 0 22:19:14 0/7/7/0 0/0/0/0
Verifying Routing Table Information
Purpose
Verify that the routing table contains the IBGP routes.
Action
From operational mode, enter the show route command.
user@A> show route
inet.0: 12 destinations, 38 routes (12 active, 0 holddown, 10 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.10.0/30 *[Direct/0] 22:22:03
> via fe-0/0/0.1
[BGP/170] 22:20:55, MED 2, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:51, MED 3, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
10.10.10.1/32 *[Local/0] 22:22:03
Local via fe-0/0/0.1
10.10.10.4/30 *[OSPF/10] 22:21:13, metric 2
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:51, MED 4, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
10.10.10.8/30 *[Direct/0] 22:22:03
> via fe-0/0/1.3
[BGP/170] 22:20:51, MED 2, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 3, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
10.10.10.9/32 *[Local/0] 22:22:03
Local via fe-0/0/1.3
10.10.10.12/30 *[OSPF/10] 22:21:08, metric 2
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 4, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
192.163.6.4/32 *[OSPF/10] 22:21:13, metric 1
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:55, MED 1, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:51, MED 3, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
192.168.0.1/32 *[OSPF/10] 22:21:08, metric 1
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:51, MED 1, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 3, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
192.168.5.5/32 *[OSPF/10] 22:21:08, metric 2
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 00:15:24, MED 1, localpref 100, from 192.168.0.1
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 4, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
192.168.6.5/32 *[Direct/0] 22:22:04
> via lo0.1
[BGP/170] 22:20:51, MED 2, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 2, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
192.168.40.4/32 *[OSPF/10] 22:21:13, metric 2
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:55, MED 1, localpref 100, from 192.163.6.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:51, MED 4, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
224.0.0.5/32 *[OSPF/10] 22:22:07, metric 1
MultiRecvUnderstanding a Route Reflector That Belongs to Two Different Clusters
The purpose of route reflection is loop prevention when the internal BGP (IBGP) routing devices are not fully meshed. To accomplish this, RRs break one of the rules of normal BGP operation: They readvertise routes learned from an internal BGP peer to other internal BGP peers.
Normally, a single RR is a member of only one cluster. Consider, for example, that in a hierarchical RR design, a tier-two RR can be the client of a tier-1 RR, but they can not be clients of each other.
However, when two RRs are clients of each other and the routes are being reflected from one cluster to another, only one of the cluster IDs is included in the cluster list. This is because having one cluster ID in the cluster list is adequate for loop prevention in this case.
Table 1 summarizes the rules that route reflectors use when filling in a reflected route's cluster list with cluster IDs.
Route Reflection Scenario |
Configuration |
|---|---|
When reflecting a route from one of the clients to a non-client router client -> RR -> non-client |
The RR fills the cluster ID associated with that client in the cluster list of the reflected route. |
When reflecting a route from a non-client router to a client router non-client -> RR -> client |
The RR fills the cluster ID associated with that client in the cluster list of the reflected route. |
When reflecting a route from a client router to another client router that is in a different cluster client1 -> RR -> client2 (different cluster) |
The RR fills the cluster ID associated with client1 in the cluster list before reflecting the cluster ID to client2. The cluster ID associated with client 2 is not added. |
When reflecting a route from a client router to a non-client router that is in a different autonomous system. For example, when you have configured a tier 2 RR and 2 BGP groups, one for the RR clients and the other for tier 1 RR, and you are reflecting a route from one autonomous system to another autonomous system. client -> RR -> non-client (different AS) |
The RR does not fill the cluster list with the cluster-ID before reflecting the route to the non-client device because the cluster-ID is specific to one autonomous system. |
See Also
Example: Configuring a Route Reflector That Belongs to Two Different Clusters
This example shows how to configure a route reflector (RR) that belongs to two different clusters. This is not a common scenario, but it might be useful in some situations.
Requirements
Configure the device interfaces and an internal gateway protocol (IGP). For an example of an RR setup that includes the interface and IGP configuration, see Example: Configuring a Route Reflector.
Overview
In this example, Device RR1 is a route reflector for both Device R3 and Device RR2. The route reflector RR1 has two different cluster IDs assigned, one is 10.13.1.3 for RR1-R3 and 10.12.1.2 for RR1-RR2.
Device RR2 is a route reflector for Device R4.
Consider figure Figure 5.
This example shows the BGP configuration on Device RR1 and Device RR2.
Configuration
Procedure
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 RR1
set protocols bgp group RR1_client type internal set protocols bgp group RR1_client local-address 192.168.20.1 set protocols bgp group RR1_client cluster 10.13.1.3 set protocols bgp group RR1_client neighbor 192.168.48.1 set protocols bgp group Non_client type internal set protocols bgp group Non_client local-address 192.168.20.1 set protocols bgp group Non_client neighbor 192.168.16.1 set protocols bgp group RR1_to_RR2 type internal set protocols bgp group RR1_to_RR2 local-address 192.168.20.1 set protocols bgp group RR1_to_RR2 cluster 10.12.1.2 set protocols bgp group RR1_to_RR2 neighbor 192.168.40.1
Device RR2
set protocols bgp group RR2_client type internal set protocols bgp group RR2_client local-address 192.168.40.1 set protocols bgp group RR2_client cluster 10.24.2.4 set protocols bgp group RR2_client neighbor 192.168.32.1 set protocols bgp group RR2_to_RR1 type internal set protocols bgp group RR2_to_RR1 local-address 192.168.40.1 set protocols bgp group RR2_to_RR1 neighbor 192.168.20.1
Configuring Device RR1
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 Junos OS CLI User Guide.
To configure Device RR1:
-
Configure the peering relationship with Device R3.
[edit protocols bgp group RR1_client] user@RR1# set type internal user@RR1# set local-address 192.168.20.1 user@RR1# set cluster 10.13.1.3 user@RR1# set neighbor 192.168.48.1
-
Configure the peering relationship with Device R0.
[edit protocols bgp group Non_client] user@RR1# set type internal user@RR1# set local-address 192.168.20.1 user@RR1# set neighbor 192.168.16.1
-
Configure the peering relationship with Device RR2.
[edit protocols bgp group RR1_to_RR2] user@RR1# set type internal user@RR1# set local-address 192.168.20.1 user@RR1# set cluster 10.12.1.2 user@RR1# set neighbor 192.168.40.1
Results
From configuration mode, confirm your configuration by entering the
show protocols command. If the output does not display
the intended configuration, repeat the instructions in this example to
correct the configuration.
user@RR1# show protocols
bgp {
group RR1_client {
type internal;
local-address 192.168.20.1;
cluster 10.13.1.3;
neighbor 192.168.48.1;
}
group Non_client {
type internal;
local-address 192.168.20.1;
neighbor 192.168.16.1;
}
group RR1_to_RR2 {
type internal;
local-address 192.168.20.1;
cluster 10.12.1.2;
neighbor 192.168.40.1;
}
}
If you are done configuring the device, enter commit from
configuration mode.
Configuring Device RR2
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 Junos OS CLI User Guide.
To configure Device RR2:
-
Configure the peering relationship with Device R4.
[edit protocols bgp group RR2_client] user@RR2# set type internal user@RR2# set local-address 192.168.40.1 user@RR2# set cluster 10.24.2.4 user@RR2# set neighbor 192.168.32.1
-
Configure the peering relationship with Device RR1.
[edit protocols bgp group RR2_to_RR1] user@RR2# set type internal user@RR2# set local-address 192.168.40.1 user@RR2# set neighbor 192.168.20.1
Results
From configuration mode, confirm your configuration by entering the
show protocols command. If the output does not display
the intended configuration, repeat the instructions in this example to
correct the configuration.
user@RR2# show protocols
bgp {
group RR2_client {
type internal;
local-address 192.168.40.1;
cluster 10.24.2.4;
neighbor 192.168.32.1;
}
group RR2_to_RR1 {
type internal;
local-address 192.168.40.1;
neighbor 192.168.20.1;
}
}
If you are done configuring the device, enter commit from
configuration mode.
Verification
Confirm that the configuration is working properly.
- Checking the Cluster ID Advertised for Route 10.3.3.3
- Checking the Cluster ID Advertised for Route 10.1.0.1
Checking the Cluster ID Advertised for Route 10.3.3.3
Purpose
Verify that BGP is running on configured interfaces and that the BGP session is established for each neighbor address.
Action
From operational mode, enter the show route advertising-protocol bgp
neighbor-address command.
user@RR1> show route advertising-protocol bgp 192.168.40.1 active-path 10.3.3.3 extensive
inet.0: 61 destinations, 61 routes (60 active, 0 holddown, 1 hidden)
* 10.3.3.3/32 (1 entry, 1 announced)
BGP group RR1_to_RR2 type Internal
Nexthop: 192.168.48.1
Localpref: 100
AS path: [100] I
Cluster ID: 10.13.1.3
Originator ID: 192.168.48.1
Meaning
The 10.3.3.3/32 route originates from the Device RR1’s client peer, Device R3. When this route is sent to RR1’s client, Device RR2, the route has the 10.13.1.3 cluster ID attached, which is the cluster ID for RR1-R3.
Checking the Cluster ID Advertised for Route 10.1.0.1
Purpose
Check the route advertisement from Device RR1 to Device RR2.
Action
From operational mode, enter the show route
advertising-protocol bgp neighbor-address
command.
user@RR1> show route advertising-protocol bgp 192.168.40.1 active-path 10.1.0.1/32 extensive
inet.0: 61 destinations, 61 routes (60 active, 0 holddown, 1 hidden)
* 10.1.0.1/32 (1 entry, 1 announced)
BGP group RR1_to_RR2 type Internal
Nexthop: 192.168.16.1
Localpref: 100
AS path: [100] I
Cluster ID: 10.12.1.2
Originator ID: 192.168.16.1Meaning
The 10.1.0.1/32 route originates from the Device RR1’s non-client peer, Device R0. When this route is sent to RR1’s client, Device RR2, the route has the 10.12.1.2 cluster ID attached, which is the cluster ID for RR1-RR2.
Device RR1 preserves the inbound cluster ID from Device RR2 when advertising to another client in a different cluster (Device R4).
Understanding BGP Optimal Route Reflection
You can configure BGP Optimal Route Reflection (BGP-ORR) with IS-IS and OSPF as the interior gateway protocol (IGP) on a route reflector to advertise the best path to the BGP-ORR client groups. This is done by using the shortest IGP metric from a client's perspective, instead of the route reflector's view.
Client groups sharing the same or similar IGP topology can be grouped as one BGP peer
group. You can configure optimal-route-reflection to enable BGP-ORR in
that BGP peer group. You can also configure one of the
reflector
nodes as the primary node (igp-primary) in a BGP peer group so that the
IGP metric from that primary node is used to select the best path and advertise it to
the clients in the same BGP peer group. Optionally, you can also select another
reflector
node as the backup node (igp-backup), which is used when the primary
reflector
node (igp-primary) goes down or is unreachable.
To enable BGP-ORR, include the optimal-route-reflection statement at the
[edit protocols bgp group group-name] hierarchy
level.
BGP-ORR only works when IGP is used for BGP route resolution. BGP-ORR does not work when MPLSLDP/RSVP is used for route resolution.
For BGP-ORR to work, the BGP prefix should be resolved through IGP. In normal Layer 3 VPN, or Layer 2 VPN, or VPLS, or MVPN, or EVPN scenarios, the prefixes are resolved over inet.3. In inet.3, the primary route for the protocol-next-hop of the prefix would be either RSVP or LDP ( and not an IGP protocol like IS-IS or OSPF). For BGP-ORR to work, you need to configure the router to use inet.0 for the route-resolution of Layer 3 VPN, or Layer 2 VPN, or VPLS, or MVPN, or EVPN prefixes. You can do this through the following commands:
-
For Layer 3 VPN prefix:
user@host# set routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0
-
For Layer 2 VPN, or VPLS prefix:
user@host# set routing-options resolution rib bgp.l2vpn.0 resolution-ribs inet.0
-
For EVPN prefix:
user@host# set routing-options resolution rib bgp.evpn.0 resolution-ribs inet.0
-
For MVPN prefix:
user@host# set routing-options resolution rib bgp.mvpn.0 resolution-ribs inet.0
Another method is to leak the IGP routes into inet.3 and make them as the primary route in inet.3.
Use the following CLI hierarchy to configure BGP-ORR:
[edit protocols bgp]
group group-name{
optimal-route-reflection {
igp-primary ipv4-address;
igp-backup ipv4-address;
}
}
See Also
Configuring BGP Optimal Route Reflection on a Route Reflector to Advertise the Best Path
You can configure BGP Optimal Route Reflection (BGP-ORR) with IS-IS and OSPF as the interior gateway protocol (IGP) on a route reflector to advertise the best path to the BGP-ORR client groups. This is done by using the shortest IGP metric from a client's perspective, instead of the route reflector's view.
To enable BGP-ORR, include the optimal-route-reflection statement at the [edit protocols bgp group group-name] hierarchy level.
Client groups sharing the same or similar IGP topology can be
grouped as one BGP peer group. You can configure optimal-route-reflection to enable BGP-ORR in that BGP peer group.
To configure BGP-ORR:
Use the following CLI commands to monitor and troubleshoot the configuration for BGP-ORR:
show bgp group—View the primary and backup configurations of BGP-ORR.show isis bgp-orr—View the IS-IS BGP-ORR metric (RIB).show ospf bgp-orr—View the OSPF BGP-ORR metric (RIB).show ospf route—View the entries in the OSPF routing tableshow route—View the active entries in the routing tables.show route advertising protocol bgp peer—Verify whether the routes are being advertised according to the BGP-ORR rules.
See Also
BGP Route Server Overview
A BGP route server is the external BGP (EBGP) equivalent of an internal IBGP (IBGP) route reflector that simplifies the number of direct point-to-point EBGP sessions required in a network. EBGP route servers are transparent in terms of BGP attribute propagation so that a route received from a route server carries the set of BGP attributes (NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP, and Communities) if the route is from a directly connected EBGP peer.
As with an IBGP route reflector, an EBGP route server is attached to a network outside of the direct forwarding path between the EBGP peers using the route server functionality. This connectivity can be through a direct physical link, or through Layer 2 networks such as VPLS LAN or EVPN, or through an IP fabric of point-to-point EBGP links providing reachability of loopback addresses of peers (typical in data center networks).
The BGP protocol is enhanced to provide route-server capability with the following functionalities described in RFC 7947:
Attribute transparency for NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP, and Communities.
Per-client policy control and multiple route-server RIBs for mitigation of path-hiding.
BGP programmability leverages the route-server functionality. The BGP JET bgp_route_service.proto API has been enhanced to support route server functionality as follows:
Program the EBGP route server.
Inject routes to the specific route server RIB for selectively advertising it to the client groups in client-specific RIBs.
The BGP JET bgp_route_service.proto API includes a peer-type object that identifies individual routes as either EBGP or IBGP (default).
Route server functionality is generally address-family independent, although certain specific BGP attribute support may be address-family-specific (for example, AIGP is only supported for labeled-unicast address-families). Route server functionality is supported for all EBGP address families.
- BGP Attribute Transparency
- Next-Hop
- AS-Path
- Other Attributes
- BGP Route Server Client RIB
- Policy Requirements and Considerations
BGP Attribute Transparency
EBGP attribute transparency [RFC7947] for the route server is supported by modifying the normal BGP route propagation such that neither transitive nor non-transitive attributes are stripped or modified while propagating routes.
Changes to normal EBGP behavior are controlled by the route-server-client CLI configuration. The route-server-client CLI configuration
at the [edit protocols bgp group group-name] hierarchy level implements route server BGP attribute transparency
behavior.
The route server provides attribute transparency for both single-hop EBGP and multi-hop configurations. Therefore, the
route-server-clientconfiguration implicitly includes the functionality ofno-nexthop-changefor single-hop and multi-hop sessions. For multi-hop BGP sessions you must configure themultihopkeyword.The
route-server-clientcan be configured at the protocol, group, or neighbor levels of the [edit protocol bgp] hierarchy.The
route-server-clientconfiguration is applicable only when the group type is external. When theroute-server-clientis configured for internal groups, a configuration error is issued when attempting to commit.The
route-server-clientconfiguration has no parameters.Normal BGP privilege applies to the
route-server-clientconfiguration.
Attributes are handled independently with respect to attribute transparency. Even if next-hops cannot be sent unmodified by the route-server, other attributes are sent transparently as applicable for those attributes.
The following is a sample route-server-client configuration:
[edit]
protocols {
bgp {
group R0 {
type external;
route-server-client;
family inet {
unicast;
}
peer-as 100;
neighbor 10.0.0.1;
}
}
}
Next-Hop
The next-hop attribute must not be modified by imposing next-hop self or otherwise modifying the next-hop, unless explicitly configured through a policy. The route server must propagate BGP next-hops according to the third-party next-hop rules of RFC 4271.
Next-hop behavior is specified for the following route-server scenarios:
In the case of LAN and WAN interconnect, when the route server is connected to client peers through a shared LAN and WAN subnet, the received third-party next-hops are advertised by the route server without modification as defined in RFC 4271.
In the case of data center multihop interconnect, when the route server is connected to client peers through a multihop interconnect, EBGP multihop must be configured and the behavior of the
no-nexthop-changeCLI configuration is implicitly imposed by theroute-server-clientconfiguration. The received third-party next-hops are advertised by the route server without modification, as per the optional third-party behavior defined in RFC 4271.In other cases, such as point-to-point single-hop connections between the route server and client peers, normal next-hop advertisement procedures are used to prevent advertising next-hops that could be rejected by BGP peers (for example, most BGP implementations, by default, rejects next-hops addresses that are not covered by the subnet address on non-multipoint sessions.
AS-Path
AS-Path must not be modified by prepending the route server’s
local AS number. Configuring route-server-client CLI for
a peer suppresses the prepending of the local AS number in the advertisements.
In addition, the show route advertising-protocol bgp peer CLI command is changed for peers that are route
server clients such that the local AS is not shown in the advertised
metrics.
Other Attributes
MULTI_EXIT_DISC attribute (optional, non-transitive) must be propagated as received.
All community attributes, including no-advertise, no-export, and non-transitive extended communities, must be propagated as received.
Accumulated IGP (AIGP) attribute (optional, non-transitive) must be propagated as received.
Note:Junos OS supports AIGP only for BGP-LU address families (IPv4 and IPv6).
BGP Route Server Client RIB
A route server client-specific RIB is a distinct view of a BGP Loc-RIB which can contain different routes for the same destination than other views. Route server clients, through their peer groups, may associate with one individual client-specific view or a shared common RIB.
In order to provide the ability to advertise different routes to different clients for the same destination, it is conceptually necessary to allow for multiple instances of the BGP path selection to occur for the same destination but in different client/group contexts.
To implement the high-level requirement of flexible policy control with per-client/group path selection, BGP route server takes the approach of using non-forwarding routing instances (NFIs) to multi-instance the BGP pipeline, including BGP path selection, Loc-RIB, and policy. The route server is configured to group route server clients within BGP groups configured within separate non-forwarding routing instances. This approach leverages the fact that BGP running within a routing instance does path selection and has a RIB that is separate from BGP running in other routing instances.
Policy Requirements and Considerations
To propagate routes between route server clients, routes are leaked between the RIBs of the routing instances based on configured policies.
Configuration of the route server for policy control includes the following considerations:
Route server clients should be configured within the same primary instance or routing-instance to receive the same Loc-RIB view.
Route server clients should be configured within their own routing-instance to receive totally unique Loc-RIB views.
Route server clients should be configured in different BGP peer groups in the same routing-instance to have different export policy on the same Loc-RIB view.
For the route server client-specific RIB views to receive all routes from other tables by default, a full-mesh of
instance-importpolicies is configured withinstance-any. When configuringinstance-importwith policy containinginstance-any:instance-anycan be used in:policy-statement ... term ... frompolicy-statement ... frompolicy-statement ... term ... topolicy-statement ... to
instance-anyhas no parameters.Using
instance-anyin policies other thaninstance-importdoes not have any effect.
Configuring many distinct routing-instances and peer-groups impacts scale and performance.
The BGP
forwarding-contextCLI configuration at the [edit protocols bgp group neighbor] hierarchy level splits the routing instance for a BGP neighbor into a configuration instance and a forwarding instance. The BGPforwarding-contextCLI configuration also supports non-forwarding instance with BGP peers configured asroute-server-clientwhere the specified instance is any instance capable of forwarding a primary or a routing-instance that is not of type no-forwarding.
See Also
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.
no-install statement eliminates interaction between the routing protocols daemon
(rpd) and other components in the Junos system such as the kernel
or the distributed firewall daemon (dfwd).