split routing - traceroute not displaying unrouted hops
Hi guys,
Firstly, I'm new here... I've used linuxquestions.org from time to time, but never needed to register until now... hopefully someone can help... ;) An in-depth explanation of this issue is already described over here: http://newyork.ubuntuforums.org/show...4#post10241054 , so I will merely quote it again here - it seems nobody knows the solution over at Ubuntu's forums...: Quote:
Thanks! |
Seeing "*"'s during a traceroute usually indicates that ICMP is filtered, I wouldn't necessarily expect to see every hop
|
Thanks for the response
This is not a problem with external filtering then, the filtering must logically be taking place on my local machine if another distro doesn't show a 'filtered' output on the same exact connection? I'd like to know how to change this behaviour if anybody has any idea... |
You also need to remember that ICMP is a low priority protocol, if a router is under heavy load it may choose not to respond to ICMP packets
|
Thanks again for the feedback, but I don't know why you consider that a relevant explanation if you've read and understood the described problem...
I explained that the hops are only 'non-responsive' when that particular hop IP is routed elsewhere or is unrouted, and that this was not the case with previous linux distributions that I've used Let me try explain again... The behaviour goes explicitly as follows: If any of the hops is not routed via the same gateway/interface as the destination IP, no information about that hop will be displayed at all (asterix's will be displayed in that hop's place). That's all I'm saying, and that this was not the case previously for me (when using debian lenny) - before I'd even see the ISP's Private Class internal router IP's (which are not routed from my end) show up in the traceroute, and that's no longer the case. This is annoying because traceroutes take a long time now because as a result of my split routing, some of the intermediary hops are part of a subnet that routes via another interface and therefore are not displaying (and hence in turn, hanging/delaying the rest of the trace) when they would have before... I'm sure there must be a simple (iptables-based?) solution... I'm just intruiged that nobody has any idea yet, neither here or on the ubuntu forums. As I said, this is not a traceroute-specific problem, but a distribution issue, as all clients that lie behind this server (router), including windows machines, are now also experiencing this undesired 'phantom firewall' [so to speak] effect on traces, seemingly regardless of whether it's a UDP or ICMP trace |
Could you go through the process again but show the routing table at each stage ?
|
Sure, although surely there's already enough information provided? Well, as requested:
We start off with just one pppoe (internet) interface up - ppp0 Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
This may arguably be intended or expected behaviour now, but the point I'm trying to make is that it was not like this before. In fact, as I said, I'd often even see private LAN class subnets appear in the middle of a traceroute indicating that the ISP is internally routing via private class subnets (ie, something like 10.5.2.1) which, if I explicitly tried to trace those hops directly, I'd get an instant unreachable error. Of course now that IP wont even display in the first place, like it used to, because it's not typically routed/reachable on this fussy ubuntu server! xD In other words, it seems more natural that if the destination is routed and reachable via one interface, that traceroute should show the whole hop path irrespective of whether some/all of the constituent intermediary hops may be routed via another interface. It's as if it's taking the entire routing table into account for each hop, even if it's not going to end up using/routing via those other interfaces to reach the destination anyway in reality, and even though the hops are still an integral part of actual IP traffic via that route... so it should show these hops anyway Thanks |
I see ... it may be because the 5th hop via ppp1 is not the 5th hop via ppp0 - you're basically creating a "shortcut" which sends packets for hop 5 out a different interface. You could try shutting down ppp0 and seeing what the hop count is .. but really, this is expected behaviour. Unless 196.26.0.10 happens to be 5 hops or less via ppp1 you won't get an answer.
hth |
If anyone else stumbles upon this little pest, I found the solution (for my case at least)!:
rp_filter must be disabled for the relevant interfaces echo "0" > /proc/sys/net/ipv4/conf/all/rp_filter edit /etc/sysctl.conf: Quote:
|
All times are GMT -5. The time now is 02:50 AM. |