
- •Table of Contents
- •About the Technical Reviewers
- •Acknowledgments
- •Introduction
- •Objectives
- •Audience
- •Organization
- •Approach
- •Features and Text Conventions
- •Command Syntax Conventions
- •Icons Used in This Book
- •Origins and Recent History of the Internet
- •Network Access Points
- •Routing Arbiter Project
- •The Very High-Speed Backbone Network Service
- •Transitioning the Regional Networks from the NSFNET
- •NSF Solicits NIS Managers
- •Other Internet Registries
- •Internet Routing Registries
- •The Once and Future Internet
- •Looking Ahead
- •Frequently Asked Questions
- •References
- •ISP Services
- •Looking Ahead
- •Frequently Asked Questions
- •History of Internet Addressing
- •IP Address Space Depletion
- •Looking Ahead
- •Frequently Asked Questions
- •References
- •Overview of Routers and Routing
- •Routing Protocol Concepts
- •Segregating the World into Autonomous Systems
- •Looking Ahead
- •Frequently Asked Questions
- •References
- •How BGP Works
- •BGP Capabilities Negotiation
- •Multiprotocol Extensions for BGP
- •TCP MD5 Signature Option
- •Looking Ahead
- •Frequently Asked Questions
- •References
- •Building Peer Sessions
- •Sources of Routing Updates
- •Overlapping Protocols: Backdoors
- •The Routing Process Simplified
- •Controlling BGP Routes
- •Route Filtering and Attribute Manipulation
- •BGP-4 Aggregation
- •Looking Ahead
- •Frequently Asked Questions
- •References
- •Redundancy
- •Symmetry
- •Load Balancing
- •Looking Ahead
- •Frequently Asked Questions
- •References
- •Interaction of Non-BGP Routers with BGP Routers
- •BGP Policies Conflicting with Internal Defaults
- •Policy Routing
- •Looking Ahead
- •Frequently Asked Questions
- •Route Reflectors
- •Confederations
- •Controlling IGP Expansion
- •Looking Ahead
- •Frequently Asked Questions
- •References
- •Route Instabilities on the Internet
- •BGP Stability Features
- •Looking Ahead
- •Frequently Asked Questions
- •Building Peering Sessions
- •Route Filtering and Attribute Manipulation
- •Peer Groups
- •Sources of Routing Updates
- •Overlapping Protocols: Backdoors
- •BGP Attributes
- •BGP-4 Aggregation
- •Looking Ahead
- •Redundancy, Symmetry, and Load Balancing
- •Following Defaults Inside an AS
- •Policy Routing
- •Route Reflectors
- •Confederations
- •Controlling Route and Cache Invalidation
- •BGP Outbound Request Filter Capability
- •Route Dampening
- •Looking Ahead
- •Interesting Organizations
- •Research and Education
- •Miscellaneous
- •Books
- •Internet Request For Comments
- •When to Use BGP ORF
- •Configuration
- •EXEC Commands
- •Closing Remarks
- •The Motivation Behind the New Command-Line Interface
- •Organizing Command Groups in the New Configuration
- •Peer Groups
- •Route Maps
- •Redistribution
- •Route Reflector
- •Aggregation
- •List of BGP Commands
- •Upgrading to the AF Style
Internet Routing Architectures, Second Edition
Appendix C. BGP Outbound Route Filter (ORF)
Outbound Route Filter (ORF) is a new BGP functionality used to minimize the number of BGP updates sent to a neighbor. This appendix provides information on BGP ORF as it relates to IOS versions 12.0ST and 12.1.
The idea is to push the locally-configured BGP prefix filter to the remote peer so that the remote peer applies this received filter as yet another outbound filter. This results in two benefits:
•The number of prefixes that are sent are reduced and thus leads to a lesser number of BGP updates.
•Less work for the local router which previously used to process all those extra updates. This might mean less transient memory consumption and less attribute and cache creation.
This appendix covers the ORF. The inbound prefix list can be pushed down to the peer acting as its outbound policy.
ORF is defined as a new capability, IOS uses 130 as its code value. The new capability reflects the latest draft which lists all the ORF-types supported as send, receive or both. This means that there is a compatibility issue between routers running these two capabilities. The old knob is accepted only as receive capability.
The local-peer that advertises support for BGP ORF in send-mode will push its inbound prefix list only if it receives the receive-mode BGP ORF capability from the remote-peer. The remote-peer however will wait before sending the first update until it receives a ROUTEREFRESH request or BGP ORF with IMMEDIATE from the peer. Note that this is done for each address-family (AF) for updates exchanged between the peers depending on the BGP ORF capability advertised.
When to Use BGP ORF
BGP ORF allows one BGP speaker to install its inbound prefix list filter on the remote end, and can be used to reduce the amount of unwanted routing update.
For example, this feature can be used to address the issue of receiving ("unwanted") full routes from multi-homed BGP customers. The customer can simply enable the capability, thus allowing its provider to manage the route filtering, and avoid such unwanted routing updates.
Configuration
The following section provides configuration guidelines that should be used when configuring BGP ORF. BGP ORF is asymmetric in nature and independently configured on each end of the connection.
page 394
Internet Routing Architectures, Second Edition
The steps to configure BGP ORF consist of the following:
1.Enabling the BGP ORF capability as send-mode.
2.Enabling the BGP ORF capability as receive-mode.
3.Ensure backward compatibility of the old knobs
Enabling the BGP ORF Capability as Send-Mode
The command to enable the BGP ORF capability as send mode is as follows:
[no] neighbor x.x.x.x capability orf prefix list send
This command is used to configure the local router to advertise the ORF capability with BGP ORF-type (value 128) in send-mode (value 2) during session establishment with the remote peer specified. This command can be used for individual members as well as members of peergroup or the peergroup itself.
The default for this capability is OFF. This is not advertised and has to be turned ON by configuration.
This is available for all address families.
Enabling the BGP ORF Capability as Receive-Mode
The command to enable the BGP ORF capability as send mode is as follows:
[no] neighbor x.x.x.x capability orf prefix list receive
This command is used to configure the local router to advertise the ORF capability with BGP ORF-type (value 128) in the receive-mode (value 1) during the session establishment with the remote peer specified. This command can be used only for the individual members or for peergroup itself. The command cannot be used for peergroup members.
The default for this capability is OFF. This is not advertised and has to be turned ON by configuration.
BGP ORF support is available for all address families (that is IPv4 unicast, IPv4 multicast, and so on).
Ensuring Backward Compatibility of the Old Knobs
The command to ensure backward compatibility of the old knobs is as follows:
[no] neighbor x.x.x.x capability prefix-filter
page 395
Internet Routing Architectures, Second Edition
If the preceding knob is configured, the new software accepts this knob as hidden and will advertise it as the new BGP ORF capability in the receive-mode. Note that it will NVGEN in the new format. This means that the remote-peer peering with this before should be upgraded as well to make the ORF work.
If the knob is configured as follows:
[no] neighbor x.x.x.x send prefix-filter
then the new software accepts this knob as hidden and will advertise it as the new BGP ORF capability in the send-mode. Note that it will NVGEN in the new format. This means that the remote-peer peering with this before should be upgraded as well to make the ORF work.
EXEC Commands
Pushing Out A Prefix List and Receiving a Route Refresh from a Neighbor
The command syntax to push out a prefix list and receive route refresh from a neighbor is as follows (note that any address family can be specified):
clear ip bgp x.x.x.x in prefix-filter
clear ip bgp x.x.x.x vrf foo in prefix-filter
clear ip bgp x.x.x.x ipv4 multicast in prefix-filter
When the inbound prefix list changes (or is removed), this command can be used to push out the new prefix list, and consequently receive route refresh from the neighbor based on the new prefix list.
The keyword prefix-filter will be ignored if the BGP ORF capability has not been received from the neighbor, or if the local speaker has not enabled send-orf for the neighbor.
Without the keyword prefix-filter, the command clear ip bgp x.x.x.x in would simply perform the normal route refresh from the neighbor. It does not push out the current inbound prefix list filter to the neighbor. The command is useful when using inbound routing policies other than the prefix list filter such as a route map change.
Displaying the Prefix List Received from a Neighbor
The command syntax to display the prefix list received from a neighbor is as follows:
show ip bgp neighbor x.x.x.x received prefix-filter
show ip bgp vpnv4 vrf foo neighbor x.x.x.x received prefix-filter show ip bgp ipv4 multicast neighbor x.x.x.x received prefix-filter
page 396
Internet Routing Architectures, Second Edition
Displaying Changes to the Neighbor BGP Table
Changes to the output of show ip bgp neighbor x.x.x.x reveal the following information:
AF-dependant capabilities:
Outbound Route Filter (ORF) type (128) Prefix-list: Send-mode: advertised, received
Receive-mode: advertised, received
Outbound Route Filter (ORF): sent, received (2 entries)
First update is deferred until ORF or ROUTE-REFRESH is received Scheduled to send the Prefix-list filter test
Closing Remarks
Even after a BGP speaker pushes its inbound prefix list to the remote end, the speaker will continue to apply the locally defined inbound prefix list filter to received updates.
page 397