[j-nsp] Leaking OSPF routes into ISIS

Dragan Jovicic draganj84 at gmail.com
Thu Oct 6 11:41:36 EDT 2016


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 <saku at ytti.fi> wrote:

> On 6 October 2016 at 18:12, Hugo Slabbert <hugo at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


More information about the juniper-nsp mailing list