* 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