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.

Example: Configuring EBGP Multihop

Understanding BGP Multihop

When external BGP (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.

Example: Configuring EBGP Multihop Sessions

This example shows how to configure an external BGP (EBGP) peer that is more than one hop away from the local router. This type of session is called a multihop BGP session.

• Requirements
• Overview
• Configuration
• Verification

Requirements

No special configuration beyond device initialization is required before you configure this example.

Overview

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.

Unlike directly connected EBGP sessions in which physical address are typically used in the neighbor statements, you must use loopback interface addresses for multihop EBGP by specifying the loopback interface address of the indirectly connected peer. In this way, 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. Configure the interface to the directly connected device (to-D), and configure the loopback interface.
   [edit interfaces fe-1/2/0 unit 9]user@C# set description to-Duser@C# set family inet address 10.10.10.9/30
   [edit interfaces lo0 unit 3]user@C# set family inet address 192.168.40.4/32
2. Configure an EBGP session with Device E.

   The neighbor statement points to the loopback interface on Device E.

   [edit protocols bgp group external-peers]user@C# set type externaluser@C# set local-address 192.168.40.4user@C# set export send-staticuser@C# set peer-as 18user@C# set neighbor 192.168.6.7
3. Configure the multihop statement to enable Device C and Device 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@C# set multihop ttl 2
4. Configure connectivity to Device 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@C# set static route 10.10.10.14/32 next-hop 10.10.10.10user@C# set static route 192.168.6.7/32 next-hop 10.10.10.10
5. Configure the local router ID and the autonomous system (AS) number.
   [edit routing-options]user@C# set router-id 192.168.40.4user@C# set autonomous-system 17
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-static term 1]user@C# set from protocol staticuser@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.

Configuring Device D

Step-by-Step Procedure

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

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

   [edit routing-options]user@D# set static route 192.168.40.4/32 next-hop 10.10.10.9user@D# set static route 192.168.6.7/32 next-hop 10.10.10.14
4. Configure the local router ID.
   [edit routing-options]user@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.

Configuring Device E

Step-by-Step Procedure

1. Set the CLI to Device 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 fe-1/2/0 unit 14]user@E# set description to-Duser@E# set family inet address 10.10.10.14/30
   [edit interfaces lo0 unit 5]user@E# set family inet address 192.168.6.7/32
3. Configure an EBGP session with Device E.

   The neighbor statement points to the loopback interface on Device C.

   [edit protocols bgp group external-peers]user@E# set local-address 192.168.6.7user@E# set export send-staticuser@E# set peer-as 17user@E# set neighbor 192.168.40.4
4. Configure the multihop statement to enable Device C and Device 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@E# set multihop ttl 2
5. Configure connectivity to Device 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@E# set static route 10.10.10.8/30 next-hop 10.10.10.13user@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@E# set router-id 192.168.6.7user@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@E# set from protocol staticuser@E# 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.

Verification

Confirm that the configuration is working properly.

• Verifying Connectivity
• Verifying That 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 use.

Action

From operational mode, enter the ping 10.10.10.14 source 192.168.40.4 command from Device C, and enter the ping 10.10.10.9 source 192.168.6.7 command from Device 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 That 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

Check 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.