Mikrotik Traceroute Empty: Causes & Solutions

by

Traceroute, a network diagnostic tool, sometime returns empty result when it is executed on MikroTik routers due to several reasons. Firewall rules configured on MikroTik devices sometimes block the ICMP packets which traceroute uses to map the route of a network connection. Incorrect network configuration on the router like default gateway setup, DNS configuration, or interface settings can lead to traceroute failing to display any information. Another potential cause is related to MTU Size, where a large MTU can result in packet fragmentation, leading to a failure in traceroute operations if the network does not properly support it.

Unveiling the Mystery of a Silent Traceroute

Ever felt like you’re shouting into the void? That’s what it’s like when your traceroute command comes back empty on your Mikrotik RouterOS device! Traceroute is our trusty network detective, right? It’s the tool we use to map out the internet’s hidden pathways, showing us each hop our data takes to reach its destination.

So, when it goes silent? Cue the head-scratching and maybe a little bit of internal screaming.

This post is your guide to turning that silent traceroute into a talkative one. We’ll walk through a treasure map of troubleshooting steps to unearth the reasons why your Mikrotik is keeping secrets. Is it a firewall doing its job a little too well? Perhaps a quirky routing issue? Or maybe, just maybe, the culprit lies beyond your own network. Whatever the reason, we’ll equip you with the knowledge to hunt it down, from your firewall to the great beyond.

Traceroute Demystified: How it Works (and Why It Sometimes Doesn’t)

Alright, let’s get down to brass tacks and unravel the mystery of Traceroute! Think of it as your network’s personal GPS, a digital breadcrumb trail that shows you exactly which servers and routers your data hops through to reach its destination.

At its heart, Traceroute is a clever little tool that relies on a few key players. The star of the show is TTL, or Time To Live. Imagine each packet of data gets a limited number of “lives” – every time it passes through a router, its TTL decrements. Traceroute starts by sending out a packet with a TTL of 1. This packet makes it to the first router, the TTL hits zero, and boom! The router sends back an ICMP Time Exceeded message, basically saying, “Hey, this packet expired here!” Traceroute notes the router’s IP address, then sends out another packet with a TTL of 2, and so on, mapping each hop along the way. Think of it like a data-driven scavenger hunt!

This is where ICMP (Internet Control Message Protocol) comes into play. Those “Time Exceeded” messages? That’s ICMP doing the heavy lifting. It’s the messenger that relays the bad news (and the router’s address) back to you, painting a picture of your network path. Without ICMP, Traceroute would be completely in the dark.

And here’s a fun fact: while ICMP is the standard protocol for these “Time Exceeded” messages, some implementations of Traceroute get a little fancy and use UDP (User Datagram Protocol) instead. It’s like choosing a different delivery service – same principle, slightly different method.

But what happens when the journey goes silent? When you run Traceroute and get…nothing? That’s the problem we’re tackling here! When it fails, you won’t see any IP addresses, no hop counts – just the blinking cursor of doom. We’re going to dive into the reasons why this can happen, turning you from a frustrated user into a Traceroute troubleshooting ninja.

The Usual Suspects: Common Causes of Mikrotik Traceroute Failure

Alright, let’s put on our detective hats and dive into the murky world of why your Mikrotik traceroute might be ghosting you. It’s like inviting someone to a party, and they just… don’t show up, leaving you wondering what went wrong. Don’t worry, we’re about to unmask the culprits behind this network mystery! These are the most common reasons why your traceroute is failing to deliver the goods on your Mikrotik device.

Firewall Interference

Ah, the firewall – the bouncer of your network, deciding who gets in and who gets the boot. Sometimes, it can be a little too enthusiastic.

  • Firewall Rules (Input Chain): Think of the Input chain as the gatekeeper for traffic headed to the Mikrotik itself. If a rule here blocks incoming ICMP Time Exceeded messages (those little notes routers send back saying, “Hey, my TTL expired!”), your traceroute will never know the path. Imagine you send a letter, but the post office refuses to deliver the “undeliverable” notes back to you. You’d never know where it got lost!

    • Real-World Example: You’ve set up a firewall rule to drop all ICMP traffic to protect against ping floods (a common security measure). While this protects against attacks, it also silences those crucial ICMP Time Exceeded messages that traceroute relies on.
  • Firewall Rules (Forward Chain): The Forward chain handles traffic passing through the Mikrotik. If rules here are too restrictive, they might mangle or drop the traceroute packets themselves, preventing them from reaching their destination.
  • Firewall Rules (Output Chain): This is less common, but the Output chain can block the initial traceroute packets from even leaving the Mikrotik. This is rare but worth a check if you’ve got some very specific output filtering in place.
  • ICMP Filtering: Some admins create specific rules to drop certain types of ICMP packets. Use /ip firewall filter print to hunt down these rules. Look for anything targeting ICMP (protocol=icmp) and dropping packets (action=drop).
  • Bridge Configuration: If your Mikrotik is acting as a bridge, firewall rules applied to the bridge interface can also wreak havoc on traceroute. Make sure the bridge isn’t inadvertently blocking ICMP or UDP traffic.
  • Best Practice: This is crucial: Document everything! When you make firewall changes, leave a comment explaining what you did and why. Future you will thank you, especially when troubleshooting at 3 AM.

Routing Issues

Routing is like the GPS of your network. If it’s got the wrong directions, your packets are going to end up in the digital equivalent of Timbuktu.

  • Incorrect or missing routes can mean your traceroute packets never reach their destination, or even worse, the return ICMP messages can’t find their way back to you. It’s like sending a package with no return address – if it can’t be delivered, it’s just lost forever.

  • Use the /ip route print command to see your Mikrotik’s routing table.

    • Example Output:

      Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, P - prohibit
DAc  0.0.0.0/0        gateway=192.168.1.1  interface=ether1
DAc  192.168.1.0/24   interface=ether1

    • The 0.0.0.0/0 route is your default route – where packets go if there’s no specific route. Make sure it’s pointing to the correct gateway. Also, check for specific routes to the target network; if those are missing or incorrect, that’s your problem.

  • Troubleshooting Tip: Always double-check your default route (the gateway to the outside world) and any specific routes to the destination network you’re trying to reach.

NAT (Network Address Translation) Problems

NAT is like having a translator for your network. If the translation is off, things get garbled.

  • NAT misconfiguration can really mess with traceroute, especially when your Mikrotik is acting as a gateway. It can alter the source IP address of the traceroute packets, which can confuse return routes, making the ICMP responses go astray.
  • NAT rules determine how your internal IP addresses are translated to public IP addresses. If these rules aren’t correctly set up for ICMP traffic, your traceroute results will be incomplete or non-existent.
  • Configuration Advice: Carefully review your NAT rules. Ensure that they are correctly configured to handle ICMP traffic. A misconfigured NAT rule could be rewriting the source IP in a way that prevents the ICMP Time Exceeded packets from finding their way back. Use /ip firewall nat print to review your NAT configuration.

MTU (Maximum Transmission Unit) Mismatch

MTU is like the size of the truck carrying your data. If the road has a low bridge (a smaller MTU), the truck has to be broken down into smaller pieces (fragmentation), which can cause problems.

  • If the MTU size on one of your network interfaces is smaller than what’s needed for the traceroute packets, the packets will be fragmented. Sometimes, these fragmented packets get dropped along the way, causing traceroute to fail.
  • You can diagnose MTU issues using the ping command with the “do-not-fragment” (DF) bit set. ping [destination] -f -l [size] (where size is slightly less than the suspected MTU). If the ping fails, it means the packet is too big and needs to be fragmented, indicating an MTU issue.
  • If you identify an MTU mismatch, adjust the MTU settings on the relevant interfaces (/interface ethernet set [interface] mtu=[value]). Experiment with slightly smaller MTU values until traceroute starts working.

External Factors Beyond Your Control

Sometimes, the problem isn’t you – it’s them!

  • Upstream Routers: Some routers, especially those belonging to your ISP, might be configured not to send ICMP responses. This is often done for security or performance reasons, and you can’t do much about it.
  • ISP (Internet Service Provider): Your ISP might be filtering ICMP or experiencing routing issues that affect traceroute. They might be having a bad day too!
  • Destination Network: The destination network you’re trying to traceroute to might be blocking traceroute attempts for security reasons. Some networks consider traceroute a form of reconnaissance and block it accordingly.
  • Troubleshooting Tip: Try tracerouting to multiple destinations. If the problem is only with one network, the issue likely lies with them, not you. If all traceroutes are failing, the problem is probably closer to home.

Diagnostic Toolkit: Time to Put on Your Detective Hat!

So, your traceroute is still ghosting you, huh? Don’t worry, we’re about to roll up our sleeves and get our hands dirty with some serious diagnostic tools. Think of this section as your digital detective kit, complete with gadgets to sniff out the culprit behind the silent traceroute. We’ll be diving into Mikrotik’s arsenal and venturing into the world of packet analysis, so buckle up!

Ping: The Old Reliable Knock on the Door

First up, the trusty Ping command. It’s the equivalent of knocking on the door to see if anyone’s home.

  • How to Use It: Open your Mikrotik terminal and type ping [destination IP address or hostname]. For example, ping google.com.
  • What to Look For:
    • Packet Loss: If you’re losing packets, that’s a big red flag. It means there’s a connectivity problem somewhere along the line.
    • Latency: High latency (the time it takes for a packet to return) can also indicate network congestion or other issues.
    • Unreachable: If you receive a “destination host unreachable” message it means you have a configuration or routing issue

Torch: Mikrotik’s Built-in Packet Inspector

Ever wanted to see network traffic in real-time? That’s where Torch comes in! It’s like having a live feed of what’s happening on your network.

  • How to Use It: In your Mikrotik terminal, type tool torch [interface]. Replace [interface] with the interface you want to monitor (e.g., ether1).
  • Filter Settings: To focus on ICMP traffic, use the following filter settings in Torch:
    • protocol=icmp
  • What to Look For: Dropped packets, unusual traffic patterns, or anything that looks out of the ordinary. This is where you play detective! If you’re not seeing ICMP replies from the device you’re trying to traceroute to, you’ll see that here.

Wireshark/tcpdump: The Packet Sniffing Powerhouse

For a more in-depth analysis, Wireshark and tcpdump are your go-to tools. These are like having a microscope for your network traffic.

  • How to Use It:
    • Wireshark: Install Wireshark on a computer connected to the same network as your Mikrotik. Start a capture on the relevant interface and reproduce the traceroute.
    • tcpdump: Use tcpdump -i [interface] -w [filename].pcap on a Linux machine, replacing [interface] and [filename] with the appropriate values. You can then open the .pcap file in Wireshark for analysis.
  • Filtering Traffic: In Wireshark, use the filter icmp to focus on ICMP packets.
  • What to Look For: Examine the captured packets to see if your Traceroute requests are reaching the destination and if any ICMP Time Exceeded messages are being returned. Analyze the source and destination addresses, TTL values, and any error messages.

RouterOS Logging: Digging for Buried Treasure

Sometimes, the answers are hidden in the logs. RouterOS Logging can provide valuable clues about what’s happening behind the scenes.

  • How to Configure It: Go to System > Logging in Winbox or use the /system logging command in the terminal.
  • Log Filter Settings: Create a new logging action with the following settings:
    • Topics: firewall, info, error
    • Prefix: TRACEROUTE_DEBUG
  • What to Look For: Search the logs for “TRACEROUTE_DEBUG” entries or any messages related to firewall events, dropped packets, or ICMP errors. These logs can help you pinpoint exactly where the problem is occurring.

Interface Status: Are Your Cables Plugged In? (And Other Important Questions)

Sometimes, the simplest things are the easiest to overlook. Checking the status of your network interfaces can reveal hidden problems.

  • How to Check: In Winbox, go to Interfaces. In the terminal, use the /interface print command.
  • What to Look For:
    • Packet Loss: High packet loss on an interface is a major problem.
    • CRC Errors: These indicate data corruption, often due to faulty cabling or hardware.
    • Duplex Mismatches: Ensure that the duplex settings on both ends of the connection are the same (e.g., both set to auto-negotiate or both set to full duplex).

By methodically working through these tools, you’ll be well on your way to uncovering the mystery of your silent traceroute and restoring functionality to your Mikrotik network. Happy hunting!

Solutions and Configuration Tweaks: Restoring Traceroute Functionality

Alright, sleuths! You’ve put on your detective hats, identified the likely suspects behind your silent Traceroute, and now it’s time to roll up your sleeves and implement some fixes. Think of this section as your practical guide to rehabilitating your network’s Traceroute functionality. We’re not just pointing fingers; we’re fixing the problem!

Firewall Rule Adjustments

So, your firewall is being a little too enthusiastic with its “block everything that moves” policy, huh? We need to gently persuade it to let those crucial ICMP Time Exceeded messages through. Here’s how we can make those adjustments on your Mikrotik RouterOS device.

  1. Access Your Firewall Rules: Fire up Winbox or connect via SSH, and navigate to IP > Firewall.

  2. Identify Blocking Rules: Carefully review your Input chain rules. Look for anything that might be dropping ICMP traffic. Pay special attention to rules with action set to drop or reject. A common culprit is a rule that blocks all ICMP without specifying exceptions.

  3. Create an Exception:

    • Click the “+” button to add a new rule.
    • In the General tab:
      • Set Chain to Input.
      • Set Protocol to icmp.
      • Under Icmp Types, specify time-exceeded.
    • In the Action tab:
      • Set Action to accept.
    • Move this new rule above any existing rules that might be blocking ICMP. Rule order matters!

  4. Specific Targeting (Optional): If you only want to allow Traceroute from specific networks or hosts, you can add Src. Address or other criteria in the General tab.

Safety Note: Before you go wild with the firewall hammer, always back up your configuration. Go to Files > Backup in Winbox. You’ll thank yourself later if something goes sideways. Trust me, I’ve been there!

Route Configuration

Is your traffic taking a scenic route through oblivion? Let’s get those routes straightened out! Sometimes the reason traceroute fails is not because packets are being blocked but, the device that is receiving them simply doesn’t know where to send a reply to.

  • Check Existing Routes: Type /ip route print in the terminal. This will dump your routing table.

  • Spot the Gaps: Look for a missing default route (dst-address=0.0.0.0/0) or a lack of specific routes to the networks you’re trying to Traceroute to.

  • Add a Static Route: If you’re missing a route, here’s how to add one:

    /ip route add dst-address=YOUR_DESTINATION_NETWORK gateway=YOUR_GATEWAY_IP

    Replace YOUR_DESTINATION_NETWORK with the IP address range of the network you are trying to reach (e.g., 8.8.8.8/32 for Google’s DNS), and YOUR_GATEWAY_IP with the IP address of your next-hop router.

  • Consider Dynamic Routing: For larger or more complex networks, dive into dynamic routing protocols like OSPF or BGP. These automatically learn and adapt to network changes. I won’t delve into this too much as that itself warrants its own blog post!

NAT Configuration Review

NAT (Network Address Translation) can sometimes be a bit of a trickster, disguising your packets in ways that confuse Traceroute. Here’s how to make sure it’s playing nice:

  • Examine Your NAT Rules: Go to IP > Firewall > NAT.

  • Identify Potential Issues: Look for rules that might be interfering with ICMP responses. For example, if you have a rule that masquerades all outgoing traffic but doesn’t handle ICMP properly, return packets might get lost.

  • Create NAT Rule for ICMP (If Needed): In some cases, you might need a specific NAT rule to ensure ICMP traffic is correctly translated:

    /ip firewall nat add chain=srcnat protocol=icmp action=masquerade out-interface=YOUR_OUTGOING_INTERFACE

    Replace YOUR_OUTGOING_INTERFACE with the name of the interface that connects to the internet (e.g., ether1).

MTU Adjustment

Is your network trying to send giant pizzas through tiny mail slots? That’s an MTU (Maximum Transmission Unit) problem! When MTU is not configured correctly, packets have to be fragmented and sometimes these fragments don’t arrive at the destination. This causes connectivity issues, like traceroute failing. Here’s how to deal with it:

  • Determine Current MTU: Check the MTU settings on your interfaces under Interfaces.

  • Ping with “Do Not Fragment”: Use ping with the -f (do not fragment) option to test the maximum MTU size.

    ping -f -l 1472 google.com (from a command prompt)

    If you get “Packet needs to be fragmented but DF set,” reduce the packet size (-l 1472) until it goes through. Add 28 to that number to get the MTU to configure on your Mikrotik interfaces (1472 + 28 = 1500).

  • Adjust Interface MTU: Set the MTU on your interfaces (especially the WAN interface) to the largest size that works without fragmentation.

    /interface ethernet set [ find name=ether1 ] mtu=1500

    Remember to test connectivity after each adjustment.

With these adjustments, you should be well on your way to getting your Traceroute back on track and shining a light on your network’s path once again!

Calling for Backup: When to Involve Your ISP

Alright, you’ve diligently gone through all the troubleshooting steps, tweaked your Mikrotik settings until your fingers are sore, and you’re still staring at a blank Traceroute screen. Don’t lose heart just yet! Sometimes, the gremlins aren’t hiding within your own network. Sometimes, the problem is bigger than your RouterOS kingdom. This is where you need to call in the cavalry – in this case, your Internet Service Provider (ISP).

But when exactly should you hoist the “Help, We’re Under Siege!” flag and dial up your ISP? Here’s the deal: If you’ve exhausted all the internal troubleshooting steps, like checking firewall rules, routing tables, and MTU settings, and Traceroute still refuses to cooperate, the issue might be lurking upstream, beyond your network’s borders.

Think of it like this: you’ve checked all the pipes in your house for a leak, but the water’s still not flowing. Maybe the problem isn’t in your house at all, but in the city’s main water line. That’s where the water company (your ISP) comes in.

So, you’re ready to call your ISP. What should you do? Here’s what you’ll want to do:

  • Document everything that you’ve tried and that you can replicate for them.
  • Prepare all the relevant information.
  • Test your router and your internet speed to see if they are what your ISP quoted.
  • If your ISP is filtering ICMP packets or routing issues that affect Traceroute it would be a good idea to ask them about it.
  • In the nicest way possible, explain what’s happening.

Here are a few scenarios that scream “ISP intervention needed!”:

  • Routing Oddities: You’re seeing strange or inconsistent routing paths in Traceroute results (when it does work intermittently, or when comparing to traceroutes from external online tools), especially if the first few hops look normal, then suddenly vanish. This could indicate a routing issue on your ISP’s network or further upstream.
  • ICMP Black Hole: You suspect your ISP might be filtering ICMP traffic altogether. While not common, some ISPs might implement aggressive filtering policies. If Ping tests are also failing consistently, this is a big red flag. Try Tracerouting to multiple, diverse destinations. If none of them work, it points to a widespread issue, likely with your ISP.
  • DNS Issues: You may want to check if you have DNS Issues because this will cause you to not be able to trace route at all!

When you do reach out to your ISP, be prepared to provide them with as much detail as possible. This includes:

  • Your account information (obviously!).
  • The destination you’re trying to Traceroute to (IP address or domain name).
  • The results of your troubleshooting steps (firewall rules checked, routing table analysis, etc.).
  • A clear explanation of the problem (“Traceroute is returning no results,” not just “the internet is broken!”).
  • The time and date you performed the traceroute so the ISP can backtrack if they were having an issue.

Essentially, you want to paint them a clear picture of the issue and demonstrate that you’ve done your homework. This will help them diagnose the problem more efficiently and get you back on track faster.

Remember, your ISP is your partner in ensuring a healthy internet connection. Don’t hesitate to reach out when you suspect the problem lies beyond your network’s walls. After all, even the mightiest network admins need a little backup sometimes!

So, next time your MikroTik traceroute decides to ghost you, don’t panic! Just run through these checks, and you’ll likely find the culprit hiding somewhere. Happy troubleshooting!

Related Posts:

Leave a Comment