cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
620
Views
0
Helpful
0
Replies

BGP ORF (Outbound Route Filtering) on XRv

pawsonmark
Level 1
Level 1

Hello,

I have a problem using orf (outbound route filtering) on IOS XRv (version 6.0).  I am using a simple network, two routers connected together, peering with each other via BGP, on one side XR1 on the other XR2.  I would like to use the orf capability to tell XR2 what routes XR1 is willing to accept.  Here are the configs:

XR1:

interface GigabitEthernet0/0/0/0
 vrf interconnect
 ipv4 address 192.168.150.37 255.255.255.252
 ipv4 verify unicast source reachable-via rx
 carrier-delay up 30000 down 0
!
prefix-set Prefix-Set
  192.168.111.111/32
end-set
!
prefix-set Routes
  10.0.0.0/8,
  192.168.0.0/16,
  172.16.0.0/12
end-set
!
community-set Primary-Community
  65000:150
end-set
!
route-policy Outbound
  if destination in Routes then
    done
  endif
end-policy
!
route-policy ORF
  if orf prefix in Prefix-Set then
    drop
  endif
end-policy
!
route-policy Primary-Inbound
  if destination in Prefix-Set and community matches-any Primary-Community then
    set local-preference 150
  endif
end-policy
!
router bgp 65000
 bgp router-id 192.168.150.37
 bgp graceful-restart
 address-family ipv4 unicast
 !
 address-family vpnv4 unicast
 !
 vrf interconnect
  rd 1.2.3.4:780
  default-information originate
  address-family ipv4 unicast
   redistribute connected
   redistribute static
  !
  neighbor 192.168.150.38
   remote-as 64512
   ttl-security
   address-family ipv4 unicast
    send-community-ebgp
    route-policy Primary-Inbound in
    maximum-prefix 100 80 discard-extra-paths
    route-policy Outbound out
    orf route-policy ORF
    capability orf prefix send
   !
  !
 !
!
end


XR2:

interface GigabitEthernet0/0/0/0
 ipv4 address 192.168.150.38 255.255.255.252
 ipv4 verify unicast source reachable-via rx
!
interface GigabitEthernet0/0/0/1
 ipv4 address 192.168.2.1 255.255.255.0
!
route-policy PASS
  pass
end-policy
!
route-policy test-community($comm)
  set community (64512:$comm)
end-policy
!
router static
 address-family ipv4 unicast
  192.168.111.101/32 192.168.2.2
  192.168.111.102/32 192.168.2.2
  192.168.111.103/32 192.168.2.2
  192.168.111.104/32 192.168.2.2
  192.168.111.105/32 192.168.2.2
  192.168.111.106/32 192.168.2.2
  192.168.111.107/32 192.168.2.2
  192.168.111.108/32 192.168.2.2
  192.168.111.109/32 192.168.2.2
  192.168.111.110/32 192.168.2.2
  192.168.111.111/32 192.168.2.2
  192.168.222.222/32 192.168.2.2
 !
!
router bgp 64512
 bgp router-id 192.168.150.38
 bgp graceful-restart
 address-family ipv4 unicast
  redistribute static
 !
 neighbor 192.168.150.37
  remote-as 65000
  ttl-security
  address-family ipv4 unicast
   send-community-ebgp
   route-policy PASS in
   route-policy test-community(101) out
   capability orf prefix receive
  !
 !
!
end


The BGP sessions are up, the routes are in the routing table on XR2:

B    10.0.0.0/8 [20/0] via 192.168.150.37, 00:17:13
B    172.16.0.0/12 [20/0] via 192.168.150.37, 00:17:13
B    192.168.0.0/16 [20/0] via 192.168.150.37, 00:17:13
C    192.168.2.0/24 is directly connected, 18:28:51, GigabitEthernet0/0/0/1
L    192.168.2.1/32 is directly connected, 18:28:51, GigabitEthernet0/0/0/1
S    192.168.111.101/32 [1/0] via 192.168.2.2, 18:28:51
S    192.168.111.102/32 [1/0] via 192.168.2.2, 18:28:51
S    192.168.111.103/32 [1/0] via 192.168.2.2, 18:28:51
S    192.168.111.104/32 [1/0] via 192.168.2.2, 18:28:51
S    192.168.111.105/32 [1/0] via 192.168.2.2, 18:28:51
S    192.168.111.106/32 [1/0] via 192.168.2.2, 18:28:51
S    192.168.111.107/32 [1/0] via 192.168.2.2, 18:28:51
S    192.168.111.108/32 [1/0] via 192.168.2.2, 18:28:51
S    192.168.111.109/32 [1/0] via 192.168.2.2, 18:28:51
S    192.168.111.110/32 [1/0] via 192.168.2.2, 18:28:51
S    192.168.111.111/32 [1/0] via 192.168.2.2, 18:28:51
C    192.168.150.36/30 is directly connected, 18:28:51, GigabitEthernet0/0/0/0
L    192.168.150.38/32 is directly connected, 18:28:51, GigabitEthernet0/0/0/0
S    192.168.222.222/32 [1/0] via 192.168.2.2, 18:28:51

However the route-filter seems incorrect:

RP/0/0/CPU0:XR2(config-bgp-nbr)#do sh bgp ipv4 uni nei 192.168.150.37 received$
Fri Apr 15 08:56:13.128 UTC
Number of entries: 1
ipv4 prefix ORF 192.168.150.37
  1 deny 192.168.111.111/32 ge 32 le 32
RP/0/0/CPU0:XR2(config-bgp-nbr)#
RP/0/0/CPU0:XR2(config-bgp-nbr)#do sh bgp ipv4 uni nei 192.168.150.37 advertis$
Fri Apr 15 08:57:23.813 UTC
RP/0/0/CPU0:XR2(config-bgp-nbr)#

As this output shows the orf prefix-filter is being received, but it shows a deny for the only prefix that I wish to accept, and presumably after that an implicit deny all, so basically it denies all prefixes, hence the output from "advertised-routes", which shows nothing.

Just for confirmation I removed the line "orf route-policy ORF" from PE and re-ran the commands on XR2:

RP/0/0/CPU0:XR2(config-bgp-nbr)#do sh bgp ipv4 uni nei 192.168.150.37 received$
Fri Apr 15 09:02:20.153 UTC
RP/0/0/CPU0:XR2(config-bgp-nbr)#
RP/0/0/CPU0:XR2(config-bgp-nbr)#do sh bgp ipv4 uni nei 192.168.150.37 advertis$
Fri Apr 15 09:02:25.722 UTC
Network            Next Hop        From            AS Path
192.168.111.101/32 192.168.150.38  Local           64512?
192.168.111.102/32 192.168.150.38  Local           64512?
192.168.111.103/32 192.168.150.38  Local           64512?
192.168.111.104/32 192.168.150.38  Local           64512?
192.168.111.105/32 192.168.150.38  Local           64512?
192.168.111.106/32 192.168.150.38  Local           64512?
192.168.111.107/32 192.168.150.38  Local           64512?
192.168.111.108/32 192.168.150.38  Local           64512?
192.168.111.109/32 192.168.150.38  Local           64512?
192.168.111.110/32 192.168.150.38  Local           64512?
192.168.111.111/32 192.168.150.38  Local           64512?
192.168.222.222/32 192.168.150.38  Local           64512?

Processed 12 prefixes, 12 paths

While on XR1 I check "show route vrf interconnect":

B    10.0.0.0/8 [20/0] via 192.168.150.41, 18:30:50
B    172.16.0.0/12 [20/0] via 192.168.150.41, 18:30:50
B    192.168.0.0/16 [20/0] via 192.168.150.41, 18:30:50
B    192.168.111.111/32 [20/0] via 192.168.150.38, 00:01:19
C    192.168.150.36/30 is directly connected, 18:33:24, GigabitEthernet0/0/0/0
L    192.168.150.37/32 is directly connected, 18:33:24, GigabitEthernet0/0/0/0

And as you would expect the route (192.168.111.111/32) has appeared, because it is allowed through the Primary-Inbound route-policy.

If anyone has any thoughts or suggestions I would be most grateful to hear about them.

Thank you,

Mark.

0 Replies 0