How IP options work is platform specific. It used to be that _transited_ IP-options were not subject to the lo0 filter, while still being risk for RE, so you'd implement forwarding-filter, where you'd police IP-options or drop out right.
In more recent junipers, this behaviour has been changed so that transited IP-options are subject to lo0 filter, which makes it in practice impossible to determine if IP-option is transit or punt, especially if you run L3 MPLS VPN. I tried to argue that the new behaviour is PR, but didn't have enough patience to ram it through. So basically no one knows what their policy regarding transit IP packets are, and most accidentally change the policy from 'transit all, unlimited' to 'transit none' by upgrading devices. Of course generally this is the case for most things. On Mon, 13 May 2024 at 13:36, Martin Tonusoo via juniper-nsp <juniper-nsp@puck.nether.net> wrote: > > Michael, > > got it, thanks. > > > Lee, > > the README of your repository provides an excellent introduction to RE > filtering. Based on your filters, I moved the processing of the IP > Options from edge filters to RE filters: > > https://gist.github.com/tonusoo/efd9ab4fcf2bb5a45d34d5af5e3f3e0c#file-junos-re-filters-L574:L585 > > > Martin > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp -- ++ytti _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
