From: Grant Taylor <gtaylor@riverviewtech.net>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Redundant internet connections.
Date: Thu, 21 Jun 2007 17:02:50 +0000 [thread overview]
Message-ID: <467AAF3A.8090303@riverviewtech.net> (raw)
In-Reply-To: <467A2354.1070805@riverviewtech.net>
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
next prev parent reply other threads:[~2007-06-21 17:02 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-21 7:05 [LARTC] Redundant internet connections Grant Taylor
2007-06-21 7:46 ` Salim S I
2007-06-21 14:46 ` Grant Taylor
2007-06-21 15:35 ` Peter Rabbitson
2007-06-21 15:52 ` Grant Taylor
2007-06-21 16:00 ` Peter Rabbitson
2007-06-21 16:23 ` Grant Taylor
2007-06-21 16:47 ` Peter Rabbitson
2007-06-21 17:02 ` Grant Taylor [this message]
2007-06-21 17:37 ` Peter Rabbitson
2007-06-21 18:27 ` Grant Taylor
2007-06-21 21:01 ` Alex Samad
2007-06-21 21:24 ` Grant Taylor
2007-06-21 22:18 ` Alex Samad
2007-06-21 22:23 ` Grant Taylor
2007-06-21 22:30 ` Alex Samad
2007-06-21 22:35 ` Grant Taylor
2007-06-21 22:39 ` Grant Taylor
2007-06-22 11:54 ` Gustavo Homem
2007-06-22 14:22 ` Grant Taylor
2007-06-22 14:57 ` Gustavo Homem
2007-06-22 15:59 ` Grant Taylor
2007-06-22 18:57 ` Grant Taylor
-- strict thread matches above, loose matches on Subject: below --
2003-10-13 15:45 [LARTC] Redundant Internet connections Seth J. Blank
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=467AAF3A.8090303@riverviewtech.net \
--to=gtaylor@riverviewtech.net \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.