On 06/21/07 11:47, Peter Rabbitson wrote:
You are misunderstanding how ICMP works. The modems themselves are hops, and the thing they connect to is another hop. Just look at the first several entries of a traceroute to any destination, and you will see what I mean. If you still do not believe me - pull the ISP side cable from the modem, while still having your router connected to it, and try to do a ping to somewhere. Look at the source of the dest. unreachable message - it will come from the modem, not from the linux box.
Um, if you are using bridging modems (like I am) you are incorrect. If you are using modem router combos, yes. Every single install that I have used bridging modems on between the Linux router and the ISP acts the same way. If I have a workstation behind a Linux router (that is doing basic NATing) connected to a bridging DSL / Cable modem and I unplug the phone line or the coax cable from the modem, it is the Linux box that sends the ICMP message, NOT the modem. This is as expected too. The bridging modems bridge the traffic from the ethernet to the DSL / cable modem which is in turn bridged from DSL / cable back to a network interface at the ISP. Thus there is one broadcast domain between the Linux router and the ISPs router. Thus there is not IP device between the Linux router and the ISP router to send an ICMP message back.
No, again, if you are dealing with modem router combos, I'll grant you what you say, but not on bridging modems.
This would be a problem with your router configuration. It is virtually impossible to have an upstream problem that would cause this. It either works both ways or does not at all.
No, it was not a fault with my router. It was a fault radio in an (W)ISPs core network. Completely out of my control. When the ISP replaced the piece of equipment in their core (not even on the link to me) things started working correctly again.
I thought so too, but it seems that the only thing that comes close (and still does not cut it) are the DGD patches. And (this is my personal opinion) the fact they have not been included in the kernel for such a long time, indicates there is something fishy about them.
I agree that something is not quite right about the DGD patches. Though, I've applied them to 2.6.21.5 and did not have any more luck with them, so I'm not sure that there is much use for them. However I think that the DGD tests and failures there is were related to my config not being right.
I myself am using a different approach as I am doing load balancing as well. A script sends icmp ping packets with large payloads to several destinations and computes the mean rtt. Then the ratio of both rtts is used to assign link weights. When no pings come back one of the weights will be 0, and effectively no routing will be performed through this link.
*nod* I am presently using dual load balanced SDSL circuits with automated (OSPF) failover at my office. This is working out VERY well. However the questions I'm asking have to do with a project for a different client.
Nothing above prevents you from doing this, although it is a bad idea. Of course if you know what you are doing and still want to do it - it's your system :)
The contracts for the connections dictate that one is only used as a backup. If the primary is up any and all traffic outbound is to go out over it. So, if traffic comes in over the backup, returning out bound traffic is to go out the primary. Seeing as how the DMZ behind this router is globally routable, I'm not worried about issues with asymmetric routes. There are asymmetric routes in the core all the time. In my opinion, it is only at the edge where you NAT that you have to maintain IP addresses and thus have to be very careful and avoide asymmetric routes. Also, seeing as how both circuits are an ethernet connection that can carry a frame size / MTU of 1500 byes, I don't see the problems that would be introduced by encapsulated traffic like PPPoE for one link verses the other link. In short, I'm willing to listen to problems with the asymmetric routes, but I have yet to hear any thing that concerns me or even chafes me a little.
Grant. . . . _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
