Example: Configuring BGP Route Advertisement
Configuring Routing Policies to Control BGP Route Advertisements
All routing protocols use the Junos OS routing table to store the routes that they learn and to determine which routes they should advertise in their protocol packets. Routing policy allows you to control which routes the routing protocols store in and retrieve from the routing table. For information about routing policy, see the Routing Policies, Firewall Filters, and Traffic Policers Feature Guide.
When configuring BGP routing policy, you can perform the following tasks:
Configuring BGP to Advertise the Best External Route to Internal Peers
Configuring How Often BGP Exchanges Routes with the Routing Table
Applying Routing Policy
You define routing policy at the [edit policy-options] hierarchy level. To apply policies you have defined for BGP, include the import and export statements within the BGP configuration.
You can apply policies as follows:
BGP global import and export statements—Include these statements at the [edit protocols bgp] hierarchy level (for routing instances, include these statements at the [edit routing-instances routing-instance-name protocols bgp] hierarchy level).
Group import and export statements—Include these statements at the [edit protocols bgp group group-name] hierarchy level (for routing instances, include these statements at the [edit routing-instances routing-instance-name protocols bgp group group-name] hierarchy level).
Peer import and export statements—Include these statements at the [edit protocols bgp group group-name neighbor address] hierarchy level (for routing instances, include these statements at the [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address] hierarchy level).
A peer-level import or export statement overrides a group import or export statement. A group-level import or export statement overrides a global BGP import or export statement.
To apply policies, see the following sections:
Applying Policies to Routes Being Imported into the Routing Table from BGP
Applying Policies to Routes Being Exported from the Routing Table into BGP
Applying Policies to Routes Being Imported into the Routing Table from BGP
To apply policy to routes being imported into the routing table from BGP, include the import statement, listing the names of one or more policies to be evaluated:
For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.
If you specify more than one policy, they are evaluated in the order specified, from first to last, and the first matching filter is applied to the route. If no match is found, BGP places into the routing table only those routes that were learned from BGP routing devices.
Applying Policies to Routes Being Exported from the Routing Table into BGP
To apply policy to routes being exported from the routing table into BGP, include the export statement, listing the names of one or more policies to be evaluated:
For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.
If you specify more than one policy, they are evaluated in the order specified, from first to last, and the first matching filter is applied to the route. If no routes match the filters, the routing table exports into BGP only the routes that it learned from BGP.
Setting BGP to Advertise Inactive Routes
By default, BGP stores the route information it receives from update messages in the Junos OS routing table, and the routing table exports only active routes into BGP, which BGP then advertises to its peers. To have the routing table export to BGP the best route learned by BGP even if Junos OS did not select it to be an active route, include the advertise-inactive statement:
For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.
Configuring BGP to Advertise the Best External Route to Internal Peers
In general, deployed BGP implementations do not advertise the external route with the highest local preference value to internal peers unless it is the best route. Although this behavior was required by an earlier version of the BGP version 4 specification, RFC 1771, it was typically not followed in order to minimize the amount of advertised information and to prevent routing loops. However, there are scenarios in which advertising the best external route is beneficial, in particular, situations that can result in IBGP route oscillation.
In Junos OS Release 9.3 and later, you can configure BGP to advertise the best external route into an internal BGP (IBGP) mesh group, a route reflector cluster, or an autonomous system (AS) confederation, even when the best route is an internal route.
In order to configure the advertise-external statement on a route reflector, you must disable intracluster reflection with the no-client-reflect statement.
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.
In a confederation, when advertising a route to a confederation border router, any route from a different confederation sub-AS is considered external.
You can also configure BGP to advertise the external route only if the route selection process reaches the point where the multiple exit discriminator (MED) metric is evaluated. As a result, an external route with an AS path worse (that is, longer) than that of the active path is not advertised.
Junos OS also provides support for configuring a BGP export policy that matches on the state of an advertised route. You can match on either active or inactive routes. For more information, see the Routing Policies, Firewall Filters, and Traffic Policers Feature Guide.
To configure BGP to advertise the best external path to internal peers, include the advertise-external statement:
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.
For a complete list of hierarchy levels at which you can configure this statement, see the statement summary section for this statement.
To configure BGP to advertise the best external path only if the route selection process reaches the point where the MED value is evaluated, include the conditional statement:
Configuring How Often BGP Exchanges Routes with the Routing Table
BGP stores the route information it receives from update messages in the routing table, and the routing table exports active routes from the routing table into BGP. BGP then advertises the exported routes to its peers. By default, the exchange of route information between BGP and the routing table occurs immediately after the routes are received. This immediate exchange of route information might cause instabilities in the network reachability information. To guard against this, you can delay the time between when BGP and the routing table exchange route information.
To configure how often BGP and the routing table exchange route information, include the out-delay statement:
By default, the routing table retains some of the route information learned from BGP. To have the routing table retain all or none of this information, include the keep statement:
For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements.
The routing table can retain the route information learned from BGP in one of the following ways:
Default (omit the keep statement)—Keep all route information that was learned from BGP, except for routes whose AS path is looped and whose loop includes the local AS.
keep all—Keep all route information that was learned from BGP.
keep none—Discard routes that were received from a peer and that were rejected by import policy or other sanity checking, such as AS path or next hop. When you configure keep none for the BGP session and the inbound policy changes, Junos OS forces readvertisement of the full set of routes advertised by the peer.
In an AS path healing situation, routes with looped paths theoretically could become usable during a soft reconfiguration when the AS path loop limit is changed. However, there is a significant memory usage difference between the default and keep all.
Consider the following scenarios:
A peer readvertises routes back to the peer from which it learned them.
This can happen in the following cases:
Another vendor's routing device advertises the routes back to the sending peer.
The Junos OS peer’s default behavior of not readvertising routes back to the sending peer is overridden by configuring advertise-peer-as.
A provider edge (PE) routing device discards any VPN route that does not have any of the expected route targets.
When keep all is configured, the behavior of discarding routes received in the above scenarios is overridden.
Disabling Suppression of Route Advertisements
Junos OS does not advertise the routes learned from one EBGP peer back to the same external BGP (EBGP) peer. In addition, the software does not advertise those routes back to any EBGP peers that are in the same AS as the originating peer, regardless of the routing instance. You can modify this behavior by including the advertise-peer-as statement in the configuration. To disable the default advertisement suppression, include the advertise-peer-as statement:
The route suppression default behavior is disabled if the as-override statement is included in the configuration.
If you include the advertise-peer-as statement in the configuration, BGP advertises the route regardless of this check.
To restore the default behavior, include the no-advertise-peer-as statement in the configuration:
If you include both the as-override and no-advertise-peer-as statements in the configuration, the no-advertise-peer-as statement is ignored. You can include these statements at multiple hierarchy levels.
For a list of hierarchy levels at which you can include these statements, see the statement summary section for these statements.
Example: Configuring BGP Prefix-Based Outbound Route Filtering
This example shows how to configure a Juniper Networks router to accept route filters from remote peers and perform outbound route filtering using the received filters.
Requirements
Before you begin:
Configure the router interfaces.
Configure an interior gateway protocol (IGP).
Overview
You can configure a BGP peer to accept route filters from remote peers and perform outbound route filtering using the received filters. By filtering out unwanted updates, the sending peer saves resources needed to generate and transmit updates, and the receiving peer saves resources needed to process updates. This feature can be useful, for example, in a virtual private network (VPN) in which subsets of customer edge (CE) devices are not capable of processing all the routes in the VPN. The CE devices can use prefix-based outbound route filtering to communicate to the provider edge (PE) routing device to transmit only a subset of routes, such as routes to the main data centers only.
The maximum number of prefix-based outbound route filters that a BGP peer can accept is 5000. If a remote peer sends more than 5000 outbound route filters to a peer address, the additional filters are discarded, and a system log message is generated.
You can configure interoperability for the routing device as a whole or for specific BGP groups or peers only.
Topology
In the sample network, Device CE1 is a router from another vendor. The configuration shown in this example is on Juniper Networks Router PE1.
Figure 1 shows the sample network.
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.
PE1
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 Router PE1 to accept route filters from Device CE1 and perform outbound route filtering using the received filters:
- Configure the local autonomous system.content_copy zoom_out_map[edit routing-options]user@PE1# set autonomous-system 65500
- Configure external peering with Device CE1.content_copy zoom_out_map[edit protocols bgp group cisco-peers]user@PE1# set type externaluser@PE1# set description “to CE1”user@PE1# set local-address 192.168.165.58user@PE1# set peer-as 35user@PE1# set neighbor 192.168.165.56
- Configure Router PE1 to accept IPv4 route filters from
Device CE1 and perform outbound route filtering using the received
filters.content_copy zoom_out_map[edit protocols bgp group cisco-peers]user@PE1# set outbound-route-filter prefix-based accept inet
- (Optional) Enable interoperability with routing devices
that use the vendor-specific compatibility code of 130 for outbound
route filters and the code type of 128.
The IANA standard code is 3, and the standard code type is 64.
content_copy zoom_out_map[edit protocols bgp group cisco-peers]user@PE1# set outbound-route-filter bgp-orf-cisco-mode
Results
From configuration mode, confirm your configuration by entering the 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 the Outbound Route Filter
Purpose
Display information about the prefix-based outbound route filter received from Device CE1.
Action
From operational mode, enter the show bgp neighbor orf detail command.
user@PE1> show bgp neighbor orf 192.168.165.56
detail Peer: 192.168.165.56 Type: External
Group: cisco-peers
inet-unicast
Filter updates recv: 4 Immediate: 0
Filter: prefix-based receive
Updates recv: 4
Received filter entries:
seq 10 2.2.0.0/16 deny minlen 0 maxlen 0
seq 20 3.3.0.0/16 deny minlen 24 maxlen 0
seq 30 4.4.0.0/16 deny minlen 0 maxlen 28
seq 40 5.5.0.0/16 deny minlen 24 maxlen 28
Verifying the BGP Neighbor Mode
Purpose
Verify that the bgp-orf-cisco-mode setting is enabled for the peer by making sure that the ORFCiscoMode option is displayed in the show bgp neighbor command output.
Action
From operational mode, enter the show bgp neighbor command.
user@PE1> show bgp neighborPeer: 192.168.165.56 AS 35 Local: 192.168.165.58 AS 65500 Type: External State: Active Flags: <> Last State: Idle Last Event: Start Last Error: None Export: [ adv_stat ] Options: <Preference LocalAddress AddressFamily PeerAS Refresh> Options: <ORF ORFCiscoMode> Address families configured: inet-unicast Local Address: 192.168.165.58 Holdtime: 90 Preference: 170 Number of flaps: 0 Trace options: detail open detail refresh Trace file: /var/log/orf size 5242880 files 20
