[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: NetworkLayer
- From: saku at ytti.fi (Saku Ytti)
- Date: Tue, 24 Sep 2019 08:44:00 +0300
- In-reply-to: <[email protected]>
- References: <00cb01d57253$4207b0f0$c61712d0$@ca> <[email protected]>
On Tue, 24 Sep 2019 at 00:59, Naslund, Steve <SNaslund at medline.com> wrote:
> Just a tip, but you cannot really determine packet loss on an MPLS network with a traceroute. The nodes between the provider edge routers may not even represent your real path. Also, provider routers within their network will be handling pings much differently than they handle your actual traffic. The pings require processing whereas your MPLS traffic will be label switched. Much different performance.
This is not MPSL specific, equally in natively forwarded you can only
determine packet loss for the ultimate host, this is because TTL==1
packets are punted to software processing typically, and such punting
is heavily rate-limited to conserve control-plane resources, so reply
may not come. This isn't something devices have to do, but it is
something they do, NPU based devices could reply to TTL==1 from NPU at
wire-rate to fix this problem, and is only a matter of someone asking
their vendor to do that.
The MPLS speciality is that RTT may be far-end RTT for whole transit,
because LSR may not know how to send reply, LSR may only have IGP, so
LSR may need to send TTL unreachable message to far-end LER, which
will then reply back to sender, causing each step to represent
far-end LER RTT. This is not happening in the described traceroute.
Hope this helps.