Trace Route Hops omitted with IPV4 Fine With IPV6
-
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.
-
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.
-
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
-
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.
-
Jim:
I now understand the issue. Thanks for taking the time to respond.
Howard
-
@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.