Hi Anyone from Network Layer to help? We are experiencing packet loss on the their MPLS network. I have attached a screenshot. Thank you 4 38.140.46.161 0% 31 16.3ms 18.6 6.4 153.1 24.9 5 154.54.45.113 0% 31 9.8ms 13.9 9 19.2 2.9 6 62.115.168.46 0% 31 12.5ms 16.3 10.2 66 9.7 7 62.115.134.48 0% 31 25.6ms 23.4 16.5 39.2 5.7 8 62.115.51.98 0% 31 19.4ms 22.6 16.6 49.9 6.1 9 50.97.19.12 0% 31 20.2ms 22 12.8 37.9 4.3 <MPLS:L=388134,E=0> 10 50.97.19.15 0% 31 35.9ms 33 28.6 41.7 3 <MPLS:L=361891,E=0> 11 50.97.17.30 71% 31 timeout 35.3 29.8 42.8 4.9 <MPLS:L=624054,E=0> 12 169.45.18.4 40% 31 58ms 56.4 50.6 61.6 3.1 <MPLS:L=311929,E=0> 13 169.45.18.41 0% 30 149.6ms 62.7 50.5 149.6 23.4 14 169.48.118.131 0% 30 133.4ms 59.8 50.2 133.4 14.7 Karim
Before the mob descends, I'll take the liberty of pointing you at this: https://archive.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Tracerou... If the loss does not extend past a given hop to the end of the trace, it's not loss - it's probably a transit router rate limiting your trace packets.
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. Now from the trace below : If you have zero packet loss to the final hop, how could you possibly have packet loss along the path? Answer, you can't and there is no loss between you and the final hop for your traffic. What you are seeing is the intermediate node not bothering or being too busy to answer your ping. Steven Naslund Chicago IL From: NANOG <nanog-bounces@nanog.org> On Behalf Of K MEKKAOUI Sent: Monday, September 23, 2019 4:10 PM To: nanog@nanog.org Subject: NetworkLayer Hi Anyone from Network Layer to help? We are experiencing packet loss on the their MPLS network. I have attached a screenshot. Thank you 4 38.140.46.161 0% 31 16.3ms 18.6 6.4 153.1 24.9 5 154.54.45.113 0% 31 9.8ms 13.9 9 19.2 2.9 6 62.115.168.46 0% 31 12.5ms 16.3 10.2 66 9.7 7 62.115.134.48 0% 31 25.6ms 23.4 16.5 39.2 5.7 8 62.115.51.98 0% 31 19.4ms 22.6 16.6 49.9 6.1 9 50.97.19.12 0% 31 20.2ms 22 12.8 37.9 4.3 <MPLS:L=388134,E=0> 10 50.97.19.15 0% 31 35.9ms 33 28.6 41.7 3 <MPLS:L=361891,E=0> 11 50.97.17.30 71% 31 timeout 35.3 29.8 42.8 4.9 <MPLS:L=624054,E=0> 12 169.45.18.4 40% 31 58ms 56.4 50.6 61.6 3.1 <MPLS:L=311929,E=0> 13 169.45.18.41 0% 30 149.6ms 62.7 50.5 149.6 23.4 14 169.48.118.131 0% 30 133.4ms 59.8 50.2 133.4 14.7 Karim
On Tue, 24 Sep 2019 at 00:59, Naslund, Steve <SNaslund@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. -- ++ytti
participants (4)
-
K MEKKAOUI -
Naslund, Steve -
Phil Lavin -
Saku Ytti