Cc: "Juniper List"
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 coul
You can confirm PPE load by:
RMPC0(r24.labxtx01.us.bb-re0 vty)# show xl-asic 0 npu_stats
NPU Stats Dump for FPC0:NPU0
Global NPU Utilization: 0.
(xl or lu, depending on platform)
Also piping output to file and aggregating: 'show xl-asic 0 ppe cntx'
can be very useful to see what the PPEs are do
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 fol
--- Begin Message ---
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 pl
No really as if I ping .209 from Internet side without IP options (this is
ISP edge) I get 30 ms RTT across Europe.
Besides this is not the only MX104 which is slow in fast path.
If we well J finds an answer and makes it public I will share with the
list.
Thx,
R.
On Mon, Mar 23, 2020 at 9:32 PM
--- Begin Message ---
On 23-Mar-20 14:03, Robert Raszuk wrote:
Hi,
Would anyone have any idea why IP packets with options are forwarded via
MX104 20x faster then regular IP packets ?
"fast" PFE path - 24-35 ms
"slow" RE path - 1-4 ms
24 ms is ages in terms of PFE.
I hardly can imaginethat
On 23/Mar/20 19:31, Robert Raszuk wrote:
>
> PFE bugs ... but I will happily let vendor handle it these days :)
Please keep us posted.
Would be interesting to see if this can be replicated on non-MX104
hardware as well.
Mark.
___
juniper-nsp mailing
PFE bugs ... but I will happily let vendor handle it these days :)
On Mon, Mar 23, 2020 at 6:30 PM Mark Tinka wrote:
>
>
> On 23/Mar/20 19:25, Robert Raszuk wrote:
>
> > Hi Mark,
> >
> > Oh yes ... exact same config and same setup and even same hw (mx104)
> > works fine in other location giving
On 23/Mar/20 19:25, Robert Raszuk wrote:
> Hi Mark,
>
> Oh yes ... exact same config and same setup and even same hw (mx104)
> works fine in other location giving consistent 1 ms without IP options
> and mostly 1-3 ms with IP options - but that is all fine. Going to RE
> is always non determinis
Hi Mark,
Oh yes ... exact same config and same setup and even same hw (mx104) works
fine in other location giving consistent 1 ms without IP options and mostly
1-3 ms with IP options - but that is all fine. Going to RE is always non
deterministic :)
Another interesting observation is that show co
On 23/Mar/20 17:37, Saku Ytti wrote:
> I'm not sure what you mean by 'PFE loops', this is single NPU
> fabricless platform, all ports are local. The only way to delay packet
> that long, is to send it to off-chip DRAM (delay buffer).
>
> But please update list once you figure it out.
Just for g
On 23/Mar/20 17:37, Saku Ytti wrote:
> I'm not sure what you mean by 'PFE loops', this is single NPU
> fabricless platform, all ports are local. The only way to delay packet
> that long, is to send it to off-chip DRAM (delay buffer).
>
> But please update list once you figure it out.
Just for g
I'm not sure what you mean by 'PFE loops', this is single NPU
fabricless platform, all ports are local. The only way to delay packet
that long, is to send it to off-chip DRAM (delay buffer).
But please update list once you figure it out.
On Mon, 23 Mar 2020 at 17:28, Robert Raszuk wrote:
>
> Th
That is actual topology and during testing no other return path existed.
It seems that there are PFE loops which would explain why punted to RE
packets are forwarded so fast JTAC is debugging :)
Thx,
R.
On Mon, Mar 23, 2020 at 4:17 PM Saku Ytti wrote:
> Hey,
>
> > This is very simple setu
Hey,
> This is very simple setup:
>
> linux (.206) LAN mx104(.210) p2p isp (.209)
>
> Pretty much 1.4 is what is expected. The only place the delay occurs is on
> ingress from the ISP to MX104. If I ping MX104 outbound (.210) int I get 0.5
> ms.
>
> No worries anyway ... just
Hi Saku,
This is very simple setup:
linux (.206) LAN mx104(.210) p2p isp (.209)
Pretty much 1.4 is what is expected. The only place the delay occurs is on
ingress from the ISP to MX104. If I ping MX104 outbound (.210) int I get
0.5 ms.
No worries anyway ... just thought anyon
There isn't enough information to answer your question.
But one possible reason is that you're choosing a different path in SW
and HW. Or that the answers are not even coming from host you think
(tshark might add information).
a) is 1.4ms possible in terms of speed-of-light?
b) where are 24ms pac
Hi,
Would anyone have any idea why IP packets with options are forwarded via
MX104 20x faster then regular IP packets ?
"fast" PFE path - 24-35 ms
"slow" RE path - 1-4 ms
Example (I used record route to force IP Options punt to slow path):
rraszuk@cto-lon2:~$ ping 62.189.71.209 -R -v
PING 62.18
18 matches
Mail list logo
