Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

TechLibrary
Navigation

Examples: Configuring BGP Multipath

Understanding BGP Multipath

The Junos OS BGP multipath feature supports the following applications:

  • Load balancing across multiple links between two routing devices belonging to different autonomous systems (ASs)
  • Load balancing across a common subnet or multiple subnets to different routing devices belonging to the same peer AS
  • Load balancing across multiple links between two routing devices belonging to different external confederation peers
  • Load balancing across a common subnet or multiple subnets to different routing devices belonging to external confederation peers

In a common scenario for load balancing, a customer is multihomed to multiple routers in a point of presence (POP). The default behavior is to send all traffic across only one of the available links. Load balancing causes traffic to use two or more of the links.

BGP multipath does not apply to paths that share the same MED-plus-IGP cost, yet differ in IGP cost. Multipath path selection is based on the IGP cost metric, even if two paths have the same MED-plus-IGP cost.

Example: Load Balancing BGP Traffic

This example shows how to configure BGP to select multiple equal-cost external BGP (EBGP) or internal BGP (IBGP) paths as active paths.

Requirements

Before you begin:

  • Configure the device interfaces.
  • Configure an interior gateway protocol (IGP).
  • Configure BGP.
  • Configure a routing policy that exports routes (such as direct routes or IGP routes) from the routing table into BGP.

Overview

The following steps shows how to configure per-packet load balancing:

  1. Define a load-balancing routing policy by including one or more policy-statement statements at the [edit policy-options] hierarchy level, defining an action of load-balance per-packet:
    policy-statement policy-name {from {match-conditions;route-filter destination-prefix match-type <actions>;prefix-list name;}then {load-balance per-packet;}}
  2. Apply the policy to routes exported from the routing table to the forwarding table. To do this, include the forwarding-table and export statements:
    forwarding-table {export policy-name;}

    You cannot apply the export policy to VRF routing instances.

  3. Specify all next-hops of that route, if more than one exists, when allocating a label corresponding to a route that is being advertised.
  4. Configure the forwarding-options hash key for MPLS to include the IP payload.

In this example, Device R1 is in AS 65000 and is connected to both Device R2 and Device R3, which are in AS 65001. This example shows the configuration on Device R1.

Topology

Figure 1 shows the topology used in this example.

Figure 1: BGP Load Balancing

BGP Load Balancing

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.

set protocols bgp group external type external set protocols bgp group external peer-as 65001set protocols bgp group external multipath set protocols bgp group external neighbor 10.0.1.1 set protocols bgp group external neighbor 10.0.0.2 set policy-options policy-statement loadbal from route-filter 10.0.0.0/16 orlonger set policy-options policy-statement loadbal then load-balance per-packet set routing-options forwarding-table export loadbalset routing-options autonomous-system 65000

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 in the CLI User Guide.

To configure the BGP peer sessions:

  1. Configure the BGP group.
    [edit protocols bgp group external]user@R1# set type external user@R1# set peer-as 65001 user@R1# set neighbor 10.0.1.1 user@R1# set neighbor 10.0.0.2
  2. Enable the BGP group to use multiple paths.

    Note: To disable the default check requiring that paths accepted by BGP multipath must have the same neighboring autonomous system (AS), include the multiple-as option.

    [edit protocols bgp group external]user@R1# set multipath
  3. Configure the load-balancing policy.
    [edit policy-options policy-statement loadbal]user@R1# set from route-filter 10.0.0.0/16 orlonger user@R1# set then load-balance per-packet
  4. Apply the load-balancing policy.
    [edit routing-options]user@R1# set forwarding-table export loadbal
  5. Configure the local autonomous system (AS) number.
    [edit routing-options]user@R1# set autonomous-system 65000

Results

From configuration mode, confirm your configuration by entering the 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.

[edit]user@R1# show protocols
bgp {group external {type external;peer-as 65001;multipath;neighbor 10.0.1.1;neighbor 10.0.0.2;}}
[edit]user@R1# show policy-options
policy-statement loadbal {from {route-filter 10.0.0.0/16 orlonger;}then {load-balance per-packet;}}
[edit]user@R1# show routing-optionsautonomous-system 65000;
forwarding-table {export loadbal;}

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

Verification

Confirm that the configuration is working properly:

Verifying Routes

Purpose

Verify that routes are learned from both routers in the neighboring AS.

Action

From operational mode, run the show route command.

user@R1> show route 10.0.2.0
inet.0: 12 destinations, 15 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.2.0/30        *[BGP/170] 03:12:32, localpref 100
                      AS path: 65001 I
                      to 10.0.1.1 via ge-1/2/0.0
                    > to 10.0.0.2 via ge-1/2/1.0
                    [BGP/170] 03:12:32, localpref 100
                      AS path: 65001 I
                    > to 10.0.1.1 via ge-1/2/0.0
user@R1> show route 10.0.2.0 detail
inet.0: 12 destinations, 15 routes (12 active, 0 holddown, 0 hidden)
10.0.2.0/30 (2 entries, 1 announced)
        *BGP    Preference: 170/-101
                Next hop type: Router, Next hop index: 262142
                Next-hop reference count: 3
                Source: 10.0.0.2
                Next hop: 10.0.1.1 via ge-1/2/0.0
                Next hop: 10.0.0.2 via ge-1/2/1.0, selected
                State: <Active Ext>
                Local AS: 65000 Peer AS: 65001
                Age: 3:18:30 
                Task: BGP_65001.10.0.0.2+55402
                Announcement bits (1): 2-KRT 
                AS path: 65001 I
                Accepted Multipath
                Localpref: 100
                Router ID: 192.168.2.1
         BGP    Preference: 170/-101
                Next hop type: Router, Next hop index: 602
                Next-hop reference count: 5
                Source: 10.0.1.1
                Next hop: 10.0.1.1 via ge-1/2/0.0, selected
                State: <NotBest Ext>
                Inactive reason: Not Best in its group - Active preferred
                Local AS: 65000 Peer AS: 65001
                Age: 3:18:30 
                Task: BGP_65001.10.0.1.1+53135
                AS path: 65001 I
                Accepted
                Localpref: 100
                Router ID: 192.168.3.1

Meaning

The active path, denoted with an asterisk (*), has two next hops: 10.0.1.1 and 10.0.0.2 to the 10.0.2.0 destination. The 10.0.1.1 next hop is copied from the inactive path to the active path.

Verifying Forwarding

Purpose

Verify that both next hops are installed in the forwarding table.

Action

From operational mode, run the show route forwarding-table command.

user@R1> show route forwarding-table destination 10.0.2.0
Routing table: default.inet
Internet:
Destination        Type RtRef Next hop           Type Index NhRef Netif
10.0.2.0/30        user     0                    ulst 262142     2
                              10.0.1.1           ucst   602     5 ge-1/2/0.0
                              10.0.0.2           ucst   522     6 ge-1/2/1.0

Example: Configuring Single-Hop EBGP Peers to Accept Remote Next Hops

This example shows how to configure a single-hop external BGP (EBGP) peer to accept a remote next hop with which it does not share a common subnet.

Requirements

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

Overview

In some situations, it is necessary to configure a single-hop EBGP peer to accept a remote next hop with which it does not share a common subnet. The default behavior is for any next-hop address received from a single-hop EBGP peer that is not recognized as sharing a common subnet to be discarded. The ability to have a single-hop EBGP peer accept a remote next hop to which it is not directly connected also prevents you from having to configure the single-hop EBGP neighbor as a multihop session. When you configure a multihop session in this situation, all next-hop routes learned through this EBGP peer are labeled indirect even when they do share a common subnet. This situation breaks multipath functionality for routes that are recursively resolved over routes that include these next-hop addresses. Configuring the accept-remote-nexthop statement allows a single-hop EBGP peer to accept a remote next hop, which restores multipath functionality for routes that are resolved over these next-hop addresses. You can configure this statement at the global, group, and neighbor hierarchy levels for BGP. The statement is also supported on logical systems and the VPN routing and forwarding (VRF) routing instance type. Both the remote next-hop and the EBGP peer must support BGP route refresh as defined in RFC 2918, Route Refresh Capability in BGP-4. If the remote peer does not support BGP route refresh, the session is reset.

Note: You cannot configure both the multihop and accept-remote-nexthop statements for the same EBGP peer.

When you enable a single-hop EBGP peer to accept a remote next hop, you must also configure an import routing policy on the EBGP peer that specifies the remote next-hop address.

This example includes an import routing policy, agg_route, that enables a single-hop external BGP peer (Device R1) to accept the remote next-hop 1.1.10.10 for the route to the 1.1.230.0/23 network. At the [edit protocols bgp] hierarchy level, the example includes the import agg_route statement to apply the policy to the external BGP peer and includes the accept-remote-nexthop statement to enable the single-hop EBGP peer to accept the remote next hop.

Figure 2 shows the sample topology.

Figure 2: Topology for Accepting a Remote Next Hop

Topology for Accepting a Remote Next Hop

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 R0

set interfaces fe-1/2/0 unit 1 family inet address 1.1.0.1/30set interfaces fe-1/2/1 unit 2 family inet address 1.1.1.1/30set interfaces lo0 unit 1 family inet address 10.255.14.179/32set protocols bgp group ext type externalset protocols bgp group ext export test_routeset protocols bgp group ext export agg_routeset protocols bgp group ext peer-as 65000set protocols bgp group ext multipathset protocols bgp group ext neighbor 1.1.0.2set protocols bgp group ext neighbor 1.1.1.2set policy-options policy-statement agg_route term 1 from protocol staticset policy-options policy-statement agg_route term 1 from route-filter 1.1.230.0/23 exactset policy-options policy-statement agg_route term 1 then acceptset policy-options policy-statement test_route term 1 from protocol staticset policy-options policy-statement test_route term 1 from route-filter 1.1.10.10/32 exactset policy-options policy-statement test_route term 1 then acceptset routing-options static route 1.1.10.10/32 rejectset routing-options static route 1.1.230.0/23 rejectset routing-options autonomous-system 65500

Device R1

set interfaces fe-1/2/0 unit 3 family inet address 1.1.0.2/30set interfaces fe-1/2/1 unit 4 family inet address 1.12.0.1/30set interfaces fe-1/2/2 unit 5 family inet address 1.1.1.2/30set interfaces lo0 unit 2 family inet address 10.255.71.24/32set protocols bgp accept-remote-nexthopset protocols bgp group ext type externalset protocols bgp group ext import agg_routeset protocols bgp group ext peer-as 65500set protocols bgp group ext multipathset protocols bgp group ext neighbor 1.1.0.1set protocols bgp group ext neighbor 1.1.1.1set protocols bgp group int type internalset protocols bgp group int local-address 10.255.71.24set protocols bgp group int neighbor 10.255.14.177set protocols ospf area 0.0.0.0 interface fe-1/2/1.4set protocols ospf area 0.0.0.0 interface 10.255.71.24set policy-options policy-statement agg_route term 1 from protocol bgpset policy-options policy-statement agg_route term 1 from route-filter 1.1.230.0/23 exactset policy-options policy-statement agg_route term 1 then next-hop 1.1.10.10set policy-options policy-statement agg_route term 1 then acceptset routing-options autonomous-system 65000

Device R2

set interfaces fe-1/2/0 unit 6 family inet address 1.12.0.2/30set interfaces lo0 unit 3 family inet address 10.255.14.177/32set protocols bgp group int type internalset protocols bgp group int local-address 10.255.14.177set protocols bgp group int neighbor 10.255.71.24set protocols ospf area 0.0.0.0 interface fe-1/2/0.6set protocols ospf area 0.0.0.0 interface 10.255.14.177set routing-options autonomous-system 65000

Device R0

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device R0:

  1. Configure the interfaces.
    [edit interfaces fe-1/2/0 unit 1]user@R0# set family inet address 1.1.0.1/30
    [edit interfaces fe-1/2/1 unit 2]user@R0# set family inet address 1.1.1.1/30
    [edit interfaces lo0 unit 1]user@R0# set family inet address 10.255.14.179/32
  2. Configure EBGP.
    [edit protocols bgp group ext]user@R0# set type externaluser@R0# set peer-as 65000user@R0# set neighbor 1.1.0.2user@R0# set neighbor 1.1.1.2
  3. Enable multipath BGP between Device R0 and Device R1.
    [edit protocols bgp group ext]user@R0# set multipath
  4. Configure static routes to remote networks.
    These routes are not part of the topology. The purpose of these routes is to demonstrate the functionality in this example.
    [edit routing-options]user@R0# set static route 1.1.10.10/32 rejectuser@R0# set static route 1.1.230.0/23 reject
  5. Configure routing policies that accept the static routes.
    [edit policy-options policy-statement agg_route term 1]user@R0# set from protocol staticuser@R0# set from route-filter 1.1.230.0/23 exactuser@R0# set then accept
    [edit policy-options policy-statement test_route term 1]user@R0# set from protocol staticuser@R0# set from route-filter 1.1.10.10/32 exactuser@R0# set then accept
  6. Export the agg_route and test_route policies from the routing table into BGP.
    [edit protocols bgp group ext]user@R0# set export test_routeuser@R0# set export agg_route
  7. Configure the autonomous system (AS) number.
    [edit routing-options]user@R0# set autonomous-system 65500

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.

user@R0# show interfaces
fe-1/2/0 {unit 1 {family inet {address 1.1.0.1/30;}}}
fe-1/2/1 {unit 2 {family inet {address 1.1.1.1/30;}}}
lo0 {unit 1 {family inet {address 10.255.14.179/32;}}}
user@R0# show policy-options
policy-statement agg_route {term 1 {from {protocol static;route-filter 1.1.230.0/23 exact;}then accept;}}
policy-statement test_route {term 1 {from {protocol static;route-filter 1.1.10.10/32 exact;}then accept;}}
user@R0# show protocols
bgp {group ext {type external;export [ test_route agg_route ];peer-as 65000;multipath;neighbor 1.1.0.2;neighbor 1.1.1.2;}}
user@R0# show routing-options
static {route 1.1.10.10/32 reject;route 1.1.230.0/23 reject;}
autonomous-system 65500;

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

Configuring Device R1

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device R1:

  1. Configure the interfaces.
    [edit interfaces fe-1/2/0 unit 3]user@R1# set family inet address 1.1.0.2/30
    [edit interfaces fe-1/2/1 unit 4]user@R1# set family inet address 1.12.0.1/30
    [edit interfaces fe-1/2/2 unit 5]user@R1# set family inet address 1.1.1.2/30
    [edit interfaces lo0 unit 2]user@R1# set family inet address 10.255.71.24/32
  2. Configure OSPF.
    [edit protocols ospf area 0.0.0.0]user@R1# set interface fe-1/2/1.4user@R1# set interface 10.255.71.24
  3. Enable Device R1 to accept the remote next hop.
    [edit protocols bgp]user@R1# set accept-remote-nexthop
  4. Configure IBGP.
    [edit protocols bgp group int]user@R1# set type internaluser@R1# set local-address 10.255.71.24user@R1# set neighbor 10.255.14.177
  5. Configure EBGP.
    [edit protocols bgp group ext]user@R1# set type externaluser@R1# set peer-as 65500user@R1# set neighbor 1.1.0.1user@R1# set neighbor 1.1.1.1
  6. Enable multipath BGP between Device R0 and Device R1.
    [edit protocols bgp group ext]user@R1# set multipath
  7. Configure a routing policy that enables a single-hop external BGP peer (Device R1) to accept the remote next-hop 1.1.10.10 for the route to the 1.1.230.0/23 network.
    [edit policy-options policy-statement agg_route term 1]user@R1# set from protocol bgpuser@R1# set from route-filter 1.1.230.0/23 exactuser@R1# set then next-hop 1.1.10.10user@R1# set then accept
  8. Import the agg_route policy into the routing table on Device R1.
    [edit protocols bgp group ext]user@R1# set import agg_route
  9. Configure the autonomous system (AS) number.
    [edit routing-options]user@R1# set autonomous-system 65000

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.

user@R1# show interfaces
fe-1/2/0 {unit 3 {family inet {address 1.1.0.2/30;}}}
fe-1/2/1 {unit 4 {family inet {address 1.12.0.1/30;}}}
fe-1/2/2 {unit 5 {family inet {address 1.1.1.2/30;}}}
lo0 {unit 2 {family inet {address 10.255.71.24/32;}}}
user@R1# show policy-options
policy-statement agg_route {term 1 {from {protocol bgp;route-filter 1.1.230.0/23 exact;}then {next-hop 1.1.10.10;accept;}}}
user@R1# show protocols
bgp {accept-remote-nexthop;group ext {type external;import agg_route;peer-as 65500;multipath;neighbor 1.1.0.1;neighbor 1.1.1.1;}group int {type internal;local-address 10.255.71.24;neighbor 10.255.14.177;}}
ospf {area 0.0.0.0 {interface fe-1/2/1.4;interface 10.255.71.24;}}
user@R1# show routing-optionsautonomous-system 65000;

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

Configuring Device R2

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device R2:

  1. Configure the interfaces.
    [edit interfaces fe-1/2/0 unit 6]user@R2# set family inet address 1.12.0.2/30
    [edit interfaces lo0 unit 3]user@R2# set family inet address 10.255.14.177/32
  2. Configure OSPF.
    [edit protocols ospf area 0.0.0.0]user@R2# set interface fe-1/2/0.6user@R2# set interface 10.255.14.177
  3. Configure IBGP.
    [edit protocols bgp group int]user@R2# set type internaluser@R2# set local-address 10.255.14.177user@R2# set neighbor 10.255.71.24
  4. Configure the autonomous system (AS) number.
    [edit routing-options]user@R1# set autonomous-system 65000

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.

user@R2# show interfaces
fe-1/2/0 {unit 6 {family inet {address 1.12.0.2/30;}}}
lo0 {unit 3 {family inet {address 10.255.14.177/32;}}}
user@R2# show protocols
bgp {group int {type internal;local-address 10.255.14.177;neighbor 10.255.71.24;}}
ospf {area 0.0.0.0 {interface fe-1/2/0.6;interface 10.255.14.177;}}
user@R2# show routing-optionsautonomous-system 65000;

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

Verification

Confirm that the configuration is working properly.

Verifying That the Multipath Route with the Indirect Next Hop Is in the Routing Table

Purpose

Verify that Device R1 has a route to the 1.1.230.0/23 network.

Action

From operational mode, enter the show route 1.1.230.0 extensive command.

user@R1> show route 1.1.230.0 extensive
inet.0: 11 destinations, 13 routes (11 active, 0 holddown, 0 hidden)
Restart Complete
1.1.230.0/23 (2 entries, 1 announced)
TSI:
KRT in-kernel 1.1.230.0/23 -> {indirect(262142)}
Page 0 idx 1 Type 1 val 9168f6c
    Nexthop: 1.1.10.10
    Localpref: 100
    AS path: [65000] 65500 I
    Communities:
Path 1.1.230.0 from 1.1.0.1 Vector len 4.  Val: 1
        *BGP    Preference: 170/-101
                Next hop type: Indirect
                Address: 0x90c44d8
                Next-hop reference count: 4
                Source: 1.1.0.1
                Next hop type: Router, Next hop index: 262143
                Next hop: 1.1.0.1 via fe-1/2/0.3, selected
                Next hop: 1.1.1.1 via fe-1/2/2.5
                Protocol next hop: 1.1.10.10
                Indirect next hop: 91c0000 262142
                State: <Active Ext>
                Local AS: 65000 Peer AS: 65500
                Age: 2:55:31    Metric2: 0 
                Task: BGP_65500.1.1.0.1+64631
                Announcement bits (3): 2-KRT 3-BGP_RT_Background 4-Resolve tree 1 
                AS path: 65500 I
                Accepted Multipath
                Localpref: 100
                Router ID: 10.255.14.179
                Indirect next hops: 1
                        Protocol next hop: 1.1.10.10
                        Indirect next hop: 91c0000 262142
                        Indirect path forwarding next hops: 2
                                Next hop type: Router
                                Next hop: 1.1.0.1 via fe-1/2/0.3
                                Next hop: 1.1.1.1 via fe-1/2/2.5
                        1.1.10.10/32 Originating RIB: inet.0
                          Node path count: 1
                          Forwarding nexthops: 2
                                Nexthop: 1.1.0.1 via fe-1/2/0.3
                                Nexthop: 1.1.1.1 via fe-1/2/2.5
         BGP    Preference: 170/-101
                Next hop type: Indirect
                Address: 0x90c44d8
                Next-hop reference count: 4
                Source: 1.1.1.1
                Next hop type: Router, Next hop index: 262143
                Next hop: 1.1.0.1 via fe-1/2/0.3, selected
                Next hop: 1.1.1.1 via fe-1/2/2.5
                Protocol next hop: 1.1.10.10
                Indirect next hop: 91c0000 262142
                State: <NotBest Ext>
                Inactive reason: Not Best in its group - Update source
                Local AS: 65000 Peer AS: 65500
                Age: 2:55:27    Metric2: 0 
                Task: BGP_65500.1.1.1.1+53260
                AS path: 65500 I
                Accepted
                Localpref: 100
                Router ID: 10.255.14.179
                Indirect next hops: 1
                        Protocol next hop: 1.1.10.10
                        Indirect next hop: 91c0000 262142
                        Indirect path forwarding next hops: 2
                                Next hop type: Router
                                Next hop: 1.1.0.1 via fe-1/2/0.3
                                Next hop: 1.1.1.1 via fe-1/2/2.5
                        1.1.10.10/32 Originating RIB: inet.0
                          Node path count: 1
                          Forwarding nexthops: 2
                                Nexthop: 1.1.0.1 via fe-1/2/0.3
                                Nexthop: 1.1.1.1 via fe-1/2/2.5

Meaning

The output shows that Device R1 has a route to the 1.1.230.0 network with the multipath feature enabled (Accepted Multipath). The output also shows that the route has an indirect next hop of 1.1.10.10.

Deactivating and Reactivating the accept-remote-nexthop Statement

Purpose

Make sure that the multipath route with the indirect next hop is removed from the routing table when you deactivate the accept-remote-nexthop statement.

Action

  1. From configuration mode, enter the deactivate protocols bgp accept-remote-nexthop command.
    user@R1# deactivate protocols bgp accept-remote-nexthop
    user@R1# commit
  2. From operational mode, enter the show route 1.1.230.0 command.
    user@R1> show route 1.1.230.0
  3. From configuration mode, reactivate the statement by entering the activate protocols bgp accept-remote-nexthop command.
    user@R1# activate protocols bgp accept-remote-nexthop
    user@R1# commit
  4. From operational mode, reenter the show route 1.1.230.0 command.
    user@R1> show route 1.1.230.0 
    inet.0: 11 destinations, 13 routes (11 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

1.1.230.0/23       *[BGP/170] 03:13:19, localpref 100
                      AS path: 65500 I
                    > to 1.1.0.1 via fe-1/2/0.3
                      to 1.1.1.1 via fe-1/2/2.5
                    [BGP/170] 03:13:15, localpref 100, from 1.1.1.1
                      AS path: 65500 I
                    > to 1.1.0.1 via fe-1/2/0.3
                      to 1.1.1.1 via fe-1/2/2.5

Meaning

When the accept-remote-nexthop statement is deactivated, the multipath route to the 1.1.230.0 network is removed from the routing table .

 

Related Documentation

 

Published: 2013-07-09

Previous Page Next Page