BGP Route Policy for transit AS

[feableee123]

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,

[xthuijs · Accepted solution]

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

[feableee123]

Thanx Alexander,

I try with prefix set like e.g.

prefix-set prefix_client

  x.x.x.x/20       # Client IP's

end-set

route-policy policy_client-in

if source in prefix_client then

pass

else

   drop   

endif

Does it look ok or add something else ?

[xthuijs · Accepted solution]

This looks almost perfect, you want to say however in your "IF" statement:

if *destination* in (as opposed to source).

You'd only use the "source" keyword on packets. Destination keyword is used when evaluating routing prefixes.

chees

xander

[feableee123]

Thanks again,

Could You show example when using source in prefix_set, dunno if catch it ?

Btw. for test purpose could I use cli : show bgp route-policy  "test-policy"   to see result of any route-policy against bgp

table - but not impacting working routes ?

[xthuijs · Accepted solution]

Hi!

the show bgp command with the rpl will not affect the existing table and merely "filter" the display of the prefixes and paths based on the RPL execution.

you can define networks in the prefix-set, but when you are using that prefix set in an rpl to evaluate prefixes received or advertised, then the RPL command is "if destination in "

When RPL is used in non route evaluations the "source" keyword might become useful, however when routes are filtered by RPL, it executes it based on "destination" (not source).

regards

xander

[feableee123]

Thanks for great explanation.

regards,