ORF (Outbound Route Filtering)


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:

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

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: 0x0) 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: 0x820) 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.

 

Tags:
Advertisements

About ajnouri
Se vi deziras sekure komuniki eksterbloge, jen mia publika (GPG) ŝlosilo: My public key for secure communication: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x41CCDE1511DF0EB8

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: