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...:
Any pointers or feedback about this would be great... I'm guessing this could be resolved using iptables? Well I'm not all that clued up with iptables, hence my pleading for assistance =)

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
Let's do a traceroute...
Great. Now let's put up ppp1, an account with another ISP
Ok, now let's say I route a subnet via ppp1 which could be reachable via both ppp0 or ppp1, but that I'd hypothetically have routed via ppp1 because it belongs to that respective ISP, or because reaching it would take a shorter path via this ISP.
^ Well what do you know! Notice that the IP of the 5th hop of the first traceroute (196.26.0.10) is part of the subnet I just added to ppp1
Now I do a traceroute to the very same IP as before, which will again be routed via default (ppp0), this time with one of the hops (hop 5) being routed via another interface (ppp1)
Notice how hop 5 shows as filtered/unreachable -- this is the behaviour I'm describing

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:
and then reboot