Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: 1 [2]

Author Topic: Intermediate nodes’ higher reported rtt figure in the midst of traceroute  (Read 1203 times)

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 5443

It needs someone who knows how internet routing works to answer that, as I understood it the only real requirement of intermediate hops is they are compatible with the size of the packets been pushed through and as such wont do weird things like fragment up the data.

There is invisible hops as well, not every router announces itself.  e.g. on sky none of their core network hops are visible aside from the dslam.
Logged
Sky Fiber Pro - Billion 8800NL bridge & PFSense BOX running PFSense 2.4 - ECI Cab - LINE STATISTICS CLICK HERE

boost

  • Reg Member
  • ***
  • Posts: 711

"To It" vs. "Through It"

Far from a perfect analogy but this might help...

Imagine the water pump thingy in your house.

It's job is to move water THROUGH itself to where ever it may needed in your house. The sink. The shower.
Attached to all house water pumps is usually a diagnostic device. The water meter. In order to get the meter reading do we send a query THROUGH the pump to the sink or do we query the device housing/device chassis itself?

We (even if just with our eyes) look at the meter itself, not what is flowing through the meter.

The water pump does not care what the water meter does. It doesn't care if it even exists. FLOWING water THROUGH the pump is all it cares about.

In networking, there are usually two concepts that are referred to when talking about this stuff.

The DATA PLANE. Real traffic. THROUGH the device. The WATER itself. Often has lots of CPUs/ASICs dedicated to this one task.
The CONTROL PLANE. The water METER. TO the device. Often has just one CPU 'sorta dedicated' to this task.

When you happen to pass traffic through a router, by innocently browsing to some website or playing a game, your traffic falls under the DATA PLANE concept.
When you ping a router directly or perform a traceroute (which elicits a response from the router directly) your traffic falls under the CONTROL PLANE.

The control plane will often exhibit symptoms of higher latency even if the data plane is working perfectly. It's like if you've ever worked in a company where the sales team always get the red carpet treatment but the support team get the scraps. The data plane is the money. It's the real traffic. The control plane is subservient and de-prioritised.

On top of this, there are ways to further de-prioritise control plane responses. Control Plane Policing, for example:

https://www.cisco.com/c/en/us/about/security-center/copp-best-practices.html


In short, there are a whole bunch of reasons to take everything you see in a traceroute with a pinch of salt.

I stumbled across this PDF by Richard Steenbergen a few years ago and found it very useful:

https://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf

So how do we get around all of this? How do we accurately measure end to end latency?

Cisco has another handy tool for this called IP SLA:

https://learningnetwork.cisco.com/blogs/vip-perspectives/2017/06/13/ip-sla-fundamentals

Part of this toolset is the ability to send SIP-like traffic through the network and actually generate a MOS score based on the jitter/loss it observes. Brilliant for the enterprise but what about the home enthusiast, I hear you cry? :D

I don't have an answer for this but I'd be very interested to hear what others have found that works for them? :)

Here's a question for you to see if any of this stuff makes sense.

Ping typically uses ICMP (as does traceroute). ICMP is considered a diagnostic protocol. It's a control plane protocol.
If I ping the bbc.co.uk server, do the routers/hops I pass through to get there use their data plane or their control plane to route/forward my ping traffic?
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 24220
  • Over the Rainbow Bridge
    • The ELRepo Project

Here's a question for you to see if any of this stuff makes sense.

Ping typically uses ICMP (as does traceroute). ICMP is considered a diagnostic protocol. It's a control plane protocol.
If I ping the bbc.co.uk server, do the routers/hops I pass through to get there use their data plane or their control plane to route/forward my ping traffic?

A nice question.  :)
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

aesmith

  • Reg Member
  • ***
  • Posts: 726

Here's a question for you to see if any of this stuff makes sense.

Ping typically uses ICMP (as does traceroute). ICMP is considered a diagnostic protocol. It's a control plane protocol.
If I ping the bbc.co.uk server, do the routers/hops I pass through to get there use their data plane or their control plane to route/forward my ping traffic?
Data plane, as this would just be through traffic routed by IP destination address.  ICMP would only be treated differently if it's addressed to the router itself, in which case the router needs to interpret and decide if and how to respond.  By the way traceroute in many systems uses UDP as the discovery packet, although of course the TTL exceeded replies will be ICMP.  For example on Mac OSX (and I'd guess Unix and Linux) it's default is UDP, can be made to use ICMP with the "-I" option.  Cisco routers use UDP.

Regarding the original question, we see that a lot - intermediate hops apparently giving higher RTT that later hops or the final destination.  In general when troubleshooting a high RTT issue it would not be safe to use traceroute timings to try and diagnose where the delay is located.
« Last Edit: July 27, 2018, 08:40:44 AM by aesmith »
Logged

CarlT

  • Reg Member
  • ***
  • Posts: 909
  • Next generation network design and deployment

"To It" vs. "Through It"

Boost wins this thread.

The decision on whether to use data / forwarding plane or control / management plane is made really early on, too. For Weaver's delectation it's often done on nothing more than some bitwise operations on headers. The flow is then allocated to one of the planes, depending on configuration may have some additional inspection done on it for QoS / access control / reporting purposes then once that's done is placed into a hardware accelerated path and off it goes with just packets counted and queuing enforced per policy.

In the case of Linux-based kit ICMP is actually handled by the kernel. To handle it higher up in software where you may have more control you have to hook the ZCI.
Logged
-----
Deploying better networks, not just faster ones.

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 6382
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick

> I don't have an answer for this but I'd be very interested to hear what others have found that works for them? :)

Me too. And excellent tip about the Cisco thing. They seemed to have ‘gamed’ the system in a sensible way then, by choosing SIP which is something that looks relevant.

Definitely thanks to boost and CarlT for their answers and reading matter.
« Last Edit: September 23, 2018, 03:40:11 AM by Weaver »
Logged
Pages: 1 [2]
 

anything