Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Trace Route Hops omitted with IPV4 Fine With IPV6

    Scheduled Pinned Locked Moved Traffic Shaping
    6 Posts 3 Posters 952 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G
      ghkrauss
      last edited by ghkrauss

      Fellow Members:

      Any suggestions for the issue of omitted trace route hops with IPV4 but ok with IPV6. I have seen discussion of the topic but not a clear resolution. Fq-Codel is working fine otherwise.

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        Certain actions like policy routing will cause hops to appear missed on traceroute since it doesn't alter the TTL when passing through. It should only affect the firewall itself in those cases.

        Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • G
          ghkrauss
          last edited by

          Jim:

          Thank you for your response with respect to FQ-Codel. You refer to policy issues. Do you have any ideas as to areas I should investigate? The current Pfsense configuration for FQ-Codel follows that discussed in the Hangouts session. I have been using Pfsense for over 5 years now and fine it just gets better all the time. As such I try to refine our installation by taking advantage of new developments.

          Howard

          1 Reply Last reply Reply Quote 0
          • jimpJ
            jimp Rebel Alliance Developer Netgate
            last edited by

            Policy routing (rules with a gateway set) not "policy issues".

            If you have a rule with a gateway set, then it's perfectly normal to see "missing" hops in traceroute. It's not something that can be fixed or changed, that's part of how policy routing works.

            Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

            uptownVagrantU 1 Reply Last reply Reply Quote 0
            • G
              ghkrauss
              last edited by

              Jim:

              I now understand the issue. Thanks for taking the time to respond.

              Howard

              1 Reply Last reply Reply Quote 0
              • uptownVagrantU
                uptownVagrant @jimp
                last edited by

                @jimp I'm also seeing ICMP echo replies dropping when NAT is enabled, a limiter is being used, and the limiter is loaded with traffic. This is also documented in Playing with fq_codel in 2.4 and bug 9024.

                Issue 1:
                Using limiters on an interface, with outgoing NAT enabled, causes all ICMP echo reply traffic to drop when the limiter is loaded with large flows. I can reproduce this issue with the following configuration.

                • limiters created (any scheduler). One limiter for out and one limiter for in.
                • create a single child queue for the out limiter and one for the in limiter.
                • floating match IPv4 any rule on WAN Out using the out limiter child queue for in and in limiter child queue for out.
                • floating match IPV4 any rule on WAN In using the in limiter child queue for in and out limiter child queue for out.
                • load the limiter with traffic (most recently I've been using a netserver v2.6.0 on the WAN side and a Flent client on the LAN side running RRUL test)
                • start a constant ping from the client to the server during the RRUL test

                Both the flent.gz output and the constant ping will show a high rate of ICMP echo reply packets getting dropped. If NAT is disable you will not see ICMP echo reply drops. If NAT is enabled but the limiter is not being loaded with traffic you will not see ICMP echo reply drops.

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.