All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.