BGP Route Policy for transit AS

Question

Hello,
Can anyone could tell me how route policy in (RPL) should look like - some best practice .
Simple situation. I have two ISP's, one Client ( I am transit AS for Client).
ISP1  AS 100  ------
                                ----------    MY AS 300  ( I am BGP transit for  client)       ------------  My BGP CLIENT AS 400
ISP2  AS 200 ------
What I configured already are 4 route-policy ( two for isp's  in/out  and two for client in/out)
route-policy client-in
route-policy client-out
route-policy  isp-in
route-policy  isp-out
as-path-set aspath_Other
  ios-regex '.*'
end-set
as-path-set aspath_Local_plus_Client
  ios-regex '^$',
  ios-regex '^400'
end-set
as-path-set aspath_Client
    ios-regex '^400'
end-set
route-policy isp-in
    pass
end-policy
route-policy isp-out
  if (as-path in aspath_Local_plus_Client) then
    pass
  elseif (as-path in aspath_Other) then
    drop
  endif
end-policy
route-policy client-out
  pass
end-policy
route-policy client-in
  if (as-path in aspath_Client) then
    pass
  elseif (as-path in aspath_Other) then
    drop
  endif
end-policy
I am not sure about route-policy client-in  ( should I use aspath like above or e.g prefix-list  .. )?
regards,

Answer 1

Hi,
you may find this reference useful that talks about inline vs named lists when it comes to RPL.
named lists are easier to edit and preferred when the lists are long, but inline sets are faster to process.
When stating faster, you should think in usec improvements.
One improvement I see is that you can change this:
route-policy client-in
  if (as-path in aspath_Client) then
    pass
  elseif (as-path in aspath_Other) then
    drop
  endif
end-policy
to this:
route-policy client-in
  if (as-path in aspath_Client) then
    pass
  else
    drop
  endif
end-policy
Considering the aspath other is a catch all it is a waste of cycles to invoke regex to make sure that it is matches any.
On the topic of using prefix sets vs AS paths there are probably different opinions about it.
If your client originates prefixes that are not theirs your policy still accepts them and will result in rogue routing and hijacking of prefixes.
So with that I would recomment using a prefix set to accept prefixes from my client, just to make sure that we accept legimate prefixes. You dont want to be the guy that sourced rogue prefixes because of a client misconfiguration.
regards
xander