Wednesday, October 26, 2011

BGP Outbound Route Filtering (ORF)

The BGP Outbound Route Filtering capability conserves network bandwidth and router resources upon the BGP route update process by minimizing the number of BGP updates sent to a neighbor. A BGP router will allows its neighbor to send over its inbound prefix filter, which is then installed in addition to any outbound filter configured for the neighbor.
* The inbound filter list that can be sent to the peer and installed as its outbound filter.

Below are the main benefits of implementing BGP ORF:
 A BGP router will no longer consume resources generating routing updates that will be filtered by the neighbor.
 A BGP router will not need to consume resources to process unwanted incoming routing updates and filter out prefixes based on the inbound filter implemented for the neighbor. A low-end router with limited memory can be overwhelmed (run out of memory) by large number of BGP updates even if it has the inbound filters configured.
 Reduce the administration overhead on a provider upon handling the constant change requests from customers for modifying the outbound filters to determine the prefixes that the customers would like to and don’t want to receive. Likewise from the perspective of the customers, this is the optimal administrative design, as they don’t need to send change requests to the provider, and can change their filtering design anytime.

The BGP ORF feature is disabled by default. It is enabled by advertising ORF capability to peers. BGP ORF is asymmetric in nature and can be configured in one direction between 2 routers, with one end configured to send ORF capability and another end configured to receive ORF capability. It can be independently configured with send, receive, or both ORF capabilities. The ORF capability is exchanged during session establishment.

The local peer that advertises the support for BGP ORF in send mode will send its inbound filter only if it receives the receive mode BGP ORF capability from the remote peer. However, the remote peer will not send the first update until it receives a ROUTE-REFRESH Request message with the IMMEDIATE ORF flag along with the ORF prefix list from the local peer. The local peer will continue to apply the locally defined inbound prefix list filter upon the received updates. BGP updates are exchanged between peer routers for each address family depending on the BGP ORF capability advertised.

A sample network with RT1 in AS1 and RT2 in AS2 is used to demonstrate the usage of BGP ORF. The BGP table on RT2 below lists the routes that received from RT1.
RT2#sh ip bgp
BGP table version is 6, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          12.12.12.1               0             0 1 ?
*> 172.16.1.0/24    12.12.12.1               0             0 1 i
*> 192.168.1.0      12.12.12.1               0             0 1 i
*> 192.168.2.0      12.12.12.1               0             0 1 i
*> 192.168.3.0      12.12.12.1               0             0 1 i
RT2#

Note that advertising a default route via BGP requires the following 3 steps:
 Create a static default route using the ip route 0.0.0.0 0.0.0.0 {ip-addr | out-intf} command.
 Redistribute static into BGP using the redistribute static BGP router subcommand.
 Configure the default-information originate BGP router subcommand.

Suppose that AS2 would like to only receive the default route 0.0.0.0/0 and 172.16.1.0/24 from AS1. Below shows the result of implementing traditional filtering using prefix list. The filtering goal is achieved, but with inefficiency; as the unwanted routes actually being sent from AS1 and filtered in AS2, wasting the network bandwidth and router resources for generating and processing them.
RT2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
RT2(config)#ip prefix-list AS1-Inbound permit 0.0.0.0/0
RT2(config)#ip prefix-list AS1-Inbound permit 172.16.1.0/24
RT2(config)#router bgp 2
RT2(config-router)#neighbor 12.12.12.1 prefix-list AS1-Inbound in
RT2(config-router)#end
RT2#
RT2#debug ip bgp updates
BGP updates debugging is on
RT2#
00:01:59: BGP(0): no valid path for 0.0.0.0/0
00:01:59: BGP(0): no valid path for 172.16.1.0/24
00:01:59: BGP(0): no valid path for 192.168.1.0/24
00:01:59: BGP(0): no valid path for 192.168.2.0/24
00:01:59: BGP(0): no valid path for 192.168.3.0/24
00:01:59: %BGP-5-ADJCHANGE: neighbor 12.12.12.1 Down User reset
00:01:59: BGP(0): nettable_walker 0.0.0.0/0 no best path
00:01:59: BGP(0): nettable_walker 172.16.1.0/24 no best path
00:01:59: BGP(0): nettable_walker 192.168.1.0/24 no best path
00:01:59: BGP(0): nettable_walker 192.168.2.0/24 no best path
00:01:59: BGP(0): nettable_walker 192.168.3.0/24 no best path
00:02:22: %BGP-5-ADJCHANGE: neighbor 12.12.12.1 Up
00:02:22: BGP(0): 12.12.12.1 computing updates, afi 0, neighbor version 0, table version 11, starting at 0.0.0.0
00:02:22: BGP(0): 12.12.12.1 update run completed, afi 0, ran for 4ms, neighbor version 0, start version 11, throttled to 11
00:02:22: BGP(0): 12.12.12.1 initial update completed
00:02:23: BGP(0): 12.12.12.1 rcvd UPDATE w/ attr: nexthop 12.12.12.1, origin ?, metric 0, path 1
00:02:23: BGP(0): 12.12.12.1 rcvd 0.0.0.0/0
00:02:23: BGP(0): 12.12.12.1 rcvd UPDATE w/ attr: nexthop 12.12.12.1, origin i, metric 0, path 1
00:02:23: BGP(0): 12.12.12.1 rcvd 172.16.1.0/24
00:02:23: BGP(0): 12.12.12.1 rcvd 192.168.1.0/24 -- DENIED due to: distribute/prefix-list;
00:02:23: BGP(0): 12.12.12.1 rcvd 192.168.2.0/24 -- DENIED due to: distribute/prefix-list;
00:02:23: BGP(0): 12.12.12.1 rcvd 192.168.3.0/24 -- DENIED due to: distribute/prefix-list;
00:02:23: BGP(0): Revise route installing 1 of 1 route for 0.0.0.0/0 -> 12.12.12.1 to main IP table
00:02:23: BGP(0): Revise route installing 1 of 1 route for 172.16.1.0/24 -> 12.12.12.1 to main IP table
RT2#
RT2#sh ip bgp
BGP table version is 13, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          12.12.12.1               0             0 1 ?
*> 172.16.1.0/24    12.12.12.1               0             0 1 i
RT2#

Without BGP ORF, the upstream router RT1 sent the full BGP table to the downstream router RT2, and filtering was applied inbound on the downstream router. With BGP ORF, the downstream router dynamically informs the upstream router the routes to filter outbound; and that the downstream router will only receive update messages based upon the prefixes that it wants.

Below shows the implementation of the BGP ORF send mode on RT2 and receive mode on RT1.
The neighbor capability orf prefix-list {receive | send | both} address family submode command can be configured and take effect under the BGP router configuration mode, but the command will only be displayed under the address family section.
Note that configuring this command will terminate the established BGP session with the neighbor.
The output of the debug ip bgp privileged command shows the negotiation of the BGP ORF capability during initial BGP peering session establishment.
RT1 (AS1):
!
router bgp 1
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 12.12.12.2 remote-as 2
 !
 address-family ipv4
 redistribute static
 neighbor 12.12.12.2 activate
 neighbor 12.12.12.2 capability orf prefix-list receive
 default-information originate
 no auto-summary
 no synchronization
 network 172.16.1.0 mask 255.255.255.0
 network 192.168.1.0
 network 192.168.2.0
 network 192.168.3.0
 exit-address-family
!
======================================================================
RT2 (AS2):
!
router bgp 2
 bgp router-id 2.2.2.2
 bgp log-neighbor-changes
 neighbor 12.12.12.1 remote-as 1
 !
 address-family ipv4
 neighbor 12.12.12.1 activate
 neighbor 12.12.12.1 capability orf prefix-list send
 neighbor 12.12.12.1 prefix-list AS1-Inbound in
 no auto-summary
 no synchronization
 exit-address-family
!
ip prefix-list AS1-Inbound seq 5 permit 0.0.0.0/0
ip prefix-list AS1-Inbound seq 10 permit 172.16.1.0/24
!

BGP ORF is defined as a new capability with the Capability Code of 130, BGP ORF-Type 128, with Receive-mode (value 1), Send-mode (value 2), or Both (value 3) in the BGP OPEN messages. The send keyword is supported for individual neighbors, peer group members, or the peer group itself; the receive and both keywords are not supported for peer group members and peer groups.

Below shows the excerpt of the show ip bgp neighbors command on RT1 and RT2 regarding BGP ORF.
RT1#sh ip bgp neighbors
--- output omitted ---
 For address family: IPv4 Unicast
  BGP table version 6, neighbor version 6
  Index 1, Offset 0, Mask 0x2
  AF-dependant capabilities:
    Outbound Route Filter (ORF) type (128) Prefix-list:
      Send-mode: received
      Receive-mode: advertised
  Outbound Route Filter (ORF): received (2 entries)
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:               2          0
    Prefixes Total:                 2          0
    Implicit Withdraw:              0          0
    Explicit Withdraw:              0          0
    Used as bestpath:             n/a          0
    Used as multipath:            n/a          0

                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Total:                                0          0
  Number of NLRIs in the update sent: max 4, min 0
--- output omitted ---
======================================================================
RT2#sh ip bgp neighbors
--- output omitted ---
For address family: IPv4 Unicast
  BGP table version 17, neighbor version 17
  Index 1, Offset 0, Mask 0x2
  AF-dependant capabilities:
    Outbound Route Filter (ORF) type (128) Prefix-list:
      Send-mode: advertised
      Receive-mode: received
  Outbound Route Filter (ORF): sent;
  Incoming update prefix filter list is AS1-Inbound
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:               0          2 (Consumes 96 bytes)
    Prefixes Total:                 0          2
    Implicit Withdraw:              0          0
    Explicit Withdraw:              0          0
    Used as bestpath:             n/a          2
    Used as multipath:            n/a          0

                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Bestpath from this peer:              2        n/a
    Total:                                2          0
  Number of NLRIs in the update sent: max 0, min 0
--- output omitted ---
BGP ORF support is available for all address families, eg: IPv4 unicast, IPv4 multicast, etc.

Below shows that RT1 received the inbound prefix filter of RT2.
Note that the prefix list does not show up locally in the running configuration.
RT1 then uses the prefix list as an outbound filter towards RT2 and sends only the interested routes.
RT1#sh ip bgp neighbors 12.12.12.2 received prefix-filter
Address family: IPv4 Unicast
ip prefix-list 12.12.12.2: 2 entries
   seq 5 permit 0.0.0.0/0
   seq 10 permit 172.16.1.0/24
RT1#
RT1#sh ip prefix-list

RT1#
RT1#sh ip bgp neighbors 12.12.12.2 advertised-routes
BGP table version is 6, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          0.0.0.0                  0         32768 ?
*> 172.16.1.0/24    0.0.0.0                  0         32768 i
RT1#

Below shows how RT2 dynamically requests RT1 to defer the old ORF prefix list and sends the new ORF prefix list when requesting RT1 to send an additional prefix – 192.168.1.0/24.
RT2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
RT2(config)#ip prefix-list AS1-Inbound permit 192.168.1.0/24
RT2(config)#end
RT2#
RT2#clear ip bgp 12.12.12.1 in prefix-filter
RT2#
00:09:25: BGP: 12.12.12.1 sending REFRESH_REQ to remove orftype 128 (defer) for afi/safi: 1/1
00:09:25: BGP: 12.12.12.1 sending REFRESH_REQ with pfxlist ORF for IPv4 Unicast
00:09:25: BGP(0): 12.12.12.1 rcvd UPDATE w/ attr: nexthop 12.12.12.1, origin ?, metric 0, path 1
00:09:25: BGP(0): 12.12.12.1 rcvd 0.0.0.0/0...duplicate ignored
00:09:25: BGP(0): 12.12.12.1 rcvd UPDATE w/ attr: nexthop 12.12.12.1, origin i, metric 0, path 1
00:09:25: BGP(0): 12.12.12.1 rcvd 172.16.1.0/24...duplicate ignored
00:09:25: BGP(0): 12.12.12.1 rcvd 192.168.1.0/24
00:09:25: BGP(0): Revise route installing 1 of 1 route for 192.168.1.0/24 -> 12.12.12.1 to main IP table
00:09:25: BGP(0): 12.12.12.1 computing updates, afi 0, neighbor version 17, table version 18, starting at 0.0.0.0
00:09:25: BGP(0): 12.12.12.1 update run completed, afi 0, ran for 0ms, neighbor version 17, start version 18, throttled to 18
RT2#
RT2#sh ip bgp
BGP table version is 18, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          12.12.12.1               0             0 1 ?
*> 172.16.1.0/24    12.12.12.1               0             0 1 i
*> 192.168.1.0      12.12.12.1               0             0 1 i
RT2#

When the inbound prefix list changes or being removed, the clear ip bgp {ip-addr} in prefix-filter privileged command can be used to send out the prefix list and receive route refresh from the neighbor based on the new prefix list. The prefix-filter keyword will be ignored if the receive-orf capability has not been received from the neighbor, or the local router has not sent the send-orf for the neighbor.

Without the prefix-filter keyword, the clear ip bgp {ip-addr} in would simply perform the normal route refresh with the neighbor – does not send out the inbound prefix filter to the neighbor. This command is useful when using inbound routing policies other than the inbound prefix list filter such as a route map change.

No comments:

Post a Comment