ON THIS PAGE
Example: Configuring a Routing Policy to Advertise the Best External Route to Internal Peers
The BGP protocol specification, as defined in RFC 1771, specifies that a BGP peer shall advertise to its internal peers the higher preference external path, even if this path is not the overall best (in other words, even if the best path is an internal path). In practice, deployed BGP implementations do not follow this rule. The reasons for deviating from the specification are as follows:
Minimizing the amount of advertised information. BGP scales according to the number of available paths.
Avoiding routing and forwarding loops.
There are, however, several scenarios in which the behavior, specified in RFC 1771, of advertising the best external route might be beneficial. Limiting path information is not always desirable as path diversity might help reduce restoration times. Advertising the best external path can also address internal BGP (IBGP) route oscillation issues as described in RFC 3345, Border Gateway Protocol (BGP) Persistent Route Oscillation Condition.
The advertise-external
statement modifies the behavior
of a BGP speaker to advertise the best external path to IBGP peers,
even when the best overall path is an internal path.
The advertise-external
statement is supported
at both the group and neighbor level. If you configure the statement
at the neighbor level, you must configure it for all neighbors in
a group. Otherwise, the group is automatically split into different
groups.
The conditional
option limits the behavior of the advertise-external
setting, such that the external route is
advertised only if the route selection process reaches the point where
the multiple exit discriminator (MED) metric is evaluated. Thus, an
external route is not advertised if it has, for instance, an AS path
that is worse (longer) than that of the active path. The conditional
option restricts external path advertisement to when the best external
path and the active path are equal until the MED step of the route
selection process. Note that the criteria used for selecting the best
external path is the same whether or not the conditional
option is configured.
Junos OS also provides support for configuring a BGP export policy that matches the state of an advertised route. You can match either active or inactive routes, as follows:
policy-options { policy-statement name{ from state (active|inactive); } }
This qualifier only matches when used in the context of an export
policy. When a route is being advertised by a protocol that can advertise
inactive routes (such as BGP), state inactive
matches routes
advertised as a result of the advertise-inactive
and advertise-external
statements.
For example, the following configuration can be used
as a BGP export policy toward internal peers to mark routes advertised
due to the advertise-external
setting with a user-defined
community. That community can be later used by the receiving routers
to filter out such routes from the forwarding table. Such a mechanism
can be used to address concerns that advertising paths not used for
forwarding by the sender might lead to forwarding loops.
user@host# show policy-options policy-statement mark-inactive { term inactive { from state inactive; then { community set comm-inactive; } } term default { from protocol bgp; then accept; } then reject; } community comm-inactive members 65536:65284;
Requirements
Junos OS 9.3 or later is required.
Overview
This example shows three routing devices. Device R2 has an external BGP (EBGP) connection to Device R1. Device R2 has an IBGP connection to Device R3.
Device R1 advertises 172.16.6.0/24. Device R2 does not set the local preference in an import policy for Device R1’s routes, and thus 172.16.6.0/24 has the default local preference of 100.
Device R3 advertises 172.16.6.0/24 with a local preference of 200.
When the advertise-external
statement is not configured
on Device R2, 172.16.6.0/24 is not advertised by Device R2 toward
Device R3.
When the advertise-external
statement is configured
on Device R2 on the session toward Device R3, 172.16.6.0/24 is advertised
by Device R2 toward Device R3.
When advertise-external conditional
is configured
on Device R2 on the session toward Device R3, 172.16.6.0/24 is not
advertised by Device R2 toward Device R3. If you remove the then
local-preference 200
setting on Device R3 and add the path-selection
as-path-ignore
setting on Device R2 (thus making the path selection
criteria equal until the MED step of the route selection process),
172.16.6.0/24 is advertised by Device R2 toward Device R3.
To configure the advertise-external
statement
on a route reflector, you must disable intracluster reflection with
the no-client-reflect
statement, and the client cluster must be fully meshed to
prevent the sending of redundant route advertisements.
When a routing device is configured as a route reflector for a cluster, a route advertised by the route reflector is considered internal if it is received from an internal peer with the same cluster identifier or if both peers have no cluster identifier configured. A route received from an internal peer that belongs to another cluster, that is, with a different cluster identifier, is considered external.
Topology
Figure 1 shows the sample network.
CLI Quick Configuration shows the configuration for all of the devices in Figure 1.
The section #configuration148__policy-advertise-external-st describes the steps on Device R2.
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 R1
set interfaces fe-1/2/0 unit 0 description to-R2 set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.1/30 set interfaces lo0 unit 0 family inet address 192.168.0.1/32 set protocols bgp group ext type external set protocols bgp group ext export send-static set protocols bgp group ext peer-as 200 set protocols bgp group ext neighbor 10.0.0.2 set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 from route-filter 172.16.6.0/24 exact set policy-options policy-statement send-static term 1 then accept set policy-options policy-statement send-static term 2 then reject set routing-options static route 172.16.6.0/24 reject set routing-options router-id 192.168.0.1 set routing-options autonomous-system 100
Device R2
set interfaces fe-1/2/0 unit 0 description to-R1 set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.2/30 set interfaces fe-1/2/1 unit 0 description to-R3 set interfaces fe-1/2/1 unit 0 family inet address 10.0.0.5/30 set interfaces lo0 unit 0 family inet address 192.168.0.2/32 set protocols bgp group ext type external set protocols bgp group ext peer-as 100 set protocols bgp group ext neighbor 10.0.0.1 set protocols bgp group int type internal set protocols bgp group int local-address 192.168.0.2 set protocols bgp group int advertise-external set protocols bgp group int neighbor 192.168.0.3 set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set routing-options router-id 192.168.0.2 set routing-options autonomous-system 200
Device R3
set interfaces fe-1/2/0 unit 6 family inet address 10.0.0.6/30 set interfaces lo0 unit 0 family inet address 192.168.0.3/32 set protocols bgp group int type internal set protocols bgp group int local-address 192.168.0.3 set protocols bgp group int export send-static set protocols bgp group int neighbor 192.168.0.2 set protocols ospf area 0.0.0.0 interface fe-1/2/0.6 set protocols ospf area 0.0.0.0 interface lo0.0 passive set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 then local-preference 200 set policy-options policy-statement send-static term 1 then accept set routing-options static route 172.16.6.0/24 reject set routing-options static route 0.0.0.0/0 next-hop 10.0.0.5 set routing-options autonomous-system 200
Procedure
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 Junos OS CLI User Guide.
To configure Device R2:
Configure the device interfaces.
[edit interfaces] user@R2# set fe-1/2/0 unit 0 description to-R1 user@R2# set fe-1/2/0 unit 0 family inet address 10.0.0.2/30 user@R2# set fe-1/2/1 unit 0 description to-R3 user@R2# set fe-1/2/1 unit 0 family inet address 10.0.0.5/30 user@R2# set lo0 unit 0 family inet address 192.168.0.2/32
Configure OSPF or another interior gateway protocol (IGP).
[edit protocols ospf area 0.0.0.0] user@R2# set interface fe-1/2/1.0 user@R2# set interface lo0.0 passive
Configure the EBGP connection to Device R1.
[edit protocols bgp group ext] user@R2# set type external user@R2# set peer-as 100 user@R2# set neighbor 10.0.0.1
Configure the IBGP connection to Device R3.
[edit protocols bgp group int] user@R2# set type internal user@R2# set local-address 192.168.0.2 user@R2# set neighbor 192.168.0.3
Add the
advertise-external
statement to the IBGP group peering session.[edit protocols bgp group int] user@R2# set advertise-external
Configure the autonomous system (AS) number and the router ID.
[edit routing-options ] user@R2# set router-id 192.168.0.2 user@R2# set autonomous-system 200
Results
From configuration mode, confirm your configuration
by entering the show interfaces
, show protocols
, show policy-options
, and show routing-options
commands. If the output does not display the intended configuration,
repeat the instructions in this example to correct the configuration.
user@R2# show interfaces fe-1/2/0 { unit 0{ description to-R1; family inet { address 10.0.0.2/30; } } } fe-1/2/1 { unit 0 { description to-R3; family inet { address 10.0.0.5/30; } } } lo0 { unit 0 { family inet { address 192.168.0.2/32; } } }
user@R2# show protocols bgp { group ext { type external; peer-as 100; neighbor 10.0.0.1; } group int { type internal; local-address 192.168.0.2; advertise-external; neighbor 192.168.0.3; } } ospf { area 0.0.0.0 { interface fe-1/2/1.0; interface lo0.0 { passive; } } }
user@R2# show routing-options router-id 192.168.0.2; autonomous-system 200;
If you are done configuring the device, enter commit
from configuration mode.
Verification
Confirm that the configuration is working properly.
- Verifying the BGP Active Path
- Verifying the External Route Advertisement
- Verifying the Route on Device R3
- Experimenting with the conditional Option
Verifying the BGP Active Path
Purpose
On Device R2, make sure that the 172.16.6.0/24 prefix is in the routing table and has the expected active path.
Action
user@R2> show route 172.16.6 inet.0: 8 destinations, 9 routes (8 active, 1 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.6.0/24 *[BGP/170] 00:00:07, localpref 200, from 192.168.0.3 AS path: I, validation-state: unverified > to 10.0.0.6 via fe-1/2/1.0 [BGP/170] 03:23:03, localpref 100 AS path: 100 I, validation-state: unverified > to 10.0.0.1 via fe-1/2/0.0
Meaning
Device R2 receives the 172.16.6.0/24 route from both Device R1 and Device R3. The route from Device R3 is the active path, as designated by the asterisk (*). The active path has the highest local preference. Even if the local preferences of the two routes were equal, the route from Device R3 would remain active because it has the shortest AS path.
Verifying the External Route Advertisement
Purpose
On Device R2, make sure that the 172.16.6.0/24 route is advertised toward Device R3.
Action
user@R2> show route advertising-protocol bgp 192.168.0.3 inet.0: 8 destinations, 9 routes (8 active, 1 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 172.16.6.0/24 10.0.0.1 100 100 I
Meaning
Device R2 is advertising the 172.16.6.0/24 route toward Device R3.
Verifying the Route on Device R3
Purpose
Make sure that the 172.16.6.0/24 prefix is in Device R3’s routing table.
Action
user@R3> show route 172.16.6.0/24 inet.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.6.0/24 *[Static/5] 03:34:14 Reject [BGP/170] 06:34:43, localpref 100, from 192.168.0.2 AS path: 100 I, validation-state: unverified > to 10.0.0.5 via fe-1/2/0.6
Meaning
Device R3 has the static route and the BGP route for 172.16.6.0/24.
Note that the BGP route is hidden on Device R3 if the route
is not reachable or if the next hop cannot be resolved. To fulfill
this requirement, this example includes a static default route on
Device R3 (static route 0.0.0.0/0 next-hop 10.0.0.5
).
Experimenting with the conditional Option
Purpose
See how the conditional
option works in
the context of the BGP path selection algorithm.
Action
On Device R2, add the
conditional
option.[edit protocols bgp group int] user@R2# set advertise-external conditional user@R2# commit
On Device R2, check to see if the 172.16.6.0/24 route is advertised toward Device R3.
user@R2> show route advertising-protocol bgp 192.168.0.3
As expected, the route is no longer advertised. You might need to wait a few seconds to see this result.
On Device R3, deactivate the
then local-preference
policy action.[edit policy-options policy-statement send-static term 1] user@R3# deactivate logical-systems R3 then local-preference user@R3# commit
On Device R2, ensure that the local preferences of the two paths are equal.
user@R2> show route 172.16.6.0/24 inet.0: 8 destinations, 9 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.6.0/24 *[BGP/170] 08:02:59, localpref 100 AS path: 100 I, validation-state: unverified > to 10.0.0.1 via fe-1/2/0.0 [BGP/170] 00:07:51, localpref 100, from 192.168.0.3 AS path: I, validation-state: unverified > to 10.0.0.6 via fe-1/2/1.0
On Device R2, add the
as-path-ignore
statement.[edit protocols bgp] user@R2# set path-selection as-path-ignore user@R2# commit
On Device R2, check to see if the 172.16.6.0/24 route is advertised toward Device R3.
user@R2> show route advertising-protocol bgp 192.168.0.3 inet.0: 8 destinations, 9 routes (8 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.6.0/24 10.0.0.1 100 100 I
As expected, the route is now advertised because the AS path length is ignored and because the local preferences are equal.