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

Selective NHT route-policy

ADP_89
Level 1
Level 1

Hello Guys,

 

I'd like to know if anyone could help me understand how the route-policy configured on the bgp next-hop attach-point is processed by the ASR9K.

My testing case is very simple, I am using it out of production(VIRL) just to make sure that this could work.

The topology is made by 3 routers in line:

 

R1[1] -- 192.168.12.0/24 -- [2]R2[2] -- 192.168.23.0/24 -- [3]R3

 

Loopbacks are X.X.X.X/32 where X is the Router id

R1 and R2 have iBGP peering over the loopbacks advertised by OSPF

R2 and R3 have an eBGP(multihop) peering over the loopbacks installed by static routes (on R2 static router I have added 3.3.3.3/32 192.168.23.3 Gi0/0/0/0 )

R1 is also advertising via OSPF the subnet 3.3.3.0/24 -- yes R1, this is intended

R3 is advertising a some routes via eBGP (say 10.0.0.0/16)

 

By default if the link between R2 and R3 goes down R2 will forward all the traffic for 10.0.0.0/16 towards R1 as the latter is advertising a route (3.3.3.0/24) that includes the 3.3.3.3 next-hop. This will last until the BGP hold timer expires. Once this expires 10.0.0.0/16 route will be flushed from RIB.

So I do not have any ways to prevent this behaviour, no BFD, no way to establish the peering on the physical link, and I was trying to solve the problem using the selective NHT feature. But it looks like it's not behaving like a normal RPL policy.. let me explain better:

 

R2:

router bgp 65002
 bgp router-id 2.2.2.2
 address-family ipv4 unicast
  nexthop route-policy NHT

 neighbor 3.3.3.3
  remote-as 65003
  update-source Loopback0
  ignore-connected-check
  address-family ipv4 unicast
   route-policy PASS in
   route-policy PASS out

 

route-policy NHT
 if destination in (3.3.3.3/32) and protocol in (static) then
  done
 endif
 if destination in (3.3.3.3/32) then
  # this should discard any path to reach the NH that is not via a static
  drop
 endif
 pass # this allows any other BGP NH, like 1.1.1.1 in our case
end-policy

As far I can see the "drop" keyword is not stopping the policy execution; the action is taken based on the last matching condition, or in this case everything is permitted as there is an explicit pass at the end.

 

If this were the policy, the flushing works correctly but of course I'll loose validity on the other NHs.

 

route-policy NHT
 if destination in (3.3.3.3/32) and protocol in (static) then
  done
 endif
 if destination in (3.3.3.3/32) then
  drop
 endif
end-policy

 

The next one works correctly but I do not have a way to specify a default behavior in case there are no matches on top of it. Even though this solves the problem in the lab, in real scenario it would be very hard to map every next-hop to it's source-protocol.

route-policy NHT
 if destination in (3.3.3.3/32 ge 32) and protocol in (static) then
  done
 endif
 if destination in (1.1.1.1/32 ge 32) and protocol in (ospf 1) then
  pass
 endif
end-policy


Unfortunately I do not have some physical gear to test this at the moment so I am not sure if this is a problem only with the VIRL XR vms or if the same behavior happens on the ASR9K as well.

 

Anyone banged his head on this before, I cannot find specific informations on how the policy processes the entries?

 

Thanks,

ADP

0 Replies 0