[j-nsp] Slow RE path 20 x faster then PFE path

[Alexander Arseniev]

Hello,
Well, my first advice - don't use interface-style service-sets until You 
100% understand what You are actually doing. Just don't.
Second - don't try to mimic SRX' NAPT-to-interface-address translation 
feature on MX with inline NAT, it is not supported, albeit technically 
possible and very complex. Just don't.
Third - don't tinker with static routes to next-table and similar stuff 
in conjunction with inline services.
Fourth - use nexthop-style service-sets with both ends of SI- IFL pair 
in different routing-instances. It is the most straightforward inline 
NAT config possible.
Hopefully that's enough to get You started , and without Your config I 
have no other ideas to share, perhaps others can chime in.
Thanks
Alex

------ Original Message ------
From: "Robert Raszuk" <robert at raszuk.net>
To: "Alexander Arseniev" <arseniev at btinternet.com>
Cc: "Juniper List" <juniper-nsp at puck.nether.net>
Sent: 24/03/2020 08:24:36
Subject: Re: Re[2]: [j-nsp] Slow RE path 20 x faster then PFE path

>
>Yes NAT is configured there as I indicated via presence of si- phantom 
>load ... Having NAT there is not my idea though :). But sorry can not 
>share the config.
>
>If you could shed some more light on your comment how to properly 
>configure it and what to avoid I think it may be very useful for many 
>folks on this list.
>
>Many thx,
>R.
>
>
>
>On Tue, Mar 24, 2020 at 5:00 AM Alexander Arseniev 
><arseniev at btinternet.com> wrote:
>>Hello,
>>
>>
>>>
>>>Another interesting observation is that show command indicated 
>>>services
>>>inline input traffic over 33 Mpps zero output while total coming to 
>>>the box
>>>was at that time 1 Mpps ....
>>
>>Do You have inline NAT configured on this box? Is it possible to share 
>>the config please?
>>It is quite easy to loop traffic with NAT (inline or not) and while 
>>looped inside same box,
>>TTL does not get decremented so You end up with eternal PFE 
>>saturation.
>>
>>Thanks
>>Alex