Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Example: Configuring EBGP Multihop Sessions on Logical Systems

Requirements

In this example, no special configuration beyond device initialization is required.

Overview

When EBGP peers are not directly connected to each other, they must cross one or more non-BGP routers to reach each other. Configuring multihop EBGP enables the peers to pass through the other routers to form peer relationships and exchange update messages. This type of configuration is typically used when a Juniper Networks routing device needs to run EBGP with a third-party router that does not allow direct connection of the two EBGP peers. EBGP multihop enables a neighbor connection between two EBGP peers that do not have a direct connection.

The configuration to enable multihop EBGP sessions requires connectivity between the two EBGP peers. This example uses static routes to provide connectivity between the devices.

For directly connected EBGP sessions, physical addresses are typically used in the neighbor statements. For multihop EBGP, you must use loopback interface addresses, and specify the loopback interface address of the indirectly connected peer. In the use of loopback interfaces addresses, EBGP multihop is similar to internal BGP (IBGP).

Finally, you must add the multihop statement. Optionally, you can set a maximum time-to-live (TTL) value with the ttl statement. The TTL is carried in the IP header of BGP packets. If you do not specify a TTL value, the system’s default maximum TTL value is used. The default TTL value is 64 for multihop EBGP sessions. Another option is to retain the BGP next-hop value for route advertisements by including the no-nexthop-change statement.

Figure 1 shows a typical EBGP multihop network.

Device C and Device E have an established EBGP session. Device D is not a BGP-enabled device. All of the devices have connectivity via static routes.

Figure 1: Typical Network with EBGP Multihop 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 C

Step-by-Step Procedure

1. Set the CLI to Logical System C.
   user@host> set cli logical-system C
2. Configure the interface to the directly-connected device (to-D), and configure the loopback interface.
   [edit interfaces lt-1/2/0 unit 9]user@host:C# set description to-Duser@host:C# set encapsulation ethernetuser@host:C# set peer-unit 10user@host:C# set family inet address 10.10.10.9/30
   [edit interfaces lo0 unit 3]user@host:C# set family inet address 192.168.40.4/32
3. Configure an EBGP session with Logical System E.

   The neighbor statement points to the loopback interface on Logical System E.

   [edit protocols bgp group external-peers]user@host:C# set type externaluser@host:C# set local-address 192.168.40.4user@host:C# set export send-staticuser@host:C# set peer-as 18user@host:C# set neighbor 192.168.6.7
4. Configure the multihop statement to enable Logical System C and Logical System E to become EBGP peers.

   Because the peers are two hops away from each other, the example uses the ttl 2 statement.

   [edit protocols bgp group external-peers]user@host:C# set multihop ttl 2
5. Configure connectivity to Logical System E, using static routes.

   You must configure a route to both the loopback interface address and to the address on the physical interface.

   [edit logical-systems C routing-options]user@host:C# set static route 10.10.10.14/32 next-hop 10.10.10.10user@host:C# set static route 192.168.6.7/32 next-hop 10.10.10.10
6. Configure the local router ID and the autonomous system (AS) number.
   [edit routing-options]user@host:C# set router-id 192.168.40.4user@host:C# set autonomous-system 17
7. 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-static term 1]user@host:C# set from protocol staticuser@host:C# set then accept

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.

If you are done configuring the device, enter commit from configuration mode. Repeat these steps for all BFD sessions in the topology.

Device D

Step-by-Step Procedure

1. Set the CLI to Logical System D.
   user@host> set cli logical-system D
2. Configure the interfaces to the directly-connected devices, and configure a loopback interface.
   [edit interfaces lt-1/2/0 unit 10]user@host:D# set description to-Cuser@host:D# set encapsulation ethernetuser@host:D# set peer-unit 9user@host:D# set family inet address 10.10.10.10/30
   [edit interfaces lt-1/2/0 unit 13]user@host:D# set description to-Euser@host:D# set encapsulation ethernetuser@host:D# set peer-unit 14user@host:D# set family inet address 10.10.10.13/30
   [edit interfaces lo0 unit 4]user@host:D# set family inet address 192.168.6.6/32
3. Configure connectivity to the other devices using a static routes to the loopback interface addresses.

   On Logical System D, you do not need static routes to the physical addresses because Logical System D is directly connected to Logical System C and Logical System E.

   [edit routing-options]user@host:D# set static route 192.168.40.4/32 next-hop 10.10.10.9user@host:D# set static route 192.168.6.7/32 next-hop 10.10.10.14
4. Configure the local router ID and the autonomous system (AS) number.
   [edit routing-options]user@host:D# set router-id 192.168.6.6

Results

From configuration mode, confirm your configuration by entering the show interfaces and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode. Repeat these steps for all BFD sessions in the topology.

Device E

Step-by-Step Procedure

1. Set the CLI to Logical System E.
   user@host> set cli logical-system E
2. Configure the interface to the directly-connected device (to-D), and configure the loopback interface.
   [edit interfaces lt-1/2/0 unit 14]user@host:E# set description to-Duser@host:E# set encapsulation ethernetuser@host:E# set peer-unit 13user@host:E# set family inet address 10.10.10.14/30
   [edit interfaces lo0 unit 5]user@host:E# set family inet address 192.168.6.7/32
3. Configure an EBGP session with Logical System E.

   The neighbor statement points to the loopback interface on Logical System C.

   [edit protocols bgp group external-peers]user@host:E# set local-address 192.168.6.7user@host:E# set export send-staticuser@host:E# set peer-as 17user@host:E# set neighbor 192.168.40.4
4. Configure the multihop statement to enable Logical System C and Logical System E to become EBGP peers.

   Because the peers are two hops away from each other, the example uses the ttl 2 statement.

   [edit protocols bgp group external-peers]user@host:E# set multihop ttl 2
5. Configure connectivity to Logical System E, using static routes.

   You must configure a route to both the loopback interface address and to the address on the physical interface.

   [edit routing-options]user@host:E# set static route 10.10.10.8/30 next-hop 10.10.10.13user@host:E# set static route 192.168.40.4/32 next-hop 10.10.10.13
6. Configure the local router ID and the autonomous system (AS) number.
   [edit routing-options]user@host:E# set router-id 192.168.6.7user@host:E# set autonomous-system 18
7. 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-static term 1]user@host:E# set from protocol staticuser@host:E# set send-static then accept

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.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

• Verifying Connectivity
• Verifying the BGP Sessions Are Established
• Viewing Advertised Routes

Verifying Connectivity

Purpose

Make sure that Device C can ping Device E, specifying the loopback interface address as the source of the ping request.

The loopback interface address is the source address that BGP will be using.

Action

From operational mode, enter the ping 10.10.10.14 source 192.168.40.4 command from Logical System C, and enter the ping 10.10.10.9 source 192.168.6.7 command from Logical System E.

PING 10.10.10.14 (10.10.10.14): 56 data bytes
64 bytes from 10.10.10.14: icmp_seq=0 ttl=63 time=1.262 ms
64 bytes from 10.10.10.14: icmp_seq=1 ttl=63 time=1.202 ms
^C
--- 10.10.10.14 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.202/1.232/1.262/0.030 ms

PING 10.10.10.9 (10.10.10.9): 56 data bytes
64 bytes from 10.10.10.9: icmp_seq=0 ttl=63 time=1.255 ms
64 bytes from 10.10.10.9: icmp_seq=1 ttl=63 time=1.158 ms
^C
--- 10.10.10.9 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.158/1.206/1.255/0.049 ms

Meaning

The static routes are working if the pings work.

Verifying the BGP Sessions Are Established

Purpose

Verify that the BGP sessions are up.

Action

From operational mode, enter the show bgp summary command.

Groups: 1 Peers: 1 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0                 2          0          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.168.6.7              18        147        147       0       1     1:04:27 0/2/2/0              0/0/0/0

Groups: 1 Peers: 1 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0                 2          0          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.168.40.4             17        202        202       0       1     1:02:18 0/2/2/0              0/0/0/0

Meaning

The output shows that both devices have one peer each. No peers are down.

Viewing Advertised Routes

Purpose

Checking to make sure that routes are being advertised by BGP.

Action

From operational mode, enter the show route advertising-protocol bgp neighbor command.

inet.0: 5 destinations, 7 routes (5 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.10.10.14/32          Self                                    I
* 192.168.6.7/32          Self                                    I

inet.0: 5 destinations, 7 routes (5 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.10.10.8/30           Self                                    I
* 192.168.40.4/32         Self                                    I

Meaning

The send-static routing policy is exporting the static routes from the routing table into BGP. BGP is advertising these routes between the peers because the BGP peer session is established.