Generally eBGP speakers filter advertisement separately, the sender applies its outbound filter and the receiver applies its inbound filters to received updates.
The obvious goal of filtering at the receiver is to deny certain prefixes, sent by eBGP peer, according to its own policy… So why send them at all?
ORF (Outbound Route Filtering) is a step further in the cooperation between the two autonomous systems, where the receiver send its inbound filter to the sender to be used as outbound filter, thus avoiding unnecessary updates in the link and CPU resources related to update generation and inbound filtering.
The goal of this LAB is to show the benefit of ORF comparing to the traditional method.
Let’s consider the eBGP connection between R1 and R2 (figure1) , with a an R1 inbound policy allowing only prefix 20.20.10.0/24
Figure1: topology
1) Before Applying ORF:
R1 and R2 configurations look as follows:
R1:
|
ip prefix-list only_202010 seq 5 permit 20.20.10.0/24
router bgp 65500 neighbor 2.2.2.2 remote-as 65501 neighbor 2.2.2.2 ebgp-multihop 2 neighbor 2.2.2.2 update-source Loopback0 neighbor 2.2.2.2 prefix-list only_202010 in |
R2:
|
network 20.20.10.0 mask 255.255.255.0 network 20.20.20.0 mask 255.255.255.0 neighbor 1.1.1.1 remote-as 65500 neighbor 1.1.1.1 ebgp-multihop 2 neighbor 1.1.1.1 update-source Loopback0 |
1-a) Debug R2 outbound
R2:
|
R2#debug ip bgp updates out BGP updates debugging is on (outbound) for address family: IPv4 Unicast R2#clear ip bgp 1.1.1.1 soft out R2# *Mar 1 00:40:43.155: BGP(0): 1.1.1.1 send UPDATE (format) 20.20.20.0/24, next 2.2.2.2, metric 0, path Local *Mar 1 00:40:43.155: BGP(0): 1.1.1.1 send UPDATE (prepend, chgflags: 0×0) 20.20.10.0/24, next 2.2.2.2, metric 0, path Local *Mar 1 00:40:43.159: BGP(0): 1.1.1.1 send UPDATE (format) 10.10.10.0/24, next 2.2.2.2, metric 0, path 65500 *Mar 1 00:40:43.159: BGP(0): 1.1.1.1 send UPDATE (prepend, chgflags: 0×820) 10.10.20.0/24, next 2.2.2.2, metric 0, path 65500 *Mar 1 00:40:43.263: BGP(0): updgrp 1 – 1.1.1.1 updates replicated for neighbors: R2# |
1-b) Debug R1 inbound
R1:
|
R1#debug ip bgp updates in BGP updates debugging is on (inbound) for address family: IPv4 Unicast R1# R1#clear ip bgp 2.2.2.2 soft in R1# R1# *Mar 1 00:40:43.487: BGP(0): 2.2.2.2 rcvd UPDATE w/ attr: nexthop 2.2.2.2, origin i, metric 0, path 65501 *Mar 1 00:40:43.487: BGP(0): 2.2.2.2 rcvd 20.20.20.0/24 — DENIED due to: distribute/prefix-list; *Mar 1 00:40:43.491: BGP(0): 2.2.2.2 rcvd 20.20.10.0/24…duplicate ignored *Mar 1 00:40:43.491: BGP(0): 2.2.2.2 rcv UPDATE w/ attr: nexthop 2.2.2.2, origin i, originator 0.0.0.0, path 65501 65500, community , extended community *Mar 1 00:40:43.495: BGP(0): 2.2.2.2 rcv UPDATE about 10.10.10.0/24 — DENIED due to: AS-PATH contains our own AS; *Mar 1 00:40:43.495: BGP(0): 2.2.2.2 rcv UPDATE about 10.10.20.0/24 — DENIED due to: AS-PATH contains our own AS; R1# |
|
R1#sh ip bgp BGP table version is 16, local router ID is 10.10.20.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 *> 10.10.10.0/24 0.0.0.0 0 32768 i *> 10.10.20.0/24 0.0.0.0 0 32768 i *> 20.20.10.0/24 2.2.2.2 0 0 65501 i R1# |
2) With ORF feature
2-a) ORF configuration:
R1:
|
ip prefix-list only_202010 seq 5 permit 20.20.10.0/24
router bgp 65500 neighbor 2.2.2.2 prefix-list only_202010 in neighbor 2.2.2.2 capability orf prefix-list both |
R2:
|
router bgp 65501 network 20.20.10.0 mask 255.255.255.0 network 20.20.20.0 mask 255.255.255.0 neighbor 1.1.1.1 remote-as 65500 neighbor 1.1.1.1 ebgp-multihop 2 neighbor 1.1.1.1 update-source Loopback0 neighbor 1.1.1.1 capability orf prefix-list both |
2-b) debug R2 outbound
R2:
|
R2# *Mar 1 00:48:47.367: BGP(0): 1.1.1.1 send UPDATE (format) 20.20.10.0/24, next 2.2.2.2, metric 0, path Local |
Note that R2 sent only prefixes allowed in the filter received from R1.
2-c) debug R1 outbound
R1:
|
R1# *Mar 1 00:48:47.755: BGP(0): 2.2.2.2 rcvd UPDATE w/ attr: nexthop 2.2.2.2, origin i, metric 0, path 65501 *Mar 1 00:48:47.755: BGP(0): 2.2.2.2 rcvd 20.20.10.0/24 *Mar 1 00:48:47.363: BGP(0): Revise route installing 1 of 1 routes for 20.20.10.0/24 -> 2.2.2.2(main) to main IP table |
Note that R1 did not received 20.20.20.0/24 at all.
