On a side note, you don't need reject in isis export policy, since default is a reject (local and learned isis routes are flooded anyway). In fact, you can do prefix-suppression with a reject in isis export policy (say, advertise only loopback and suppress all core links) - something you can't do in ospf. On Junos, that is.
On Thu, Oct 6, 2016 at 5:33 PM, Saku Ytti <s...@ytti.fi> wrote: > On 6 October 2016 at 18:12, Hugo Slabbert <h...@slabnet.com> wrote: > > > I generally create an explicit 'reject-all' policy and stick that at the > end > > of policy lists, rather than nesting the reject within an existing > policy. > > It's a bit clearer. > > Always terminate as late as sensible policy design allows, as it'll > make it more extendable, not needing to rewrite those special cases, > just add new policy. To that effect, also consider default-action > reject instead of reject, so that you mark route to be rejected, > unless later otherwise told, this is again useful if you have that one > special hack, you don't need to rewrite anything, just chain new small > hack policy to revert that decision. > > > -- > ++ytti > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
