- Cisco BGP Overview
- BGP 4
- Configuring a Basic BGP Network
- BGP 4 Soft Configuration
- BGP Support for 4-byte ASN
- Connecting to a Service Provider Using External BGP
- BGP Prefix-Based Outbound Route Filtering
- BGP Route-Map Continue
- BGP Route-Map Continue Support for Outbound Policy
- Removing Private AS Numbers from the AS Path in BGP
- Configuring BGP Neighbor Session Options
- BGP Neighbor Policy
- BGP Dynamic Neighbors
- BGP Support for Next-Hop Address Tracking
- BGP Restart Neighbor Session After Max-Prefix Limit Reached
- BGP Support for Dual AS Configuration for Network AS Migrations
- Configuring Internal BGP Features
- BGP VPLS Auto Discovery Support on Route Reflector
- BGP FlowSpec Route-reflector Support
- BGP Support for BFD
- IPv6 Routing: Multiprotocol BGP Extensions for IPv6
- IPv6 Multicast Address Family Support for Multiprotocol BGP
- IPv6 Routing: Multiprotocol BGP Link-Local Address Peering
- IPv6 NSF and Graceful Restart for MP-BGP IPv6 Address Family
- BGP NSF Awareness
- BGP Graceful Restart per Neighbor
- Configuring Multiprotocol BGP (MP-BGP) Support for CLNS
- BGP Link Bandwidth
- iBGP Multipath Load Sharing
- BGP Multipath Load Sharing for Both eBGP and iBGP in an MPLS-VPN
- Loadsharing IP Packets Over More Than Six Parallel Paths
- BGP Policy Accounting
- BGP Policy Accounting Output Interface Accounting
- BGP Cost Community
- Regex Engine Performance Enhancement
- BGP Support for IP Prefix Import from Global Table into a VRF Table
- BGP Support for IP Prefix Export from a VRF Table into the Global Table
- BGP per Neighbor SoO Configuration
- BGP Next Hop Unchanged
- Per-VRF Assignment of BGP Router ID
- BGP Event-Based VPN Import
- BGP Support for the L2VPN Address Family
- Detecting and Mitigating a BGP Slow Peer
- Configuring BGP: RT Constrained Route Distribution
- Configuring BGP Consistency Checker
- BGP—Origin AS Validation
- BGP Support for NSR with SSO
- BGP NSR Auto Sense
- BGP NSR Support for iBGP Peers
- BGP Graceful Shutdown
- BGP — mVPN BGP sAFI 129 - IPv4
- BGP-MVPN SAFI 129 IPv6
- BGP Attribute Filter and Enhanced Attribute Error Handling
- BGP Additional Paths
- BGP-RT and VPN Distinguisher Attribute Rewrite Wildcard
- BGP—Selective Route Download
- BFD—BGP Multihop Client Support, cBit (IPv4 and IPv6), and Strict Mode
- BGP MIB Support
- BGP 4 MIB Support for per-Peer Received Routes
- BGP PIC Edge for IP and MPLS-VPN
- BGP IPv6 PIC Edge and Core for IP/MPLS
- BGP Unified MPLS iBGP Client
- Cisco-BGP-MIBv2
- BGP Diverse Path Using a Diverse-Path Route Reflector
- BGP-VRF-Aware Conditional Advertisement
- BGP—Support for iBGP Local-AS
- IOS-XE IBGP local-as dual-as
- VPLS BGP Signaling
- BGP NSR Support for MPLS VPNv4 and VPNv6 Inter-AS Option B
- L3VPN iBGP PE-CE
- eiBGP Multipath for Non-VRF Interfaces (IPv4/IPv6)
- BGP-RTC for Legacy PE
- BGP PBB EVPN Route Reflector Support
- BGP Monitoring Protocol
- VRF Aware BGP Translate-Update
- BGP Support for MTR
- BGP Accumulated IGP
BGP—Origin AS Validation
The BGP—Origin AS Validation feature helps prevent network administrators from inadvertently advertising routes to networks they do not control. This feature uses a Resource Public Key Infrastructure (RPKI) server to authenticate that certain BGP prefixes originated from an expected autonomous system before the prefixes are allowed to be advertised.
- Finding Feature Information
- Information About BGP Origin AS Validation
- How to Configure BGP Origin AS Validation
- Configuration Examples for BGP Origin AS Validation
- Additional References
- Feature Information for BGP - Origin AS Validation
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Information About BGP Origin AS Validation
Benefit of BGP—Origin AS Validation
Occasionally network administrators have unintentionally advertised routes to networks that they do not control. This security issue can be avoided by configuring the BGP—Origin AS Validation feature. This feature uses an RPKI server to authenticate certain BGP prefixes as having originated from an expected autonomous system before prefixes are accepted.
How BGP—Origin AS Validation Works
The network administrator must set up a Resource Public Key Infrastructure (RPKI) server, using third-party software. The RPKI server handles the actual authentication of public key certificates. The server is set up so that certain prefixes or prefix ranges are allowed to originate from certain autonomous systems.
The administrator then configures the router to establish a TCP connection to the RPKI server. This is done by configuring the bgp rpki server command. Upon such configuration or booting the router, the router opens a TCP connection to the indicated IP address and port number. The router downloads a list of prefixes and permitted origin AS numbers from one or more router/RPKI servers using the RPKI-Router protocol (RTR). Thus, the router obtains information from the server about which autonomous systems are permitted to advertise which routes, that is, from which AS a route may originate.
If the TCP connection attempt fails, the router retries the connection once per minute. In the meantime, BGP will behave without performing origin validation.
After the TCP session between the router and the server is established, the server will normally send to the router incremental updates with new prefixes that have been added to the RPKI database. The router might also query the server every refresh interval. The router will not send a serial query message or reset query message during the interval between when it sends a serial query or reset query and when it receives an End of Data (EOD) message. Serial queries in this interval are stripped, and reset queries in this interval are sent upon receipt of the EOD message.
A prefix or prefix range and the origin-AS corresponding to it are considered an SOVC record. Overlapping prefix ranges are allowed. An SOVC table containing three records might look like this:
10.0.1.0/20-25 AS 3
10.0.1.0/19-24 AS 4
10.0.1.0/23-27 AS 5
When a prefix (network) is received from an external BGP (eBGP) peer, the prefix is initially placed in the Not Found state. It is then examined and marked as Valid, Invalid, or Not Found:
Valid—Indicates the prefix and AS pair are found in the SOVC table.
Invalid—Indicates the prefix meets either of the following two conditions: 1. It matches one or more Route Origin Authorizations (ROAs), but there is no matching ROA where the origin AS matches the origin AS on the AS-PATH. 2. It matches the one or more ROAs at the minimum-length specified in the ROA, but for all ROAs where it matches the minimum length, it is longer than the specified maximum length. Origin AS does not matter for condition #2.
Not Found—Indicates the prefix is not among the valid or invalid prefixes.
By default, a prefix that is marked Invalid is not advertised to any peer, will be withdrawn from the BGP routing table if it was already advertised, and will not be flagged as a bestpath or considered as a candidate for multipath (unless a BGP bestpath command indicates otherwise). Unless a BGP bestpath command is configured indicating otherwise, the bestpath computation prefers Valid prefixes over Not Found prefixes, and both types of prefixes are advertised.
A prefix marked as Valid is installed in the BGP routing table.
By default, a prefix marked as Not Found is installed in the BGP routing table and will only be flagged as a bestpath or considered as a candidate for multipath if there is no Valid alternative (independently of other BGP attributes such as Local Preference or ASPATH).
If more than one RPKI server is configured, the router will connect to all configured servers and download prefix information from all of them. The SOVC table will be made of the union of all the records received from the different servers.
Once the bgp rpki server command (or the neighbor announce rpki state command) is configured for an address family, the router starts doing RPKI validation for every path in that address family.
Use of the Validation State in BGP Best Path Determination
There are two ways you can modify the default BGP best path selection process when using RPKI validation states:
You can completely disable the validation of prefixes by the RPKI server and the storage of that validation information. This is done by configuring the bgp bestpath prefix-validate disable command. You might want to do this for configuration testing. The router will still connect to the RPKI server and download the validation information, but will not use the information.
You can allow an invalid prefix to be used as the BGP best path, even if valid prefixes are available. This is the default behavior. The command to allow a BGP best path to be an invalid prefix, as determined by the BGP Origin AS Validation feature, is the bgp bestpath prefix-validate allow-invalid command. The prefix validation state will still be assigned to paths, and will still be communicated to iBGP neighbors that have been configured to receive RPKI state information. You can use a route map to set a local preference, metric, or other property based on the validation state.
During BGP best path selection, the default behavior, if neither of the above options is configured, is that the system will prefer prefixes in the following order:
Those with a validation state of valid.
Those with a validation state of not found.
Those with a validation state of invalid (which, by default, will not be installed in the routing table).
These preferences override metric, local preference, and other choices made during the bestpath computation. The standard bestpath decision tree applies only if the validation state of the two paths is the same.
If both commands are configured, the bgp bestpath prefix-validate disable command will prevent the validation state from being assigned to paths, so the bgp bestpath prefix-validate allow-invalid command will have no effect.
These configurations can be in either router configuration mode or in address family configuration mode for the IPv4 unicast or IPv6 unicast address families.
Use of a Route Map to Customize Treatment of Valid and Invalid Prefixes
You can create a route map to match on any of the RPKI states, and thereby create a custom policy for handling valid or invalid prefixes.
By default, the router overrides all other preferences to reject routes that are in an invalid state. You must explicitly configure the bgp bestpath prefix-validate allow-invalid command if you want to use a route map to do something such as permit such prefixes, but with a nondefault local preference.
How to Configure BGP Origin AS Validation
Enabling BGP—Origin AS Validation
1.
enable
2.
configure
terminal
3.
router
bgp
autonomous-system-number
4.
bgp
rpki
server
tcp {ipv4-address
|
ipv6-address}
port
port-number
refresh
seconds
DETAILED STEPS
Announcing the RPKI State to iBGP Neighbors
Perform this task to cause the router to announce the RPKI state with routes to its iBGP neighbors in the BGP extended community attribute and to also receive the RPKI state with routes from iBGP neighbors. This task might be more convenient than configuring the BGP—Origin AS Validation feature on the router.
1.
enable
2.
configure
terminal
3.
router
bgp
autonomous-system-number
4.
neighbor
{ip-address | ipv6-address}
send-community
extended
5.
neighbor
{ip-address | ipv6-address}
announce
rpki
state
DETAILED STEPS
Disabling the Validation of BGP Prefixes, But Still Downloading RPKI Information
Perform this task if the BGP—Origin AS Validation feature is enabled, but you want to disable the validation of prefixes based on origin AS and disable the storage of validation information. The router will still connect to the RPKI server and still download the validation information, but the information will not be used in any way. This task is useful for configuration testing.
1.
enable
2.
configure
terminal
3.
router
bgp
autonomous-system-number
4.
address-family
{ipv4 |
ipv6}
unicast
5.
bgp
bestpath
prefix-validate
disable
DETAILED STEPS
Allowing Invalid Prefixes as the Best Path
Perform this task if the BGP—Origin AS Validation feature is enabled, and you want to allow invalid prefixes to be used as the best path, even if valid prefixes are available. Thus, you have control over announcing invalid networks, but preferring them less than valid and not-found prefixes. Also, the downstream peer can modify path attributes based on a route map that matches invalid prefixes.
1.
enable
2.
configure
terminal
3.
router
bgp
autonomous-system-number
4.
address-family
{ipv4 |
ipv6}
unicast
5.
bgp
bestpath
prefix-validate
allow-invalid
DETAILED STEPS
Configuring a Route Map Based on RPKI States
Perform this task to create a route map based on RPKI states. The route map in this particular task sets a policy for all three RPKI states based on local preference, but other set commands can be used to set a policy. This task does not include a command that makes use of this route map.
1.
enable
2.
configure
terminal
3.
router
bgp
autonomous-system-number
4.
address-family
{ipv4 |
ipv6}
unicast
5.
bgp
bestpath
prefix-validate
allow-invalid
6.
exit
7.
exit
8.
route-map
map-tag
{permit |
deny} [sequence-number]
9.
match
rpki
{not-found |
invalid |
valid}
10.
set
local-preference
number
11.
exit
12.
route-map
map-tag
{permit |
deny} [sequence-number]
13.
match
rpki
{not-found |
invalid |
valid}
14.
set
local-preference
number
15.
exit
16.
route-map
map-tag
{permit |
deny} [sequence-number]
17.
match
rpki
{not-found |
invalid |
valid}
18.
set
local-preference
number
19.
exit
20.
route-map
map-tag
{permit |
deny} [sequence-number]
21.
end
DETAILED STEPS
Configuration Examples for BGP Origin AS Validation
Example: Configuring BGP to Validate Prefixes Based on Origin AS
In the following example, the router is configured to connect to two RPKI servers, from which it will receive SOVC records of BGP prefixes and AS numbers.
router bgp 65000 no bgp log-neighbor changes bgp rpki server tcp 10.0.96.254 port 32001 refresh 600 bgp rpki server tcp FEC0::1002 port 32002 refresh 600
Example: Announcing RPKI State to Neighbors
router bgp 65000 neighbor 10.10.10.10 remote-as 65000 address-family ipv4 unicast neighbor 10.10.10.10 send-community extended neighbor 10.10.10.10 announce rpki state
Example: Disabling the Checking of Prefixes
The following example, for the IPv4 address family, disables the checking of prefixes to ensure they are valid. It also disables the storage of validation information. However, the router will still connect to the RPKI server and download the validation information. This example is useful for configuration testing.
router bgp 65000 bgp rpki server tcp 10.0.96.254 port 32001 refresh 600 address-family ipv4 unicast bgp bestpath prefix-validate disable
Example: Allowing Invalid Prefixes as Best Path
In the following example, for the IPv6 address family, invalid prefixes are allowed to be used as the best path, even if valid prefixes are available.
router bgp 65000 bgp rpki server tcp FEC0::1002 port 32002 refresh 600 address-family ipv6 unicast bgp bestpath prefix-validate allow-invalid
Example: Using a Route Map Based on RPKI State
In the following example, a route map named rtmap-PEX1-3 sets a local preference of 50 for invalid prefix/AS pairs, 100 for not-found prefix/AS pairs, and 200 for valid prefix/AS pairs. The local preference values are set for incoming routes from the neighbor at 10.0.102.1. The neighbor at 10.0.102.1 is an eBGP peer. Note that the bgp bestpath prefix-validate allow-invalid command is required in order to permit invalid prefixes.
router bgp 65000 address-family ipv4 unicast neighbor 10.0.102.1 route-map rtmap-PEX1-3 in bgp bestpath prefix-validate allow-invalid ! route-map rtmap-PEX1-3 permit 10 match rpki invalid set local-preference 50 ! route-map rtmap-PEX1-3 permit 20 match rpki not-found set local-preference 100 ! route-map rtmap-PEX1-3 permit 30 match rpki valid set local-preference 200 ! route-map rtmap-PEX1-3 permit 40
Additional References
Related Documents
Related Topic |
Document Title |
---|---|
Cisco IOS commands |
|
BGP commands |
Technical Assistance
Description |
Link |
---|---|
The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password. |
Feature Information for BGP - Origin AS Validation
The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.Feature Name |
Releases |
Feature Information |
---|---|---|
BGP - Origin AS Validation |
Cisco IOS 15.2(1)S 15.2(4)S |
This feature allows the router to connect to an RPKI server and download a list of prefixes and permitted origin AS numbers. The following commands were introduced: bgp bestpath prefix-validate, bgp rpki server, clear ip bgp rpki server, debug ip bgp event rpki, match rpki, neighbor announce rpki state, show ip bgp rpki servers, show ip bgp rpki table. The following commands were modified: show ip bgp, show ip bgp ipv4, show ip bgp ipv6 unicast, show ip bgp summary. |