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@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
|