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 4843 times)

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick

Imagine we are doing a traceroute to example.com. There are six hops, say. Now our traceroute reports an RTT to node 4 which is higher than that to node 5. I am assuming that these RTTs are just that, they are not differences, that is they are for the whole round trip from the start to node n, and are not just for the last hop only, ie from node n-1 to node n and back.

Now why would an intermediate number be higher? Indeed how could it? I am ruling out one-off errors, so say we take a series average. The only explanation I can think of is that there is a weird delay at the intermediate node in returning the ping, but this delay is absent for node n+1. Perhaps because node n is very busy.

What do you think?
Logged

johnson

  • Reg Member
  • ***
  • Posts: 838

I have often wondered about this. My hand waving answer is that intermediary nodes may not prioritise ICMP requests, quite a lot do not even respond to them.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick

They ought to prioritise ICMPs. Do you think they get stuck in egress queues? Anyway that would make sense of it, would it not?
Logged

johnson

  • Reg Member
  • ***
  • Posts: 838

I don't know, but figure hops deep in links between datacenters have little reason to have ICMP responses enabled.

What purpose would it serve, other than to generate more traffic and expose another attack mechanism?
Logged

banger

  • Kitizen
  • ****
  • Posts: 1186
  • TTB 80/20

Johnson's theory is my understanding of intermediate routers as well.
Logged
Tim
talktalkbusiness.net & freenetname
Asus RT-AC68U and ZyXEL VMG1312-B10A Bridge on 80 Meg TTB Fibre

https://www.thinkbroadband.com/speedtest/1502566996147131655

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick

What about path MTU? Should not be wanting to break that by dropping Too Big responses/

And generally of course ICMP helps understand routing and diagnose problems, as we all know.

I would have thought that if the occasional mere malformed ping can break the network, then one has deeper problems and maybe needs to find some staff with clue. :-)
Logged

d2d4j

  • Kitizen
  • ****
  • Posts: 1103

Hi weaver

I am sorry, but I am struggling to understand why you are asking your question

Edge/intermediate systems are designed that way. If they respond at all, it would be a small delay. Ideally they should not respond and certainly not when under loading.

These systems could process petabytes of data

If you are thinking about monitoring of these, the owners will have internal monitoring running to them, which maybe shown on large screens, where simply if green all good, amber then red (bad)

So apologies for my not understanding

Many thanks

John
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick

@d2d4j - Indeed, just as you say, their own sysadmins will know what is going on with their own network. You and I are in agreement. I don't see any reason to be dropping ICMP responses. One should be able to be confident that malformed packets will not cause any problems, surely? Anyway, I am wandering off topic - my own fault. :-)

Obviously the benefit is to other people trying to work out what is going on.

I did not ask a question was not about whether or not ICMP responses should be generated or not, or whether ICMP should be blocked. Johnson mentioned ICMPs being enabled or otherwise.

I asked about the numbers.

You made me think of something: So here I go off-topic again. Were I designing such a system, then what I could do is just not bother generating an ICMP echo response if I am busy, one thing less to do. Also have a rate-limiter type counter on each link, and don't send one if it is "too soon", that is: if the time now minus the time last one was was sent on the link is less than some value.

But returning to the real question: if someone is trying to work out what the hop delay times are, this is hard, because the return path can be added in and how do you separate that back out again? Also some queuing time will be mixed in, and maybe you do, maybe you don't want to see that. It all depends on what you are trying to assess: the base physical network or the current state of it, including load.
Logged

niemand

  • Kitizen
  • ****
  • Posts: 1836

Hmm.

Depending on hardware and software normal packet forwarding is handled by ASICs, ICMP goes up the management plane and is handled by a different control plane. That is about all there is on that one. Networking is increasingly about decoupling forwarding plane from management plane.

Management planes are usually subject to what Cisco call control plane policing, rate limiting some ICMP responses to avoid processors that should be doing other, more productive things, being tied up responding to pings or traceroutes.

No-one cares about individual hop latency. Networks, unless the more modern kind like ours, really aren't that bothered. Routers shoving a terabit a second around aren't inspecting every packet for delay and aren't using some non-existent protocol to determine latency to each adjacent hop.
Logged

niemand

  • Kitizen
  • ****
  • Posts: 1836

What about path MTU? Should not be wanting to break that by dropping Too Big responses/

They won't: they will forward the ICMP in exactly the same manner as other traffic.
Logged

niemand

  • Kitizen
  • ****
  • Posts: 1836

They ought to prioritise ICMPs. Do you think they get stuck in egress queues? Anyway that would make sense of it, would it not?

No. If that were happening you'd see latency go higher and stay higher after whichever hop it gets stuck in a queue at.
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33879
  • Trinity: Most guys do.
    • http://www.kitz.co.uk

Can't ICMP echo (pings) be configured separately than ICMP destination messages (fragmentation) on high end routers. 
Quite a lot routers used for transit do have ICMP echo turned off, or deliberately set at low priority. It makes sense that busy (transit) routers should prioritise traffic over ICMP echo and just because ICMP echo is off it doesn't necessarily mean PMTU is also off.   

Problem is most home based routers just have one simple ICMP on/off which drops all ICMP traffic and when PMTU discovery can break.

----


ETA   Yes you can.  Example ICMP config options which can be set to ACCEPT or DROP

Code: [Select]
# Allow incoming ICMP: ping, MTU discovery, TTL expired
/sbin/iptables -A INPUT -i eth0 -p icmp -d $YOURBOX --icmp-type 8/0 -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p icmp -d $YOURBOX --icmp-type 3/4 -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p icmp -d $YOURBOX --icmp-type 11/0 -j ACCEPT
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

niemand

  • Kitizen
  • ****
  • Posts: 1836

Not really an issue for carrier networks. They will just be forwarding this, none of them will be addressed to them as they didn't originate the flow.

That's really the key point really. The difference between what just goes along the super-fast, hugely hardware assisted forwarding plane and what needs additional, time consuming, inspection.

In some cases that inspection involves work from CPUs currently engaged in converging routing tables. No real dilemma which gets the CPU time as a priority :)

As another reminder traffic going across a core network is often going inside MPLS. Depending on where the last label is popped and TTL allowed to increment the packet may still be in the MPLS domain so not running on native IP yet.
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP

yeah its about priority, whether low priority means deliberately delayed or just a sort of best efforts thing I dont know, but not all icmp packets can be lumped as unimportant, for ipv6 especially icmp is key for correct operation.  Although I dont know if intermediate ops matter for this or just endpoints.  As long as icmp packet forwarding isnt delayed I think its probably ok.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick

Kitz wrote:
>and just because ICMP echo is off it doesn't necessarily mean PMTU is also off.   

That is indeed what you would think, depending on the level of intelligence, and if it is handled by hardware then what determines it is how detailed the inspection performed by the hardware is.

Re Chrys' point about MPLS - I am not being a bit thick here: if we are still inside MPLS then would the node not just be totally invisible anyway, not seen as an IP hop? Or is there a system that inspects what is inside an MPLS payload anyway, and so could decrement a hop count?
Logged
Pages: [1] 2