back to article Contrary to some, traceroute is very real – I should know, I helped make it work

A few weeks ago I stumbled onto an article titled "Traceroute isn’t real," which was reasonably entertaining while also not quite right in places. I assume the title is an allusion to birds aren’t real, a well-known satirical conspiracy theory, so perhaps the article should also be read as satire. You don’t need me to critique …

  1. John Smith 19 Gold badge
    Coat

    Interesting stuff

    Sorry but yes I do find this sort of stuff interesting.

    Without an understanding of how we got here, how will we know where to go next?

    Just a thought.

    1. Mike 137 Silver badge

      Re: Interesting stuff

      No apologies necessary -- you're absolutely right. The biggest problem we face for the future is successive echelons of notionally technical folks who understand less and less about how things actually work internally. And there are moves to make this even worse by paring down initial training.

      1. K555

        Re: Interesting stuff

        These are the people that hit tick-boxes in GUI configurations because the short description sounds useful and they have no idea about what they just configured.

        And, when things fall over and you have to explain why, they say 'that's stupid, why does it work like that?'

        Granted, a lot of tick box descriptions are indeed counter intuitive, which is why it's worth the google time to find out how things actually work underneath. Also, experience tells you that if it's one of those options you get on propitiatory pro-sumer gear says "automatically do magic fixes to my network and make things brilliant, with some mesh and stuff", treat the damn thing the same way you would a land mine.

        1. Anonymous Coward
          Anonymous Coward

          Re: Interesting stuff

          "Granted, a lot of tick box descriptions are indeed counter intuitive, which is why it's worth the google time to find out how things actually work underneath"

          I've worked with a lot of software that sucks at explaining tickboxes/options/flags/settings/etc. I see a boolean option named something like "frobinate_the_packet", check the help file and the help file informs me "Set frobinate_the_packet to "TRUE" to frobinate the packet, set it to "FALSE" to not frobinate the packet". Oh gee, thanks, that's the part I couldn't figure out. Setting a verb_the_noun option to true causes the action to be taken, I never could have guessed that. Meanwhile, no explanation of what frobinate does, why one would want to frobinate, what the downsides are if you do so, etc.

          1. K555

            Re: Interesting stuff

            Help textbox says: "This option can help in some circumstances but may have consequences"

        2. A.P. Veening Silver badge

          Re: Interesting stuff

          Also, experience tells you that if it's one of those options you get on propitiatory pro-sumer gear says "automatically do magic fixes to my network and make things brilliant, with some mesh and stuff", treat the damn thing the same way you would a land mine.

          I'd say with a lot more care, land mines are simple and easy to understand.

    2. GeekyOldFart

      Re: Interesting stuff

      "If you don't know where you're from, you don't know where you are. If you don't know where you are, you don't know where you're going. And if you don't know where you're going, you're probably going wrong."

    3. Philo T Farnsworth Silver badge

      Re: Interesting stuff

      I watched about half of the NANOG presentation upon which the blog posting to which Mr Davie is replying is based1 and found it edifying. I'm planning on watching the final half later today. Parenthetically, I'm not sure the video entirely supports the thesis in the blog, at least with respect to the usefulness of traceroute, though I will agree that a lot of people don't fully understand what they're seeing (including, in all candor, myself included).

      While I had sort of known most of what was in the video already, mostly from intuition and being around first rate network engineering and engineers enough for some of it to rub off2, it was useful to see it all laid out in a clear and cogent manner.

      ________________

      1 Can that get any more convoluted?

      2 I recommend immediately showering and scrubbing down with a Brillo to get it all off.

  2. Giles C Silver badge

    Well that explains the * * * output on the trace command, it is the ISP not wanting to see how the data goes through their internal network.

    When I used to trace MPLS paths I often wondered about that as it would go through our internal network to the SP router then the * before emerging on the SP exit router before wandering around our network on the other end.

    Mind you it doesn’t help when someone defines a static route on the firewall to an internal switch, and said internal switch has a default route of the firewall - this happened earlier this week, nobody admits to doing it though…

    1. Anonymous Coward
      Anonymous Coward

      really?

      admits? If you don't let them sign in as root you'd know who did it. You are logging all changes to an external syslog server, right? If you just need a small self-contained CYA solution, splunk or graylog would do you just fine.

    2. Jamie Jones Silver badge

      .Nah, nothing specifically to do with MLPS.

      The "* * *" simply means that the router at that point doesn't respond with the "ICMP time exceeded in-transit," packet, or it is filtered out somewhere.

      A common reason for seeing this isn't intentional - routers within an ISP that will only ever connect to some other router in the ISP can have private IP addresses. - They only ever route internally. So if one of those is in the path, you'll get an "ICMP time exceeded in-transit" from one of these addresses.

      For example, try a traceroute to catnip.dyslexicfish.net, as seen here:

      traceroute to catnip.dyslexicfish.net (104.238.172.250), 64 hops max, 40 byte packets

      1 [AS0] ipv4-router-home (172.20.0.1) 0.484 ms 0.353 ms 0.247 ms

      2 [AS12708] host-213-78-0-1.as13285.net (213.78.0.1) 15.578 ms 18.750 ms 18.081 ms

      3 [AS13285] host-78-144-0-105.as13285.net (78.144.0.105) 20.093 ms 19.680 ms 19.979 ms

      4 [AS13285] ae55-scr002.slh.as13285.net (78.144.1.46) 23.339 ms

      [AS13285] ae52-scr102.loh.as13285.net (78.144.1.30) 24.333 ms

      [AS13285] ae55-scr002.slh.as13285.net (78.144.1.46) 23.593 ms

      5 [AS13285] ae62-scr101.thw.as13285.net (78.144.1.114) 14.597 ms 14.849 ms 13.383 ms

      6 [AS0] vl32-br1-cer.lon3.choopa.net (195.66.226.176) 34.450 ms 14.247 ms 14.834 ms

      7 [AS0] 10.69.3.70 (10.69.3.70) 14.964 ms 15.332 ms 14.967 ms

      8 [AS0] 10.69.1.222 (10.69.1.222) 15.722 ms 16.145 ms 16.193 ms

      9 * * *

      10 [AS20473] catnip (104.238.172.250) 15.530 ms 19.968 ms 20.044 ms

      Hops 7 and 8 are "private lan" addresses internal to provider "choopa.net".

      (Hop 9 simply isn't responding)

      To parse hops 7 and 8, my machine received ICMP messages from those private addresses, but sourced from the internet, not my local network.

      Now, many people (or even ISPs) will filter out any "private lan" packets from entering their network (assuming they are spoofed addresses - but the above shows this isn't always the case). If you or your ISP do similar, hops 7 and 8 above will be "* * *" also.

    3. M.V. Lipvig Silver badge

      No, tracert worked just fine on the inside. It just didn't work if you were trying it from outside the network (and this is something I did not know.)

      Back in the late 1990s I was a frame relay repair tech for one of the rather large US telecoms. We also worked on ATM circuits, but I tried to avoid that pig's breakfast as much as I could. I don't remember a whole lot about the job, but do remember that on frame relay we could identify what actual physical circuit was down by running a tracert command and identifying the port where the trace stopped. Then, we sent a field tech out to fix it. For ATM, I dunno, we read coffee grounds or burned chicken feathers or something to find the fault. I can't remember and I like it that way.

      I've not worked on either frame relay or ATM in over 20 years now though.

  3. ecofeco Silver badge

    One of my favotire tools

    See title.

    Along with the rest of the family:

    ipconfig /all - Display Connection Configuration

    ipconfig /displaydns - Display DNS Cache Info Configuration

    ipconfig /flushdns - Clear DNS Cache

    ipconfig /release - Release All IP Address Connections

    ipconfig /renew - Renew All IP Address Connections

    ping <IP/URL> Test Reachability to destination

    pathping <IP/URL> - Combined functionality of Ping and Tracert

    netstat - Displays the TCP/IP protocol sessions:

    route - Display Local Route

    arp - Display Resolved MAC Addresses

    finger - Used to retrieve the information about a user on a network:

    tracert <IP/URL> - For tracing the path to a destination

    net Access and maintain a Microsoft File/Printer Sharing environment

    nslookup <URL> Name Server Lookup

    Hostname - Display Name of Computer Currently on: hostname

    control netconnections - Network Connections

    systeminfo - To see the system information

    1. Giles C Silver badge

      Re: One of my favotire tools

      Not sure why you got a load of downvotes for this, anyone who works as a network engineer will be using this all the time. I would add bgp / ospf commands to this, as once you know the data is going the wrong way you need to find out who is advertising the wrong route (also a request to other network admins please add a description to your bgp neighbours as it makes it easier to understand).

      1. ttlanhil

        Re: One of my favotire tools

        > Not sure why you got a load of downvotes for this

        I wasn't one of them, but I'd assume for listing windows tools; this is el reg, after all...

        1. AndrewB57

          Re: One of my favotire tools

          Not Windows, exactly, but DOS

          I assume the downvotes because MS-DOS is not the sainted Linux

          1. Anonymous Coward
            Anonymous Coward

            Re: One of my favotire tools

            Not Linux, standard Unix tools the internet was built on.

            In fact, Linux is diverging on that standard almost as much as Microsoft is.

            1. Anonymous Coward
              Anonymous Coward

              Re: One of my favotire tools

              Except for the fact that most Internet diagnostics are available on the Linux (and MacOS) commandline as standard whereas Windows does not have all of them.

              As for the list, I'd also add ntp tools to it - one of the things Windows does have quite reasonable diagnostics for, mainly because by default that's picked up from the AD but you can change it to something of a higher strata if you need more immediate accuracy (a lower strata just takes a bit longer to stabilise into a reasonable accuracy).

            2. M.V. Lipvig Silver badge

              Re: One of my favotire tools

              Must be diverging in a different direction, seeing as Linux just works while M$ just works you over.

        2. ecofeco Silver badge

          Re: One of my favotire tools

          Yeah, I hate M$ with a passion, but I have to use these tools every day and well, they just work.

          Old school DOS commands beat everything else in M$. And Power$hit is the usual M$ Frankenstein abomination.

          1. Anonymous Coward Silver badge
            Linux

            Re: One of my favotire tools

            Except DOS hasn't existed for a long while. You're presumably thinking of the command prompt (command.com / cmd.exe) which is indeed a powerful and useful way to deal with windows boxen.

            Powershell is a steaming pile of MS

            1. jake Silver badge

              Re: One of my favotire tools

              "Except DOS hasn't existed for a long while."

              I worked on a DOS based machine just this month. Idexx Vettest 8008 blood test machine. It will happily run on MS-DOS 5.0, but today it boots FreeDOS for logistical reasons. It runs from a single floppy, contains no HDD, and the display is a rather small LCD. This later model has a 386, 2 megs of RAM, an unused IDE controller and unused ISA expansion slot. They have odd memory mapping because of the LCD display, a small built-in thermal printer, and proprietary hardware for the blood work itself. I have never tried to plug in a HDD or expansion card, no point.

              "Powershell is a steaming pile of MS"

              You'll get no argument from me there :-)

            2. el_oscuro
              Linux

              Re: One of my favotire tools

              The Windows CMD shell has a syntax that is completely un-intuitive but surprisingly powerful and it has an excellent man page. That man page comes complete with many detailed examples on usage. You can access that man page with this command:

              [code]

              C:\> help

              [/code]

        3. Yes Me Silver badge
          Joke

          Re: One of my favotire tools

          I think the downvotes were for the American spelling; it should have been "favoutire".

          1. captain veg Silver badge

            Re: One of my favotire tools

            Favoutyre.

            -A.

      2. the spectacularly refined chap Silver badge

        Re: One of my favotire tools

        I just added another downvote since there are too many assumptions made, as if networking begins and end with configuring a basic home network.

        It assumes everything is DHCP. If not it's wrong.

        It assumes everything is TCP/IP. Not IP, but TCP/IP. Any IP network will also be using UDP/IP and ICMP as a minimum. That is before even considering any other network layer protocols also in operation. Traceroute is the sort of tool aimed at the people that need to consider all the bases.

        1. Anonymous Coward
          Anonymous Coward

          Re: One of my favotire tools

          No the original poster said these are SOME of my favourite tools.

          Besides ping and traceroute both normally run on icmp as far as I know.

          Just because a list doesn’t include what YOU consider to be essential tools doesn’t make it invalid.

          Regarding dhcp all of the client networks I work on use dhcp for client addressing and a lot of networking problems are to do with clients.

          Ipconfig also works on static ip addresses very well and is easier than the gui - for Linux just use ifconfig most of the options are similar.

          1. Lunatic Looking For Asylum
            Mushroom

            Re: One of my favotire tools

            Damn - now I've got Julie Andrews singing in my head.

            1. M.V. Lipvig Silver badge

              Re: One of my favotire tools

              You bastard! I didn't, until you plugged that cable in!

        2. Ken Moorhouse Silver badge

          Re: It assumes everything is DHCP. If not it's wrong.

          Not going to embarrass the vendor here, but I used to have Wireshark logs which show a WellKnownRouterBrand dishing out the same IP address to two devices in close sequence. Notified them, but I've never seen this advertised as "fixed", but then again I've moved on from using their products...

        3. ecofeco Silver badge

          Re: One of my favotire tools

          Being a pendant is not considered a noble trait.

          Making assumptions, even less so.

          1. Anonymous Coward Silver badge
            Facepalm

            Re: One of my favotire tools

            Do you perchance mean "pedant"?

            1. molletts

              Re: One of my favotire tools

              Don't hold your breath for a reply - if he's a pendant, he'll probably just leave you hanging too.

              1. AndrewB57

                Re: One of my favotire tools

                Underrated comment

            2. John Sager

              Re: One of my favotire tools

              It's an in-reference to another well-known blog in certain circles. It's author even used to write here once upon a time.

          2. barryc

            Re: One of my favotire tools

            I'm a Pedant.

            Appreciated in Proof Reading Circles.

            This thread has lost its way.

        4. Yes Me Silver badge

          Re: One of my favotire tools

          The big false assumption is that it assumes everything is IPv4

          1. KarMann Silver badge
            Facepalm

            Re: One of my favotire tools

            Even bigger than assuming that an URL and a (sub)domain name are the same thing, though?

    2. el_oscuro

      Re: One of my favotire tools

      Like you, I used to drive windows from a command prompt, and know all of these commands like the back of my hand. I remember one time when the network between our primary and standby went down. Checking it with tracert, I discovered the packets were getting sent into an endless loop between hops before dying with TTL dysentery. At least it made for an amusing email to our network admins.

    3. JT_3K

      Re: One of my favotire tools

      You missed an important part. The ability to chain commands with '&&'.

      'ipconfig /release && ipconfig /renew'

      A godsend when working remotely.

  4. Jou (Mxyzptlk) Silver badge

    Nice historic view!

    Going back to where things started gives a nice insight, and this article is a nice example. I have to yet fiund an MPLS which does not hide their routing from traceroute. On the other hand hiding it simplifies it on the ends of that MPLS connection since the networks those packets pass through don't have to be known or seen. Again a tradeoff question.

    1. Jamie Jones Silver badge

      Re: Nice historic view!

      Are you using a traceroute that will show this information?

      I've tried tracing (with mtr --mpls) to syd-au-ping.vultr.com. from various UK addresses, and one in Paris, and they all go through telstraglobal. Part of the trace shows:

      8. HK | AS4637 | i-1003.ulcn-core01.telstraglobal.net (202.84.178.9)

      HK | AS4637 | i-1052.1wlt-core02.telstraglobal.net (202.84.143.169)

      HK | AS4637 | i-1004.1wlt-core02.telstraglobal.net (202.84.249.5)

      9. HK | AS4637 | i-1052.1wlt-core02.telstraglobal.net (202.84.143.169)

      [MPLS: Lbl 24150 TC 2 S 1 TTL 255]

      HK | AS4637 | i-1004.1wlt-core02.telstraglobal.net (202.84.249.5)

      [MPLS: Lbl 24150 TC 2 S 1 TTL 255]

      10. HK | AS4637 | i-1004.1wlt-core02.telstraglobal.net (202.84.249.5)

      [MPLS: Lbl 24150 TC 2 S 1 TTL 255]

      HK | AS4637 | i-1052.1wlt-core02.telstraglobal.net (202.84.143.169)

      [MPLS: Lbl 24150 TC 2 S 1 TTL 255]

      HK | AS4637 | i-10406.sydo-core04.telstraglobal.net (202.84.141.226)

      11. AU | AS1221 | bundle-ether4.oxf-gw30.sydney.telstra.net (203.50.13.93)

      HK | AS4637 | i-10406.sydo-core04.telstraglobal.net (202.84.141.226)

      EDIT: El Reg, fix your "PRE" parsing code!

  5. doublelayer Silver badge

    Responding to headlines never helps

    This article's author goes to great lengths to argue against another post based on that post's admittedly bad headline. The reason for that is simple: the author has seen the "isn't real" bit of the headline and jumped to bad conclusions. It's not literal, but it's also not satire a la "birds aren't real". The article itself explains what they mean with the frequent claims that traceroute "doesn't exist":

    From a network perspective, traceroute does not exist. It's simply an exploit, a trick someone discovered, so it's to be expected that it has no defined qualities. It's just random junk being thrown at a host, hoping that everything along the paths responds in a way that they are explicitly not required to. Is it any surprise that the resulting signal to noise ratio is awful?

    I would have phrased this differently, without the hyperbole, because that clearly causes problems. This response makes no point relevant to the network administration consequences of a traceroute command that is pretty much only usable by people with a lot of knowledge about the topology of any networks they're tracing through and plenty more about what that command is actually doing. Where it does respond, specifically the viability of traceroute in MPLS, it simplifies the problem by pointing out that you can, if you desire, manually implement the TTL field, then goes on to describe the many different ways you can choose not to, ways that everyone chose to use. It is fair to say the author of the anti-traceroute article got it wrong when they claimed that MPLS couldn't support it, but in practice, "couldn't support" looks very similar to "doesn't because they deliberately chose not to". It is similar enough that it doesn't invalidate the author's main point, that traceroute is a command that is dangerous in the hands of people who aren't good at understanding why it doesn't give them as much information as they think it does.

  6. Malcolm Weir

    But the original "anti-traceroute" post was... inaccurate

    Maybe I'm the only person who does this, but fairly frequently I want to know how my packets are exiting my network, aka "is the VPN down again?".

    Traceroute does that perfectly, and I don't know of anything as easy to use that comes close to providing that functionality.

    Sure, the author of the original screed may not want to, but he does go to extraordinary lengths to try to justify his lack of imagination to see valid use cases that traceroute addresses. Possibly he's lucky not to have seen issues that traceroute helped solve, but I'd opine he's more naive than lucky!

  7. Grunchy Silver badge

    I love the article even though it is way WAY over my head. I never “grokked” any of this network stuff, and for all of the ‘90s had a simmering anger for stupid IP configs that stubbornly refused to work for no apparent reason.

    Sure I tried traceroute, I got the result: big deal. I’m just an ISP customer, “where” the traffic goes is meaningless information to a layperson like me. (Actually, I always figured this might reveal some susceptible server that I could overwhelm with DDOS, if I ever had any idea how that worked or how to do it, but I never overcame the “don’t care” energy threshold necessary to get involved.)

    Here’s the bee in my bonnet today: spontaneously I can no longer play YouTube content more than 60 seconds before the spinny wheel takes over. Is it cache or Adblock or router needs reboot? Eventually after trying everything I just activated the “video download helper” and watch via VLC instead. Shrug! Something broke and I have zero idea about this network business. Voodoo curse, perhaps Friday 13, or some other thing, shrug!

    1. This post has been deleted by its author

    2. Justin Pasher

      For the everyday end user, traceroute is a great way to find out where latency gets introduced.

      Are you noticing a slowdown in a service and suddenly getting 100+ ms pings to the server? Is it your ISP? The hand off between your ISP and the next backbone? The target server? If you observe where the ping times jump (assuming the hops respond to ping), you can use this to narrow down the source.

      Like some others said, you can also use it to see if traffic is going out the correct connection (e.g. VPN).

    3. stiine Silver badge
      Unhappy

      its NoScript. jnn-pa.googleapis.com has to be allowed since friday. The other bugbear is that Alphabet is consilidating all of their load balancers, and with it, their ip addresses. This means that ip addresses that were formerly assigned to doubleclick.net hosts are not also assigned to googlevideo.com hosts, along with calendar.google.com and meet.google.com, and probably others. This means that if you have an out-of-date ip block list for doubleclick.net, you are actually blocking anything and everything alphabet/google/youtube...randomly.

      1. This post has been deleted by its author

  8. This post has been deleted by its author

  9. hammarbtyp
    Coat

    Great article. However in defence of ATM, it was designed to allow highly efficient hardware switching and therefore high throughput. It was designed around the limitations of the day, but as general purpose processors became more powerful and more of the stack could be done in software that need waned.

    Saying that the TCP/IP protocol has a lot to be blamed for. The fixed header, poorly defined elements etc has meant over the years it has been abused that has led to a spaghetti of work arounds

    That's me with the 3 volume ATM manual in the loft

    1. ColinPa Silver badge

      It's the old problem

      You get the first version out there, and see how popular it is. If it is popular you can add more widgets to it.

      If you spend time up front doing all things, that with hindsight, you should have done, you would never ship it. Another problem is you can also add all the features you think might be used, in the original version, and then find they are not used, or have been superseded.

      I was told, get something out there, for people to try. When people come hammering on your door, add the things that multiple people want.

      (We had a "requirement" from one customer to change our product, because they had a bug in their application program, but had lost the source of their program. They thought it would be cheaper to get us to put some special code in than them rewrite their program from scratch! - so you need multiple people banging on your door to justify doing something)

      1. the spectacularly refined chap Silver badge

        Re: It's the old problem

        Cf the OSI network stack, which took so long to standardise that widespread adoption of IP had already filled the void it was intended to.

        In some ways that is not ideal, 30+ years on there is still no standard job submission protocol for IP, OSI had it from the start.

    2. Jellied Eel Silver badge

      Holy Wars

      Great article. However in defence of ATM, it was designed to allow highly efficient hardware switching and therefore high throughput. It was designed around the limitations of the day, but as general purpose processors became more powerful and more of the stack could be done in software that need waned

      Not really. I still argue that MPLS is kinda ATM's revenge. ATM was designed to replace circuit switched networks, support Multiple Protocols (hint, hint) and perhaps most importantly, provide some deterministic behaviour. But ATM was complicated, scarey, and a lot of the net-heads didn't understand it. So then as the article says, it often came down to cell tax..

      Saying that the TCP/IP protocol has a lot to be blamed for. The fixed header, poorly defined elements etc has meant over the years it has been abused that has led to a spaghetti of work arounds.

      Such is the nature of network engineering. Like the cell tax argument was mostly true, but the fault of the IP headers being so damn fat.. And mostly unused, and became even more bloated with IPv6. Plus curiosities inherited from the DoD days, where sender was more important than recipient, so source address came first. Then stuff like this-

      https://en.wikipedia.org/wiki/Differentiated_services

      DiffServ uses a 6-bit differentiated services code point (DSCP) in the 6-bit differentiated services field (DS field) in the IP header for packet classification purposes. The DS field, together with the ECN field, replaces the outdated IPv4 TOS field

      Which then allowed marketing types to look at... 64 classes of service! Make it so! This differentiates our service compared to our competitors who only offer 5! And then generally ignoring boring details like explaining how CoS really works, configuring it, training support to handle calls about packets ending up in the bit-bucket or why 64 classes don't really matter when there's only maybe 4 hardware queues.

      And at the same time-

      https://en.wikipedia.org/wiki/Type_of_service

      Prior to the redefinition, the ToS field could specify a datagram's priority and request a route for low-latency, high-throughput, or highly-reliable service. Based on these ToS values, a packet would be placed in a prioritized outgoing queue, or take a route with appropriate latency, throughput, or reliability.

      So ToS was actually rather useful, at least within a service provider's domain, but rarely got implemented. Despite my best <cough> efforts. And it was much the same with ECN. A rather handy thing to know, but became 'obsoleted' with the introduction of DSCP.. Just as VoIP was coming along and a firehose of UDP traffic aimed in the general direction of the bit bucket, even if that was given EF. And then there were VPNs, so FUN! with more headers, and trying to cram those down other L2VPNs. And then having to explain to customers that a 1500byte packet ain't going to fit down an xDSL circuit with a 1492byte MTU, and if you've set the DF bit, it's going to end up in the bit bucket..

      So luckily, and thanks to our dear author, MPLS came along so network engineers could sleep easier. F'it and forward it, along the most appropriate LSP, and all those IP annoyances (mostly) became an edge problem. Gimme a compact & bijou lable with the relevant information and I can forward/switch that faster than routing it. And then for additional FUN!, the Internet became just another VRF.

      Which is also getting back to the traceroute thing. As the author says, you can traceroute across LSPs, assuming you know how to drive traceroute. And it's implemented in the MPLS domain, which I'd argue it shouldn't be.. Because a) it gives the switch/routers more work to do and b) as an end-user, what can you do with the output anyway given actionable stuff like IP ToS and ECN have been 'obsoleted'? If a switch (router) or circuit is having a bad day, then floods of ICMP traffic needing to be processed might just make that worse. And in a well-behaved (mostly) SP, we already know about the problem(s) and are working on fixing them.

      But as an unashamed Bell-head. I love MPLS because I can switch Tbps of traffic, and most of the IP stuff became a software problem. It's still FUN! sometimes because in the kinds of networks I tend to deal with, there's no longer 'The' Internet, but potentially multiple Internets, all happily pretending not to be best-efforts in their own VRFs. But the late, great Jon Postel described the Internet best-

      https://datatracker.ietf.org/doc/html/rfc791

      The internet protocol does not provide a reliable communication facility. There are no acknowledgments either end-to-end or hop-by-hop. There is no error control for data, only a header checksum. There are no retransmissions. There is no flow control.

      But at least MPLS gives us network engineers a fighting chance of managing some of that stuff..

      1. stiine Silver badge

        Re: Holy Wars

        Does anyone other than me remember MS-DOS setting the ToS/DCP fields to make their applications more performant?

        1. Jellied Eel Silver badge

          Re: Holy Wars

          Does anyone other than me remember MS-DOS setting the ToS/DCP fields to make their applications more performant?

          Yep, but Windows (NT?) rather than DOS. And then hapless MS types getting flamed because if all MS packets give themselves the highest priority, then in an MS environment, they'll all have the same priority. Plus unless CoS/QoS is implemented on the network, those bits would just ignored anyway. Or when it started to get implemented, out-of-contract traffic would get set to best-efforts, because all traffic must be treated equally. On the Internet anyway.

      2. barryc

        Re: Holy Wars hmm

        A good RFC - but my favourite (apologies for UK spelling) are

        RFC 1149 and RFC 2549

        https://en.wikipedia.org/wiki/IP_over_Avian_Carriers

      3. Alan Brown Silver badge

        Re: Holy Wars

        "And then having to explain to customers that a 1500byte packet ain't going to fit down an xDSL circuit with a 1492byte MTU, and if you've set the DF bit, it's going to end up in the bit bucket.."

        I remember a large bank doing that and then telling customers on DSL that "You're the only one having that problem" when their Internet Banking portal failed to work as expected

        At the time DSL had only just been launched and the vast majority of users were still on dialup, but a nice journalist pointed out that they'd told more than 1000 people that particular porkie

        It still took over 6 months to be remedied

        1. Anonymous Coward
          Anonymous Coward

          Re: Holy Wars

          "1500byte packet ain't going to fit down an xDSL circuit with a 1492byte MTU, and if you've set the DF bit, it's going to end up in the bit bucket"

          Back in the (late? mid?) 1990s, long before xDSL was launched in the UK, there used to be a website listing "known broken websites" that were unreachable to people with a MTU smaller than 1500 in their network path - these were websites where either their hoster/provider or some part of the network infrastructure in front of them agressively filtered ICMP traffic (typically for "security" reasons) and so broke Path MTU Discovery ("https://en.wikipedia.org/wiki/Path_MTU_Discovery").

  10. Bebu sa Ware
    Coat

    Netheads v Bellheads

    The link to the '96 Wired article was incredibly interesting.

    The statement by Steve Deering

    "How about we come up with something *completely *brain-damaged. Then maybe the computer guys will notice.'"

    could be profitably applied to many recent "innovations."

    In the late '90s there were two University Campuses in AU that ran IP over ATM which was so successful that, after the lot was replaced in the noughties, one of the remaining complicit networking chaps denied its ever being deployed but forgot that he had documented the campus deployment on personal Uni web pages.

    Back then DEC OSF/1 had a kernel module that implemented classical IP over ATM which I had the misfortune to have to deal with. Its ability to cause random or acausal kernel panics would have been envied by Microsoft's Windows engineers.

    I don't think IP broadcasts played nicely with IP over ATM networks which could have been a problem for some legacy networking a protocols.

    In any case I think the netheads won. I believe most telephony, or at least LTE, is now carried over IP.

    Given that it was as much a packet v. circuit argument I suspect the last page hasn't been written.

    1. Jellied Eel Silver badge

      Re: Netheads v Bellheads

      I don't think IP broadcasts played nicely with IP over ATM networks which could have been a problem for some legacy networking a protocols.

      ATM supported broadcast and multicast traffic, arguably more reliably than IP.. But the problem isn't just 'legacy' protocols, it's mostly the way broadcasts are overused. So I developed L2VPNs and Ethernet over MPLS. Yey! Now broadcast storms can go global! And Microsoft of course has a lot to answer for, ie new patch, and Win11 is still merrily spewing out traffic, trying to find XBoxes, printers or 'My Phone' that don't exist. Would it be so hard to let those announce their presence if/when I connected them to my network(s)?

      But Pink Floyd described bad broadcast implementations.. and I was at that concert!

      https://www.youtube.com/watch?v=vi7cuAjArRs

      Then again, looking at Wireshark on a typical Win11 implementation, there's a LOT of traffic going 'Hello, Hello, is there anybody out there?' and I'm probably uncomfortable numbed to it. Luckily a decent switch should let you drop that junk.

      In any case I think the netheads won. I believe most telephony, or at least LTE, is now carried over IP.

      Ish.. Although ideally it's carried over MPLS. Which then gets into some politics, like 'net neutrality. Like I was involved in designing a new broadband network for a country with a very strict regulator. The network was EoMPLS/L2VPN and every access circuit had 128Kbps reserved with a TC of 5. Customers could use that, or not, but the regulator gave some heavy hints that that should be used for voice, given voice is a safety-of-life service and they'd be fined A LOT if end-users couldn't make emergency phone calls. Luckily that country wasn't the US, so could implement this, without falling foul of the 'net neutrality holy war. In the US, VoIP customers have died because they couldn't call and the FCC is still trying to sort out that mess..

      1. Paul Crawford Silver badge

        Re: Netheads v Bellheads

        In the US, VoIP customers have died because they couldn't call and the FCC is still trying to sort out that mess

        Essentially anything that is IP based has this problem and really the net neutrality debate is kind of a side show, but one that rapidly descends in to pointless partisan arguments.

        The goal of net neutrality, that ISP don't favour a given company, is not key here as it comes down to the question of priority for emergency calls and that should not depend upon who is paying for bandwidth (consumer or big tech).

        But the problem is one of how do you actually reserve bandwidth for this? The obvious technical one is for such traffic to use a QoS marker, but if the "free world" of anyone and everyone doing their own software/app/etc as soon as VoIP seems to get better treatment the fskers will simply use that marker to get one up over other traffic. Tragedy of the Commons.

        Of course if you use a proper phone and regulated phone service (i.e. so traffic that is genuinely for emergency services has a guarantee but only for specific call centres that deal with this) it becomes easy and the ISP's responsibility, but nobody want to pay for a guarantee allocation, they want "free" with the likes of Skype, etc, not causing expensive land-line calls.

        TL;DR you should never depend on consumer-grade IP traffic meeting any given service level.

        1. Jellied Eel Silver badge

          Re: Netheads v Bellheads

          The goal of net neutrality, that ISP don't favour a given company, is not key here as it comes down to the question of priority for emergency calls and that should not depend upon who is paying for bandwidth (consumer or big tech).

          Yep, but then that's the main point of the show. It's unsuprising that the divisions are pretty clearly defined by content providers who don't want to pay more for bandwidth, and network engineers who know that not all traffic is created equal, and some is more important than others. Plus regulators also understand the importance, hence incumbents can and do allow non-neutral services, when they make sense and aren't being abused for competitive advantage. The cost of bandwidth will always be an issue though for as long as there are asymettric traffic and cash flows.

          But the problem is one of how do you actually reserve bandwidth for this? The obvious technical one is for such traffic to use a QoS marker,

          You don't, but then CoS/QoS tends to confuse people who think it does. All it does is tell devices on the network the traffic priority, so TC5 or EF traffic is generally the 'special case' that gets expedited and skips the queues. Control packets or frames get the highest priority because if that traffic drops, everything has an annoying habit of collapsing into a steaming pile of bits. But an important principle of regulation is equality, ie everyone gets the same treatment whether they're wholesale, retail or the SP's own services.

          So it's a combination of the 128kbps not really being 'reserved' as such, just there'll be a policy alllowing 128kbps of TC5 traffic. If there's no traffic needing that priority, the whole circuit can be used. If a customer wants to prioritise 128kbps of CoD traffic, they can. But generally that's implemented at Layer 2, ie on the terminating NID and often a VLAN. Then SP customers can configure that on the routers they supply to prioritise their VoIP implementation. It gets trickier at the NNI/Peering level, but then that's generally not extended and the idea is to prioritise traffic to their own VoIP/E.911 gateways.

          TL;DR you should never depend on consumer-grade IP traffic meeting any given service level.

          Yep, which is why I was glad when I stopped doing business network design and focused on backbones. Yes, your Internet is down. Yes, I understand that your factory can't do anything because you decided to connect your business critical site to your SAP system with the cheapest xDSL service you could find..

  11. Colin Bull 1
    Happy

    Traceroute for voice telecoms ?

    I also am "even though it is way WAY over my head" reader.

    But i fantalise that traceroute be mandated for VOIP calls to allow a network of trusted sites ( similar to SPK DKIM for email ) to allow authorities to seek and destroy the spammers out of existence.

    Please tell me it is possible.

    I know the things can be fudged but that is the point of TRUSTED network nodes.

    1. stiine Silver badge

      Re: Traceroute for voice telecoms ?

      The issue is that the CLID can be spoofed by the caller. This allows for two types of calls: 1) outbound calls from company call centers with a CLID of the main inbound number (the one that they publish everywhere), and 2) scammers who write any number of convenience into the CLID because they know that their provider won't drop the calls because of invalid CLID.

      1. Jamie Jones Silver badge

        Re: Traceroute for voice telecoms ?

        Yep.. This falls neatly into the "circuit-switched vs packet-switched" conversation.

        As you know (but others might not) as a virtual circuit is created from "A" -> "B" , "B" just sends it's replies back along that same circuit (just as it would if it was a physical wired connection) - So "B" has no need to know any routing information for "A", so "A" can send whatever CLID it likes, and the connection will work. (Remember, the CLID is a bolted on piece of data that was added to give caller-id functionality - it's not a requirement for the network to work.

    2. Jamie Jones Silver badge

      Re: Traceroute for voice telecoms ?

      Adding to "stlines" response, and my previous response, the original Caller-id system on the traditional phone network was reliable because of trusted sites:

      It was all BT - so BT set the caller-id, and they errrm. trusted themselves. When talk-talk, sky, and other independents came along, BT had little choice but to either trust the CLI passed to them by the other provider, or mark it "unavailable". Similarly, in reverse.. Basically, the phone network providers had to trust each other to send the legitimate information.

      This is why international calls were marked "international" - BT etc. couldn't trust the plethora of international companies, so they blocked any CLI they received (not that there would be any, as the CLI standard was a Uk BT thing anyway)

      When a company has it's own switchboard, their peer (e.g. BT) has to again, trust the information that they are sent, although they can make sure the information matches one of the "allocated numbers" for that company, so, again, that isn't a problem, and means that companies can present any valid number, or simply not ("unavailable")

      So these are all the "trusted nodes" you talk about.

      The problem today is that anyone can set up their own PBX easily, and these (and/or their peers) are the "untrusted nodes"

      1. Colin Bull 1

        Re: Traceroute for voice telecoms ?

        I understand VERY WELL the problems of CLID, that was why I was suggesting traceroute could be used instead as a definitive list of hops a call has gone through and the ability for the authorities to see where a call has be originated from. If a switchboard is originating a spoofed CLID ( that they were not untitled to) they could be taken to task and dealt with.

        The present system where anyone can make voice calls with impunity has gone on too long. In my naivete I think it should be possible to chain together the hops and have some verification of the links in the chain of a VOIP call.

        1. Alan Brown Silver badge

          Re: Traceroute for voice telecoms ?

          There's an "originating number" buried a few layers further down than CLID which is used for billing purposes and this is what the Telcos get very upset about when it's tampered with (mostly because they don't get paid)

          Unfortunately the entire telco routing system works on the basis of anyone with access to the system being trusted, whjich simply isn't the case - as we saw in the 1990s with porn numbers being answered in Bracknell, using unallocated Niue numbering ranges (without the knowledge or permission of the Niue government)

          Telephone number range hijacking is an even older problem than IP range hijacking and as we're seeing with VOIP providers, there's little security for injection of spoofed caller-origin (and CLID) data

          Telcos get terminating revenue (typically 1/3 of the total call cost), so it's in their financial interest to route even spam calls (and is a "joint and several liability" path for responsibility that might be explored despite their "common carrier" claims). The recent "crackdown" on spoofed calls "to protect consumers" is nothing of the sort and all about telcos finding that the billing information has been falsified, so they're not being paid to terminate calls

  12. J.G.Harston Silver badge

    As always, perfect is the enemy of good enough.

  13. Gene Cash Silver badge

    "a two-page document outlining the basic ideas"

    I think that right there is the important part, and a lot of the reason ATM lost.

    Networking is complicated enough.

  14. logicalextreme

    Thanks for the read. Humbling, entertaining and a reminder that we should appreciate and pay our network engineers more. (I do not understand networking)

  15. Ken Moorhouse Silver badge

    Traceroute in combination with Looking Glass Servers

    I can't remember the nitty gritty now but one of my customers had a problem with their website. Anywhere in UK it worked fine, but in USA (their target market), surfers were being served up with the International Herald Tribune homepage. I managed to run Traceroute from locations across the USA to determine where the fault manifested itself, then contacted the relevant site. Turned out that a server along the path had been compromised, had to be rebuilt from scratch then forced to respond properly to DNS requests. In those days it could take several days for invalid DNS requests to be properly squashed which was a frustration.

  16. cassandratoday

    Labels as stacks

    Ack! You've left me wanting to know more about labels as stacks. Talk about a cliffhanger!

  17. Annihilator

    Tracer T

    My personal thanks for inadvertently giving us the gift of the young hacker who uses the “Tracer T” tool to hack Google and find out their internet speed and how many people are using Google at any one time. I probably watch this about once a year:

    https://www.youtube.com/watch?v=SXmv8quf_xM

    1. Asylum_visitor

      Re: Tracer T

      I rarely login here these days but had to just to give you an upvote for this late Monday afternoon humour! Tracer T has got some L337 hacker skills! :D

    2. K555

      Re: Tracer T

      I feel like I've just watched some source material for LinusTechTips.

  18. jake Silver badge

    Tools are tools.

    There are no bad tools, just bad craftsmen.

    It is up to you, the craftsman, to know when any given tool is, or is not, the correct tool for the task at hand.

  19. John 62

    A Terrible Mistake

    One of my university lecturers once referred to ATM as A Terrible Mistake. But people keep trying to make it happen. The cell tax is a big deal and ATM proponents must have been betting on ASICs getting faster and ignoring the possibility that general purpose processors and hacks would win in the end.

    Nortel and a few others tried to do an updated ATM called PBT (Provider Backbone Transport), which instead of all-singing all-dancing MPLS would be a stripped down version just for backbone networks. Basically Nortel wanted the Bellheads to pick their more Bell-oriented version of packet-switching. But Cisco was winning and Cisco was MPLS. PBT never got traction and Nortel couldn't compete with Cisco.

    https://www.lightreading.com/business-management/nortel-preps-new-pbt-switch

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like