Hey Saku,
> Saku Ytti
> Sent: Thursday, January 28, 2016 9:38 PM
>
> Anyone remember from top of their head if or not Trio originally punted
> transit IP packets with IP options through lo0 filter or not?
>
Isn’t there a requirement that packets with IP options needs to be punted to
the CPU for processing (process switched) (on every hop)
Although I'd be interested to know if it's the LC CPU or RE CPU handling these
then.
Also my understanding of RE filter is that it is passed down to all PFEs in the
system -so what you filter there is dropped right at the ingress and only what
you permit is then subject to the built in DDoS protection rate-limiters (Junos
"static" version of LPTS in XR) before it ends up in CPU (wanted to say RE-CPU
but now I'm not that sure, could be LC CPU possibly??? ).
> I could have sworn when I tested MX80, I needed forwarding-filters to limit
> them.
>
> Now it seems they hit lo0 filter and JTAC considers this to be correct and by
> design. I view it wildly broken, because it essentially means, if you want to
> allow IP options, you need to do something like this
>
> a) match IP options and match any local DADDR => DROP
> b) match IP options => police
>
> As opposed to just do b) in forwarding filters.
>
> Much same as it would be wildly broken to punt TTL exceeded messages
> through lo0 filter, or anything else that is not destined to the router
> itself.
>
Do you mean the term "discard-TTL_1-unknown" i.e. "from ttl 1 then discard"?
It looks like there's a built in mechanism that filters ingress packets with
TTL1 that are not destined to the router - as those would not make out the
egress interface because of TTL decremented to 0 anyway.
So it looks like instead of just the source IP and possibly some other fields
the whole packet is actually passed up to the CPU (RE/LC) so that the CPU can
generate Time Exceeded ICMP message. (if just necessary fields would have been
listed in a msg sent to CPU there would be no need to mention packets with TTL1
in the RE filter)
The rate at which these packets are punted to CPU is then subject to built-in
DDoS protection.
adam
Adam Vitkovsky
IP Engineer
T: 0333 006 5936
E: adam.vitkov...@gamma.co.uk
W: www.gamma.co.uk
This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of
this email are confidential to the ordinary user of the email address to which
it was addressed. This email is not intended to create any legal relationship.
No one else may place any reliance upon it, or copy or forward all or any of it
in any form (unless otherwise notified). If you receive this email in error,
please accept our apologies, we would be obliged if you would telephone our
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk
Gamma Telecom Limited, a company incorporated in England and Wales, with
limited liability, with registered number 04340834, and whose registered office
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
