BGP Peering Sessions
Understanding External BGP Peering Sessions
To establish point-to-point connections between peer autonomous systems (ASs), you configure a BGP session on each interface of a point-to-point link. Generally, such sessions are made at network exit points with neighboring hosts outside the AS. Figure 1 shows an example of a BGP peering session.

In Figure 1, Router A is a gateway router for AS 3, and Router B is a gateway router for AS 10. For traffic internal to either AS, an interior gateway protocol (IGP) is used (OSPF, for instance). To route traffic between peer ASs, a BGP session is used.
You arrange BGP routing devices into groups of peers. Different peer groups can have different group types, AS numbers, and route reflector cluster identifiers.
To define a BGP group that recognizes only the specified BGP systems as peers, statically configure all the system’s peers by including one or more neighbor statements. The peer neighbor’s address can be either an IPv6 or IPv4 address.
As the number of external BGP (EBGP) groups increases, the ability to support a large number of BGP sessions might become a scaling issue. The preferred way to configure a large number of BGP neighbors is to configure a few groups consisting of multiple neighbors per group. Supporting fewer EBGP groups generally scales better than supporting a large number of EBGP groups. This becomes more evident in the case of hundreds of EBGP groups when compared with a few EBGP groups with multiple peers in each group.
After the BGP peers are established, non-BGP routes are not automatically advertised by the BGP peers. At each BGP-enabled device, policy configuration is required to export the local, static, or IGP-learned routes into the BGP RIB and then advertise them as BGP routes to the other peers. BGP's advertisement policy, by default, does not advertise any non-BGP routes (such as local routes) to peers.
See also
Example: Configuring External BGP Point-to-Point Peer Sessions
This example shows how to configure BGP point-to-point peer sessions.
Requirements
Before you begin, if the default BGP policy is not adequate for your network, configure routing policies to filter incoming BGP routes and to advertise BGP routes.
Overview
Figure 2 shows a network with BGP peer sessions. In the sample network, Device E in AS 17 has BGP peer sessions to a group of peers called external-peers. Peers A, B, and C reside in AS 22 and have IP addresses 10.10.10.2, 10.10.10.6, and 10.10.10.10. Peer D resides in AS 79, at IP address 10.21.7.2. This example shows the configuration on Device E.

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.
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 the BGP peer sessions:
- Configure the interfaces to Peers A, B, C, and D.[edit interfaces]user@E# set ge-1/2/0 unit 0 description to-Auser@E# set ge-1/2/0 unit 0 family inet address 10.10.10.1/30user@E# set ge-0/0/1 unit 5 description to-Buser@E# set ge-0/0/1 unit 5 family inet address 10.10.10.5/30user@E# set ge-0/1/0 unit 9 description to-Cuser@E# set ge-0/1/0 unit 9 family inet address 10.10.10.9/30user@E# set ge-1/2/1 unit 21 description to-Duser@E# set ge-1/2/1 unit 21 family inet address 10.21.7.1/30
- Set the autonomous system (AS) number.[edit routing-options]user@E# set autonomous-system 17
- Create the BGP group, and add the external neighbor addresses.[edit protocols bgp group external-peers]user@E# set neighbor 10.10.10.2user@E# set neighbor 10.10.10.6user@E# set neighbor 10.10.10.10
- Specify the autonomous system (AS) number of the external
AS.[edit protocols bgp group external-peers]user@E# set peer-as 22
- Add Peer D, and set the AS number at the individual neighbor
level.
The neighbor configuration overrides the group configuration. So, while peer-as 22 is set for all the other neighbors in the group, peer-as 79 is set for neighbor 10.21.7.2.
[edit protocols bgp group external-peers]user@E# set neighbor 10.21.7.2 peer-as 79 - Set the peer type to external BGP (EBGP).[edit protocols bgp group external-peers]user@E# set type external
Results
From configuration mode, confirm your configuration by entering the show interfaces, 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.
Verification
Confirm that the configuration is working properly.
Verifying BGP Neighbors
Purpose
Verify that BGP is running on configured interfaces and that the BGP session is active for each neighbor address.
Action
From operational mode, run the show bgp neighbor command.
user@E> show bgp neighbor
Peer: 10.10.10.2+179 AS 22 Local: 10.10.10.1+65406 AS 17 Type: External State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Options: <Preference PeerAS Refresh> Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 10.10.10.2 Local ID: 10.10.10.1 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 BFD: disabled, down Local Interface: ge-1/2/0.0 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 22) 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: 0 Accepted prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 0 Last traffic (seconds): Received 10 Sent 6 Checked 1 Input messages: Total 8522 Updates 1 Refreshes 0 Octets 161922 Output messages: Total 8433 Updates 0 Refreshes 0 Octets 160290 Output Queue[0]: 0 Peer: 10.10.10.6+54781 AS 22 Local: 10.10.10.5+179 AS 17 Type: External State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Options: <Preference PeerAS Refresh> Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 10.10.10.6 Local ID: 10.10.10.1 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 1 BFD: disabled, down Local Interface: ge-0/0/1.5 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 22) 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: 0 Accepted prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 0 Last traffic (seconds): Received 12 Sent 6 Checked 33 Input messages: Total 8527 Updates 1 Refreshes 0 Octets 162057 Output messages: Total 8430 Updates 0 Refreshes 0 Octets 160233 Output Queue[0]: 0 Peer: 10.10.10.10+55012 AS 22 Local: 10.10.10.9+179 AS 17 Type: External State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Options: <Preference PeerAS Refresh> Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 10.10.10.10 Local ID: 10.10.10.1 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 2 BFD: disabled, down Local Interface: fe-0/1/0.9 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 22) 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: 0 Accepted prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 0 Last traffic (seconds): Received 15 Sent 6 Checked 37 Input messages: Total 8527 Updates 1 Refreshes 0 Octets 162057 Output messages: Total 8429 Updates 0 Refreshes 0 Octets 160214 Output Queue[0]: 0 Peer: 10.21.7.2+61867 AS 79 Local: 10.21.7.1+179 AS 17 Type: External State: Established Flags: <ImportEval Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Options: <Preference PeerAS Refresh> Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 10.21.7.2 Local ID: 10.10.10.1 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 3 BFD: disabled, down Local Interface: ge-1/2/1.21 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 79) 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: 0 Accepted prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 0 Last traffic (seconds): Received 28 Sent 24 Checked 47 Input messages: Total 8521 Updates 1 Refreshes 0 Octets 161943 Output messages: Total 8427 Updates 0 Refreshes 0 Octets 160176 Output Queue[0]: 0
Verifying BGP Groups
Purpose
Verify that the BGP groups are configured correctly.
Action
From operational mode, run the show bgp group command.
user@E> show bgp group
Group Type: External Local AS: 17 Name: external-peers Index: 0 Flags: <> Holdtime: 0 Total peers: 4 Established: 4 10.10.10.2+179 10.10.10.6+54781 10.10.10.10+55012 10.21.7.2+61867 inet.0: 0/0/0/0 Groups: 1 Peers: 4 External: 4 Internal: 0 Down peers: 0 Flaps: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 0 0 0 0 0 0
Verifying BGP Summary Information
Purpose
Verify that the BGP configuration is correct.
Action
From operational mode, run the show bgp summary command.
user@E> show bgp summary
Groups: 1 Peers: 4 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 10.10.10.2 22 8559 8470 0 0 2d 16:12:56 0/0/0/0 0/0/0/0 10.10.10.6 22 8566 8468 0 0 2d 16:12:12 0/0/0/0 0/0/0/0 10.10.10.10 22 8565 8466 0 0 2d 16:11:31 0/0/0/0 0/0/0/0 10.21.7.2 79 8560 8465 0 0 2d 16:10:58 0/0/0/0 0/0/0/0
See also
Example: Configuring External BGP on Logical Systems with IPv6 Interfaces
This example shows how to configure external BGP (EBGP) point-to-point peer sessions on logical systems with IPv6 interfaces.
Requirements
In this example, no special configuration beyond device initialization is required.
Overview
Junos OS supports EBGP peer sessions by means of IPv6 addresses. An IPv6 peer session can be configured when an IPv6 address is specified in the neighbor statement. This example uses EUI-64 to generate IPv6 addresses that are automatically applied to the interfaces. An EUI-64 address is an IPv6 address that uses the IEEE EUI-64 format for the interface identifier portion of the address (the last 64 bits).
Alternatively, you can configure EBGP sessions using manually assigned 128-bit IPv6 addresses.
If you use 128-bit link-local addresses for the interfaces, you must include the local-interface statement. This statement is valid only for 128-bit IPv6 link-local addresses and is mandatory for configuring an IPv6 EBGP link-local peer session.
Configuring EBGP peering using link-local addresses is only applicable for directly connected interfaces. There is no support for multihop peering.
After your interfaces are up, you can use the show interfaces terse command to view the EUI-64-generated IPv6 addresses on the interfaces. You must use these generated addresses in the BGP neighbor statements. This example demonstrates the full end-to-end procedure.
In this example, Frame Relay interface encapsulation is applied to the logical tunnel (lt) interfaces. This is a requirement because only Frame Relay encapsulation is supported when IPv6 addresses are configured on the lt interfaces.
Figure 3 shows a network with BGP peer sessions. In the sample network, Router R1 has five logical systems configured. Device E in autonomous system (AS) 17 has BGP peer sessions to a group of peers called external-peers. Peers A, B, and C reside in AS 22. This example shows the step-by-step configuration on Logical System A and Logical System E.

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.
Device A
Device B
Device C
Device D
Device E
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 the BGP peer sessions:
- Run the show interfaces terse command to verify
that the physical router has a logical tunnel (lt) interface.
user@R1> show interfaces terse
Interface Admin Link Proto Local Remote ... lt-0/1/0 up up ...
- On Logical System A, configure the interface encapsulation,
peer-unit number, and DLCI to reach Logical System E.user@R1> set cli logical-system ALogical system: A[edit]user@R1:A> editEntering configuration mode[edit]user@R1:A# edit interfaces[edit interfaces]user@R1:A# set lt-0/1/0 unit 1 encapsulation frame-relayuser@R1:A# set lt-0/1/0 unit 1 dlci 1user@R1:A# set lt-0/1/0 unit 1 peer-unit 25
- On Logical System A, configure the network address for the link
to Peer E, and configure a loopback interface.[edit interfaces]user@R1:A# set lt-0/1/0 unit 1 description to-Euser@R1:A# set lt-0/1/0 unit 1 family inet6 address 2001:db8:0:1::/64 eui-64user@R1:A# set lo0 unit 1 family inet6 address 2001:db8::1/128
- On Logical System E, configure the interface encapsulation,
peer-unit number, and DLCI to reach Logical System A.user@R1> set cli logical-system ELogical system: E[edit]user@R1:E> editEntering configuration mode[edit]user@R1:E# edit interfaces[edit interfaces]user@R1:E# set lt-0/1/0 unit 25 encapsulation frame-relayuser@R1:E# set lt-0/1/0 unit 25 dlci 1user@R1:E# set lt-0/1/0 unit 25 peer-unit 1
- On Logical System E, configure the network address for the link
to Peer A, and configure a loopback interface.[edit interfaces]user@R1:E# set lt-0/1/0 unit 25 description to-Auser@R1:E# set lt-0/1/0 unit 25 family inet6 address 2001:db8:0:1::/64 eui-64user@R1:E# set lo0 unit 5 family inet6 address 2001:db8::5/128
- Run the show interfaces terse command to see
the IPv6 addresses that are generated by EUI-64.
The 2001 addresses are used in this example in the BGP neighbor statements.
Note The fe80 addresses are link-local addresses and are not used in this example.
user@R1:A> show interfaces terse
Interface Admin Link Proto Local Remote Logical system: A betsy@tp8:A> show interfaces terse Interface Admin Link Proto Local Remote lt-0/1/0 lt-0/1/0.1 up up inet6 2001:db8:0:1:2a0:a502:0:1da/64 fe80::2a0:a502:0:1da/64 lo0 lo0.1 up up inet6 2001:db8::1 fe80::2a0:a50f:fc56:1da
user@R1:E> show interfaces terse
Interface Admin Link Proto Local Remote lt-0/1/0 lt-0/1/0.25 up up inet6 2001:db8:0:1:2a0:a502:0:19da/64 fe80::2a0:a502:0:19da/64 lo0 lo0.5 up up inet6 2001:db8::5 fe80::2a0:a50f:fc56:1da
- Repeat the interface configuration on the other logical systems.
Configuring the External BGP Sessions
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 the BGP peer sessions:
- On Logical System A, create the BGP group, and add the
external neighbor address.[edit protocols bgp group external-peers]user@R1:A# set neighbor 2001:db8:0:1:2a0:a502:0:19da
- On Logical System E, create the BGP group, and add the
external neighbor address.[edit protocols bgp group external-peers]user@R1:E# set neighbor 2001:db8:0:1:2a0:a502:0:1da
- On Logical System A, specify the autonomous system (AS)
number of the external AS.[edit protocols bgp group external-peers]user@R1:A# set peer-as 17
- On Logical System E, specify the autonomous system (AS)
number of the external AS.[edit protocols bgp group external-peers]user@R1:E# set peer-as 22
- On Logical System A, set the peer type to EBGP.[edit protocols bgp group external-peers]user@R1:A# set type external
- On Logical System E, set the peer type to EBGP.[edit protocols bgp group external-peers]user@R1:E# set type external
- On Logical System A, set the autonomous system (AS) number
and router ID.[edit routing-options]user@R1:A# set router-id 172.16.1.1user@R1:A# set autonomous-system 22
- On Logical System E, set the AS number and router ID.[edit routing-options]user@R1:E# set router-id 172.16.5.5user@R1:E# set autonomous-system 17
- Repeat these steps for Peers A, B, C, and D.
Results
From configuration mode, confirm your configuration by entering the show logical-systems command. 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.
Verification
Confirm that the configuration is working properly.
Verifying BGP Neighbors
Purpose
Verify that BGP is running on configured interfaces and that the BGP session is active for each neighbor address.
Action
From operational mode, run the show bgp neighbor command.
user@R1:E> show bgp neighbor
Peer: 2001:db8:0:1:2a0:a502:0:1da+54987 AS 22 Local: 2001:db8:0:1:2a0:a502:0:19da+179 AS 17 Type: External State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: Open Message Error Options: <Preference PeerAS Refresh> Holdtime: 90 Preference: 170 Number of flaps: 0 Error: 'Open Message Error' Sent: 20 Recv: 0 Peer ID: 172.16.1.1 Local ID: 172.16.5.5 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 BFD: disabled, down Local Interface: lt-0/1/0.25 NLRI for restart configured on peer: inet6-unicast NLRI advertised by peer: inet6-unicast NLRI for this session: 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: inet6-unicast NLRI of received end-of-rib markers: inet6-unicast NLRI of all end-of-rib markers sent: inet6-unicast Peer supports 4 byte AS extension (peer-as 22) Peer does not support Addpath Table inet6.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 0 Accepted prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 0 Last traffic (seconds): Received 7 Sent 18 Checked 81 Input messages: Total 1611 Updates 1 Refreshes 0 Octets 30660 Output messages: Total 1594 Updates 0 Refreshes 0 Octets 30356 Output Queue[0]: 0 Peer: 2001:db8:0:2:2a0:a502:0:6da+179 AS 22 Local: 2001:db8:0:2:2a0:a502:0:5da+55502 AS 17 Type: External State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: Open Message Error Options: <Preference PeerAS Refresh> Holdtime: 90 Preference: 170 Number of flaps: 0 Error: 'Open Message Error' Sent: 26 Recv: 0 Peer ID: 172.16.2.2 Local ID: 172.16.5.5 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 2 BFD: disabled, down Local Interface: lt-0/1/0.5 NLRI for restart configured on peer: inet6-unicast NLRI advertised by peer: inet6-unicast NLRI for this session: 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: inet6-unicast NLRI of received end-of-rib markers: inet6-unicast NLRI of all end-of-rib markers sent: inet6-unicast Peer supports 4 byte AS extension (peer-as 22) Peer does not support Addpath Table inet6.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 0 Accepted prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 0 Last traffic (seconds): Received 15 Sent 8 Checked 8 Input messages: Total 1610 Updates 1 Refreshes 0 Octets 30601 Output messages: Total 1645 Updates 0 Refreshes 0 Octets 32417 Output Queue[0]: 0 Peer: 2001:db8:0:3:2a0:a502:0:ada+55983 AS 22 Local: 2001:db8:0:3:2a0:a502:0:9da+179 AS 17 Type: External State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Options: <Preference PeerAS Refresh> Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 172.16.3.3 Local ID: 172.16.5.5 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 3 BFD: disabled, down Local Interface: lt-0/1/0.9 NLRI for restart configured on peer: inet6-unicast NLRI advertised by peer: inet6-unicast NLRI for this session: 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: inet6-unicast NLRI of received end-of-rib markers: inet6-unicast NLRI of all end-of-rib markers sent: inet6-unicast Peer supports 4 byte AS extension (peer-as 22) Peer does not support Addpath Table inet6.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 0 Accepted prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 0 Last traffic (seconds): Received 21 Sent 21 Checked 67 Input messages: Total 1610 Updates 1 Refreshes 0 Octets 30641 Output messages: Total 1587 Updates 0 Refreshes 0 Octets 30223 Output Queue[0]: 0 Peer: 2001:db8:0:4:2a0:a502:0:7da+49255 AS 79 Local: 2001:db8:0:4:2a0:a502:0:15da+179 AS 17 Type: External State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Options: <Preference PeerAS Refresh> Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 172.16.4.4 Local ID: 172.16.5.5 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 1 BFD: disabled, down Local Interface: lt-0/1/0.21 NLRI for restart configured on peer: inet6-unicast NLRI advertised by peer: inet6-unicast NLRI for this session: 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: inet6-unicast NLRI of received end-of-rib markers: inet6-unicast NLRI of all end-of-rib markers sent: inet6-unicast Peer supports 4 byte AS extension (peer-as 79) Peer does not support Addpath Table inet6.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 0 Accepted prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 0 Last traffic (seconds): Received 6 Sent 17 Checked 25 Input messages: Total 1615 Updates 1 Refreshes 0 Octets 30736 Output messages: Total 1593 Updates 0 Refreshes 0 Octets 30337 Output Queue[0]: 0
Meaning
IPv6 unicast network layer reachability information (NLRI) is being exchanged between the neighbors.
Verifying BGP Groups
Purpose
Verify that the BGP groups are configured correctly.
Action
From operational mode, run the show bgp group command.
user@R1:E> show bgp group
Group Type: External Local AS: 17 Name: external-peers Index: 0 Flags: <> Holdtime: 0 Total peers: 4 Established: 4 2001:db8:0:1:2a0:a502:0:1da+54987 2001:db8:0:2:2a0:a502:0:6da+179 2001:db8:0:3:2a0:a502:0:ada+55983 2001:db8:0:4:2a0:a502:0:7da+49255 inet6.0: 0/0/0/0 Groups: 1 Peers: 4 External: 4 Internal: 0 Down peers: 0 Flaps: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet6.0 0 0 0 0 0 0 inet6.2 0 0 0 0 0 0
Meaning
The group type is external, and the group has four peers.
Verifying BGP Summary Information
Purpose
Verify that the BGP peer relationships are established.
Action
From operational mode, run the show bgp summary command.
user@R1:E> show bgp summary
Groups: 1 Peers: 4 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet6.0 0 0 0 0 0 0 inet6.2 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 2001:db8:0:1:2a0:a502:0:1da 22 1617 1600 0 0 12:07:00 Establ inet6.0: 0/0/0/0 2001:db8:0:2:2a0:a502:0:6da 22 1616 1651 0 0 12:06:56 Establ inet6.0: 0/0/0/0 2001:db8:0:3:2a0:a502:0:ada 22 1617 1594 0 0 12:04:32 Establ inet6.0: 0/0/0/0 2001:db8:0:4:2a0:a502:0:7da 79 1621 1599 0 0 12:07:00 Establ inet6.0: 0/0/0/0
Meaning
The Down peers: 0 output shows that the BGP peers are in the established state.
Checking the Routing Table
Purpose
Verify that the inet6.0 routing table is populated with local and direct routes.
Action
From operational mode, run the show route command.
user@R1:E> show route
inet6.0: 15 destinations, 18 routes (15 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 2001:db8::5/128 *[Direct/0] 12:41:18 > via lo0.5 2001:db8:0:1::/64 *[Direct/0] 14:40:01 > via lt-0/1/0.25 2001:db8:0:1:2a0:a502:0:19da/128 *[Local/0] 14:40:01 Local via lt-0/1/0.25 2001:db8:0:2::/64 *[Direct/0] 14:40:02 > via lt-0/1/0.5 2001:db8:0:2:2a0:a502:0:5da/128 *[Local/0] 14:40:02 Local via lt-0/1/0.5 2001:db8:0:3::/64 *[Direct/0] 14:40:02 > via lt-0/1/0.9 2001:db8:0:3:2a0:a502:0:9da/128 *[Local/0] 14:40:02 Local via lt-0/1/0.9 2001:db8:0:4::/64 *[Direct/0] 14:40:01 > via lt-0/1/0.21 2001:db8:0:4:2a0:a502:0:15da/128 *[Local/0] 14:40:01 Local via lt-0/1/0.21 fe80::/64 *[Direct/0] 14:40:02 > via lt-0/1/0.5 [Direct/0] 14:40:02 > via lt-0/1/0.9 [Direct/0] 14:40:01 > via lt-0/1/0.21 [Direct/0] 14:40:01 > via lt-0/1/0.25 fe80::2a0:a502:0:5da/128 *[Local/0] 14:40:02 Local via lt-0/1/0.5 fe80::2a0:a502:0:9da/128 *[Local/0] 14:40:02 Local via lt-0/1/0.9 fe80::2a0:a502:0:15da/128 *[Local/0] 14:40:01 Local via lt-0/1/0.21 fe80::2a0:a502:0:19da/128 *[Local/0] 14:40:01 Local via lt-0/1/0.25 fe80::2a0:a50f:fc56:1da/128 *[Direct/0] 12:41:18 > via lo0.5
Meaning
The inet6.0 routing table contains local and direct routes. To populate the routing table with other types of routes, you must configure routing policies.
Understanding Internal BGP Peering Sessions
When two BGP-enabled devices are in the same autonomous system (AS), the BGP session is called an internal BGP session, or IBGP session. BGP uses the same message types on IBGP and external BGP (EBGP) sessions, but the rules for when to send each message and how to interpret each message differ slightly. For this reason, some people refer to IBGP and EBGP as two separate protocols.

In Figure 4, Device Jackson, Device Memphis, and Device Biloxi have IBGP peer sessions with each other. Likewise, Device Miami and Device Atlanta have IBGP peer sessions between each other.
The purpose of IBGP is to provide a means by which EBGP route advertisements can be forwarded throughout the network. In theory, to accomplish this task you could redistribute all of your EBGP routes into an interior gateway protocol (IGP), such as OSPF or IS-IS. This, however, is not recommended in a production environment because of the large number of EBGP routes in the Internet and because of the way that IGPs operate. In short, with that many routes the IGP churns or crashes.
Generally, the loopback interface (lo0) is used to establish connections between IBGP peers. The loopback interface is always up as long as the device is operating. If there is a route to the loopback address, the IBGP peering session stays up. If a physical interface address is used instead and that interface goes up and down, the IBGP peering session also goes up and down. Thus the loopback interface provides fault tolerance in case the physical interface or the link goes down, if the device has link redundancy.
While IBGP neighbors do not need to be directly connected, they do need to be fully meshed. In this case, fully meshed means that each device is logically connected to every other device through neighbor peer relationships. The neighbor statement creates the mesh. Because of the full mesh requirement of IBGP, you must configure individual peering sessions between all IBGP devices in the AS. The full mesh need not be physical links. Rather, the configuration on each routing device must create a full mesh of peer sessions (using multiple neighbor statements).
The requirement for a full mesh is waived if you configure a confederation or route reflection.
To understand the full-mesh requirement, consider that an IBGP-learned route cannot be readvertised to another IBGP peer. The reason for preventing the readvertisement of IBGP routes and requiring the full mesh is to avoid routing loops within an AS. The AS path attribute is the means by which BGP routing devices avoid loops. The path information is examined for the local AS number only when the route is received from an EBGP peer. Because the attribute is only modified across AS boundaries, this system works well. However, the fact that the attribute is only modified across AS boundaries presents an issue inside the AS. For example, suppose that routing devices A, B, and C are all in the same AS. Device A receives a route from an EBGP peer and sends the route to Device B, which installs it as the active route. The route is then sent to Device C, which installs it locally and sends it back to Device A. If Device A installs the route, a loop is formed within the AS. The routing devices are not able to detect the loop because the AS path attribute is not modified during these advertisements. Therefore, the BGP protocol designers decided that the only assurance of never forming a routing loop was to prevent an IBGP peer from advertising an IBGP-learned route within the AS. For route reachability, the IBGP peers are fully meshed.
IBGP supports multihop connections, so IBGP neighbors can be located anywhere within the AS and often do not share a link. A recursive route lookup resolves the loopback peering address to an IP forwarding next hop. The lookup service is provided by static routes or an IGP such as OSPF, or BGP routes.
Example: Configuring Internal BGP Peer Sessions
This example shows how to configure internal BGP peer sessions.
Requirements
No special configuration beyond device initialization is required before you configure this example.
Overview
In this example, you configure internal BGP (IBGP) peer sessions. The loopback interface (lo0) is used to establish connections between IBGP peers. The loopback interface is always up as long as the device is operating. If there is a route to the loopback address, the IBGP peer session stays up. If a physical interface address is used instead and that interface goes up and down, the IBGP peer session also goes up and down. Thus, if the device has link redundancy, the loopback interface provides fault tolerance in case the physical interface or one of the links goes down.
When a device peers with a remote device’s loopback interface address, the local device expects BGP update messages to come from (be sourced by) the remote device’s loopback interface address. The local-address statement enables you to specify the source information in BGP update messages. If you omit the local-address statement, the expected source of BGP update messages is based on the device’s source address selection rules, which normally results in the egress interface address being the expected source of update messages. When this happens, the peer session is not established because a mismatch exists between the expected source address (the egress interface of the peer) and the actual source (the loopback interface of the peer). To make sure that the expected source address matches the actual source address, specify the loopback interface address in the local-address statement.
Because IBGP supports multihop connections, IBGP neighbors can be located anywhere within the autonomous system (AS) and often do not share a link. A recursive route lookup resolves the loopback peer address to an IP forwarding next hop. In this example, this service is provided by OSPF. Although interior gateway protocol (IGP) neighbors do not need to be directly connected, they do need to be fully meshed. In this case, fully meshed means that each device is logically connected to every other device through neighbor peer relationships. The neighbor statement creates the mesh.
The requirement for a full mesh is waived if you configure a confederation or route reflection.
After the BGP peers are established, local routes are not automatically advertised by the BGP peers. At each BGP-enabled device, policy configuration is required to export the local, static, or IGP-learned routes into the BGP routing information base (RIB) and then advertise them as BGP routes to the other peers. BGP's advertisement policy, by default, does not advertise any non-BGP routes (such as local routes) to peers.
In the sample network, the devices in AS 17 are fully meshed in the group internal-peers. The devices have loopback addresses 192.168.6.5, 192.163.6.4, and 192.168.40.4.
Figure 5 shows a typical network with internal peer sessions.

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 A
Device B
Device C
Configuring Device A
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 internal BGP peer sessions on Device A:
- Configure the interfaces.[edit interfaces ge-0/1/0 unit 1]user@A# set description to-Buser@A# set family inet address 10.10.10.1/30[edit interfaces]user@A# set lo0 unit 1 family inet address 192.168.6.5/32
- Configure BGP.
The neighbor statements are included for both Device B and Device C, even though Device A is not directly connected to Device C.
[edit protocols bgp group internal-peers]user@A# set type internaluser@A# set description “connections to B and C”user@A# set local-address 192.168.6.5user@A# set export send-directuser@A# set neighbor 192.163.6.4user@A# set neighbor 192.168.40.4 - Configure OSPF.[edit protocols ospf area 0.0.0.0]user@A# set interface lo0.1 passiveuser@A# set interface ge-0/1/0.1
- Configure a policy that accepts direct routes.
Other useful options for this scenario might be to accept routes learned through OSPF or local routes.
[edit policy-options policy-statement send-direct term 2]user@A# set from protocol directuser@A# set then accept - Configure the router ID and the AS number.[edit routing-options]user@A# set router-id 192.168.6.5user@A# set autonomous-system 17
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.
Configuring Device B
Step-by-Step Procedure
The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode.
To configure internal BGP peer sessions on Device B:
- Configure the interfaces.[edit interfaces ge-0/1/0 unit 2]user@B# set description to-Auser@B# set family inet address 10.10.10.2/30[edit interfaces ge-0/1/1]user@B# set unit 5 description to-Cuser@B# set unit 5 family inet address 10.10.10.5/30[edit interfaces]user@B# set lo0 unit 2 family inet address 192.163.6.4/32
- Configure BGP.
The neighbor statements are included for both Device B and Device C, even though Device A is not directly connected to Device C.
[edit protocols bgp group internal-peers]user@B# set type internaluser@B# set description “connections to A and C”user@B# set local-address 192.163.6.4user@B# set export send-directuser@B# set neighbor 192.168.40.4user@B# set neighbor 192.168.6.5 - Configure OSPF.[edit protocols ospf area 0.0.0.0]user@B# set interface lo0.2 passiveuser@B# set interface ge-0/1/0.2user@B# set interface ge-0/1/1.5
- Configure a policy that accepts direct routes.
Other useful options for this scenario might be to accept routes learned through OSPF or local routes.
[edit policy-options policy-statement send-direct term 2]user@B# set from protocol directuser@B# set then accept - Configure the router ID and the AS number.[edit routing-options]user@B# set router-id 192.163.6.4user@B# set autonomous-system 17
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.
Configuring Device C
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 internal BGP peer sessions on Device C:
- Configure the interfaces.[edit interfaces ge-0/1/0 unit 6]user@C# set description to-Buser@C# set family inet address 10.10.10.6/30[edit interfaces]user@C# set lo0 unit 3 family inet address 192.168.40.4/32
- Configure BGP.
The neighbor statements are included for both Device B and Device C, even though Device A is not directly connected to Device C.
[edit protocols bgp group internal-peers]user@C# set type internaluser@C# set description “connections to A and B”user@C# set local-address 192.168.40.4user@C# set export send-directuser@C# set neighbor 192.163.6.4user@C# set neighbor 192.168.6.5 - Configure OSPF.[edit protocols ospf area 0.0.0.0]user@C# set interface lo0.3 passiveuser@C# set interface ge-0/1/0.6
- Configure a policy that accepts direct routes.
Other useful options for this scenario might be to accept routes learned through OSPF or local routes.
[edit policy-options policy-statement send-direct term 2]user@C# set from protocol directuser@C# set then accept - Configure the router ID and the AS number.[edit routing-options]user@C# set router-id 192.168.40.4user@C# set autonomous-system 17
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.
Verification
Confirm that the configuration is working properly.
Verifying BGP Neighbors
Purpose
Verify that BGP is running on configured interfaces and that the BGP session is active 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+58852 AS 17 Type: Internal State: Established Flags: Sync Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ send-direct ] Options: Preference LocalAddress 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: 3 Accepted prefixes: 3 Suppressed due to damping: 0 Advertised prefixes: 2 Last traffic (seconds): Received 25 Sent 19 Checked 67 Input messages: Total 2420 Updates 4 Refreshes 0 Octets 46055 Output messages: Total 2411 Updates 2 Refreshes 0 Octets 45921 Output Queue[0]: 0 Peer: 192.168.40.4+179 AS 17 Local: 192.168.6.5+56466 AS 17 Type: Internal State: Established Flags: Sync Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ send-direct ] Options: Preference LocalAddress 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: 2 Accepted prefixes: 2 Suppressed due to damping: 0 Advertised prefixes: 2 Last traffic (seconds): Received 7 Sent 21 Checked 24 Input messages: Total 2412 Updates 2 Refreshes 0 Octets 45867 Output messages: Total 2409 Updates 2 Refreshes 0 Octets 45883 Output Queue[0]: 0
Verifying 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 Eval> Export: [ send-direct ] Holdtime: 0 Total peers: 2 Established: 2 192.163.6.4+179 192.168.40.4+179 inet.0: 0/5/5/0 Groups: 1 Peers: 2 External: 0 Internal: 2 Down peers: 0 Flaps: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 5 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: 2 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 5 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 192.163.6.4 17 2441 2432 0 0 18:18:52 0/3/3/0 0/0/0/0 192.168.40.4 17 2432 2430 0 0 18:18:48 0/2/2/0 0/0/0/0
Verifying That BGP Routes Are Installed in the Routing Table
Purpose
Verify that the export policy configuration is causing the BGP routes to be installed in the routing tables of the peers.
Action
From operational mode, enter the show route protocol bgp command.
user@A> show route protocol bgp
inet.0: 7 destinations, 12 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.10.10.0/30 [BGP/170] 07:09:57, localpref 100, from 192.163.6.4 AS path: I > to 10.10.10.2 via ge-0/1/0.1 10.10.10.4/30 [BGP/170] 07:09:57, localpref 100, from 192.163.6.4 AS path: I > to 10.10.10.2 via ge-0/1/0.1 [BGP/170] 07:07:12, localpref 100, from 192.168.40.4 AS path: I > to 10.10.10.2 via ge-0/1/0.1 192.163.6.4/32 [BGP/170] 07:09:57, localpref 100, from 192.163.6.4 AS path: I > to 10.10.10.2 via ge-0/1/0.1 192.168.40.4/32 [BGP/170] 07:07:12, localpref 100, from 192.168.40.4 AS path: I > to 10.10.10.2 via ge-0/1/0.1
See also
Example: Configuring Internal BGP Peering Sessions on Logical Systems
This example shows how to configure internal BGP peer sessions on logical systems.
Requirements
In this example, no special configuration beyond device initialization is required.
Overview
In this example, you configure internal BGP (IBGP) peering sessions.
In the sample network, the devices in AS 17 are fully meshed in the group internal-peers. The devices have loopback addresses 192.168.6.5, 192.163.6.4, and 192.168.40.4.
Figure 6 shows a typical network with internal peer sessions.

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 A
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 internal BGP peer sessions on Device A:
- Configure the interfaces.[edit logical-systems A interfaces lt-0/1/0 unit 1]user@R1# set description to-Buser@R1# set encapsulation ethernetuser@R1# set peer-unit 2user@R1# set family inet address 10.10.10.1/30user@R1# set family inet address 192.168.6.5/32user@R1# upuser@R1# up[edit logical-systems A interfaces]user@R1# set lo0 unit 1 family inet address 192.168.6.5/32user@R1# exit[edit]user@R1# edit logical-systems B interfaces lt-0/1/0[edit logical-systems B interfaces lt-0/1/0]user@R1# set unit 2 description to-Auser@R1# set unit 2 encapsulation ethernetuser@R1# set unit 2 peer-unit 1user@R1# set unit 2 family inet address 10.10.10.2/30user@R1# set unit 5 description to-Cuser@R1# set unit 5 encapsulation ethernetuser@R1# set unit 5 peer-unit 6user@R1# set family inet address 10.10.10.5/30user@R1# up[edit logical-systems B interfaces]user@R1# set lo0 unit 2 family inet address 192.163.6.4/32user@R1# exit[edit]user@R1# edit logical-systems C interfaces lt-0/1/0 unit 6[edit logical-systems C interfaces lt-0/1/0 unit 6]set description to-Bset encapsulation ethernetset peer-unit 5set family inet address 10.10.10.6/30user@R1# upuser@R1# up[edit logical-systems C interfaces]set lo0 unit 3 family inet address 192.168.40.4/32
- Configure BGP.
On Logical System A, the neighbor statements are included for both Device B and Device C, even though Logical System A is not directly connected to Device C.
[edit logical-systems A protocols bgp group internal-peers]user@R1# set type internaluser@R1# set local-address 192.168.6.5user@R1# set export send-directuser@R1# set neighbor 192.163.6.4user@R1# set neighbor 192.168.40.4[edit logical-systems B protocols bgp group internal-peers]user@R1# set type internaluser@R1# set local-address 192.163.6.4user@R1# set export send-directuser@R1# set neighbor 192.168.40.4user@R1# set neighbor 192.168.6.5[edit logical-systems C protocols bgp group internal-peers]user@R1# set type internaluser@R1# set local-address 192.168.40.4user@R1# set export send-directuser@R1# set neighbor 192.163.6.4user@R1# set neighbor 192.168.6.5 - Configure OSPF.[edit logical-systems A protocols ospf area 0.0.0.0]user@R1# set interface lo0.1 passiveuser@R1# set interface lt-0/1/0.1[edit logical-systems A protocols ospf area 0.0.0.0]user@R1# set interface lo0.2 passiveuser@R1# set interface lt-0/1/0.2user@R1# set interface lt-0/1/0.5[edit logical-systems A protocols ospf area 0.0.0.0]user@R1# set interface lo0.3 passiveuser@R1# set interface lt-0/1/0.6
- Configure a policy that accepts direct routes.
Other useful options for this scenario might be to accept routes learned through OSPF or local routes.
[edit logical-systems A policy-options policy-statement send-direct term 2]user@R1# set from protocol directuser@R1# set then accept[edit logical-systems B policy-options policy-statement send-direct term 2]user@R1# set from protocol directuser@R1# set then accept[edit logical-systems C policy-options policy-statement send-direct term 2]user@R1# set from protocol directuser@R1# set then accept - Configure the router ID and the autonomous system (AS)
number.[edit logical-systems A routing-options]user@R1# set router-id 192.168.6.5user@R1# set autonomous-system 17[edit logical-systems B routing-options]user@R1# set router-id 192.163.6.4user@R1# set autonomous-system 17[edit logical-systems C routing-options]user@R1# set router-id 192.168.40.4user@R1# set autonomous-system 17
Results
From configuration mode, confirm your configuration by entering the show logical-systems command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.
If you are done configuring the device, enter commit from configuration mode.
Verification
Confirm that the configuration is working properly.
Verifying BGP Neighbors
Purpose
Verify that BGP is running on configured interfaces and that the BGP session is active for each neighbor address.
Action
From the operational mode, enter the show bgp neighbor command.
user@R1> show bgp neighbor logical-system A
Peer: 192.163.6.4+179 AS 17 Local: 192.168.6.5+58852 AS 17 Type: Internal State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ send-direct ] Options: <Preference LocalAddress 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: 3 Accepted prefixes: 3 Suppressed due to damping: 0 Advertised prefixes: 2 Last traffic (seconds): Received 16 Sent 1 Checked 63 Input messages: Total 15713 Updates 4 Refreshes 0 Octets 298622 Output messages: Total 15690 Updates 2 Refreshes 0 Octets 298222 Output Queue[0]: 0 Peer: 192.168.40.4+179 AS 17 Local: 192.168.6.5+56466 AS 17 Type: Internal State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ send-direct ] Options: <Preference LocalAddress 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: 2 Accepted prefixes: 2 Suppressed due to damping: 0 Advertised prefixes: 2 Last traffic (seconds): Received 15 Sent 22 Checked 68 Input messages: Total 15688 Updates 2 Refreshes 0 Octets 298111 Output messages: Total 15688 Updates 2 Refreshes 0 Octets 298184 Output Queue[0]: 0
Verifying BGP Groups
Purpose
Verify that the BGP groups are configured correctly.
Action
From the operational mode, enter the show bgp group command.
user@A> show bgp group logical-system A
Group Type: Internal AS: 17 Local AS: 17 Name: internal-peers Index: 0 Flags: <Export Eval> Export: [ send-direct ] Holdtime: 0 Total peers: 2 Established: 2 192.163.6.4+179 192.168.40.4+179 inet.0: 0/5/5/0 Groups: 1 Peers: 2 External: 0 Internal: 2 Down peers: 0 Flaps: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 5 0 0 0 0 0
Verifying BGP Summary Information
Purpose
Verify that the BGP configuration is correct.
Action
From the operational mode, enter the show bgp summary command.
user@A> show bgp summary logical-system A
Groups: 1 Peers: 2 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 5 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 192.163.6.4 17 15723 15700 0 0 4d 22:13:15 0/3/3/0 0/0/0/0 192.168.40.4 17 15698 15699 0 0 4d 22:13:11 0/2/2/0 0/0/0/0
Verifying That BGP Routes Are Installed in the Routing Table
Purpose
Verify that the export policy configuration is working.
Action
From the operational mode, enter the show route protocol bgp command.
user@A> show route protocol bgp logical-system
A
inet.0: 7 destinations, 12 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.10.10.0/30 [BGP/170] 4d 11:05:55, localpref 100, from 192.163.6.4 AS path: I > to 10.10.10.2 via lt-0/1/0.1 10.10.10.4/30 [BGP/170] 4d 11:05:55, localpref 100, from 192.163.6.4 AS path: I > to 10.10.10.2 via lt-0/1/0.1 [BGP/170] 4d 11:03:10, localpref 100, from 192.168.40.4 AS path: I > to 10.10.10.2 via lt-0/1/0.1 192.163.6.4/32 [BGP/170] 4d 11:05:55, localpref 100, from 192.163.6.4 AS path: I > to 10.10.10.2 via lt-0/1/0.1 192.168.40.4/32 [BGP/170] 4d 11:03:10, localpref 100, from 192.168.40.4 AS path: I > to 10.10.10.2 via lt-0/1/0.1
Overview: Configure Multiple Single-Hop EBGP Sessions on Different Links Using the Same Link-Local Address (IPv6)
In complex networks such as Data Center or Cloud, link-local addresses are widely used due to the high number of links and nodes. Being able to deploy multiple single-hop BGP sessions for Juniper devices using link-local addresses is a significant advantage.
Starting in Junos OS Release 20.4R1, you can enable single-hop EBGP sessions on different links over multiple directly connected peers that use the same IPv6 link-local address. You are no longer required to have unique peer addresses for Juniper devices for every EBGP session.
Example: Configure Multiple Single-Hop EBGP Sessions on Different Links Using the Same IPv6 Link-Local Address
This example shows how to configure multiple single-hop EBGP sessions on different links using the same IPv6 link-local address.
Requirements
This example uses the following hardware and software components:
2 MX Series routers
Junos OS Release 20.4R1 or later version
Overview
Prior to Junos OS Release 20.4R1, you could configure BGP peers with link-local addresses but you could not configure multiple BGP peers to use the same link-local address on different interfaces. Starting in Junos OS 20.4R1, you can enable multiple single-hop EBGP sessions on different links using the same link-local address.
Topology

Configuration
In this example, you configure multiple single-hop EBGP sessions on two different links using the same IPv6 link-local address.
CLI Quick Configuration
R1
R2
Configure Single-Hop EBGP Sessions on Multiple Links Using the Same IPv6 Link-Local Address
Step-by-Step Procedure
- Configure basic set up, including vlan-tagging, vlan-id,
loopback and IPv6 link-local addresses for R1 and R2.
You can configure multiple units on a single interface as follows:
R1
set interfaces ge-0/0/1set interfaces ge-0/0/1 description R1-to-R2-Linkset interfaces ge-0/0/1 vlan-taggingset interfaces ge-0/0/1 unit 1 vlan-id 1set interfaces ge-0/0/1 unit 1 family inet6 address fe80::10/64set interfaces ge-0/0/1 unit 2 vlan-id 2set interfaces ge-0/0/1 unit 2 family inet6 address fe80::10/64set interfaces lo0 unit 0 family inet address 198.51.100.1/24 primaryR2
set interfaces ge-0/0/1set interfaces ge-0/0/1 description R2-to-R1-Linkset interfaces ge-0/0/1 vlan-taggingset interfaces ge-0/0/1 unit 1 vlan-id 1set interfaces ge-0/0/1 unit 1 family inet6 address fe80::20/64set interfaces ge-0/0/1 unit 2 vlan-id 2set interfaces ge-0/0/1 unit 2 family inet6 address fe80::20/64set interfaces lo0 unit 0 family inet address 198.51.100.2/24 primary - Configure routing options to enable BGP on R1 and R2.
R1
set routing-options router-id 198.51.100.1set routing-options autonomous-system 65541R2
set routing-options router-id 198.51.100.2set routing-options autonomous-system 65542 - Configure EBGP on the multiple links on R1 and R2 using
the same link-local IPv6 addresses in the set protocols bgp group group neighbor peeraddress%localinterface.unit format:
R1
set protocols bgp group external peer-as 65542set protocols bgp group external local-as 65541set protocols bgp group external neighbor fe80::20%ge-0/0/1.1set protocols bgp group external neighbor "fe80::20%ge-0/0/1.2R2
set protocols bgp group external peer-as 65541set protocols bgp group external local-as 65542set protocols bgp group external neighbor fe80::10%ge-0/0/1.1set protocols bgp group external neighbor fe80::10%ge-0/0/1.2 - Enter commit from the configuration mode.
Results
Verify your configuration by checking the below configurations from devices as follows:
Here’s how you can verify configurations on R1 device:
user@R1# show interfaces
user@R1# show protocols
user@R1# show routing-options
Verification
Verify EBGP Link-local Support
Purpose
Use the show bgp summary command to verify the EBGP sessions created on the devices with the same link-local address through different interfaces.
Action
user@R1> show bgp summary
Threading mode: BGP I/O Default eBGP mode: advertise - accept, receive - accept Groups: 1 Peers: 2 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet6.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... fe80::20%ge-0/0/1.1 65542 115 114 0 0 50:59 Establ inet6.0: 0/0/0/0 fe80::20%ge-0/0/1.2 65542 114 114 0 0 50:58 Establ inet6.0: 0/0/0/0
Meaning
The output indicates that 2 EBGP sessions are established with the same IPv6 link-local address (fe80::20) of R2 through the 2 configured local-interfaces of R1 (ge-0/0/1.1 and ge-0/0/1.2).