From: Warren Flemmer warren@netlab.co.za
To: lartc@vger.kernel.org
Subject: [LARTC] A complicated routing scenario (for me at least)
Date: Sat, 18 Nov 2000 16:28:57 +0000 [thread overview]
Message-ID: <marc-lartc-98373938216952@msgid-missing> (raw)
In-Reply-To: <marc-lartc-98373938216914@msgid-missing>
<PRE>I rely on the routers to detect the downed link. If the route through the
serial is default and down then the second default (matrix 2) is used (this
has been tested on intel routers, and I am yet to see the intel do something
that the cisco can't).
The Single Box: I tried and tried and tried. Eventually I went to two boxes
and the problem as solved.
Reason for 2 boxes.
The crossrouter does source routing based on which source ip is used (If the
ip of the source belongs to isp1 then the data should go out though isp1,
the data could quite easily go through isp2 but would return through isp1,
making it imperitive that both links are up). This makes load balancing
possible (for me at least), my dial-ins are assign alternating ips from the
different isps. Since I rely on the routers to handle the routing for a
downed link, if the data is sent back to the same box, the box has no idea
the link is down and it would send it back to the same downed link, causing
a loop. I initially thought that marking data as it went out would enable
the one box to adjust the routes (route based on fwmark) if the same marked
data was retrieved, but I could not get this to work. The second box
(redundancy) instead gets the data from the router (if link down). It then
MASQ the data on the other isps ip and sends the data out.
My first impression was that 1 one box solution was feasible, but without
some way of knowing the data has been sent back by the router this is not
possible. New features in kernel 2.4 may permit this. If I managed to get
the marking to work (I managed to mark data and send data based on mark but
the returned data from the router was not always marked!), one box might
have been possible.
Even if a one box solution were possible I think I may stay with the two
boxes for now. I intend to upgrade to kernel 2.4 and use SNAT instead of
MASQ. The box I use is old and out of date for any real processing function
but works great for the app. Keeping the boxes separate would make upgrading
easy. The solution is also considerably simpler and easier to test.
-----Original Message-----
From: Mike Fedyk <<A HREF="mailto:mfedyk@matchmail.com">mfedyk@matchmail.com</A>>
To: Warren Flemmer <<A HREF="mailto:warren@netlab.co.za">warren@netlab.co.za</A>>
Cc: <A HREF="mailto:LARTC@mailman.ds9a.nl">LARTC@mailman.ds9a.nl</A> <<A HREF="mailto:LARTC@mailman.ds9a.nl">LARTC@mailman.ds9a.nl</A>>
Date: Friday, November 17, 2000 2:04 PM
Subject: Re: [LARTC] A complicated routing scenario (for me at least)
><i>Warren Flemmer wrote:
</I>>><i>
</I>>><i> Greetings
</I>>><i>
</I>>><i> I am new to iproute2 and therefore would not try to give a direct answer
</I>to
>><i> any of your questions. I have, however, been working on what seems to me
</I>to
>><i> be a similar problem and will offer it here in case it assists.
</I>>><i>
</I>>><i> I two have two links to the internet though different isps. The
</I>requirements
>><i> were that users on the lan would be as oblivious as possible to any one
</I>link
>><i> going down.
</I>>><i>
</I>>><i> The solution I came up with involved two new linux boxes. Both using
</I>iproute
>><i> and one using masq (nat with 2.4 when released). One box was placed
</I>between
>><i> the two isps with source routing and a third network card linking to the
</I>>><i> dns,www etc (I call it a crossrouter). The second box also links the two
</I>>><i> isps and uses source routing and masq to offer redundancy (redundancy
</I>box).
>><i> An attempt at text art may help
</I>>><i>
</I>>><i> isp1 +redundancy box+ isp2
</I>>><i> | | |
</I>>><i> |
</I>>><i> +---------------------+ +---------------------+
</I>>><i> | |
</I>>><i> + Crossrouter +
</I>>><i> |
</I>>><i> ---+---------+---------------+----------------------------------Lan
</I>>><i> www dns etc
</I>>><i>
</I>>><i> I made may attempts to use one box instead of two without any luck. I had
</I>>><i> bad results with marking that would have made a single box solution
</I>>><i> possible. The result was the two boxes. On the routers to the isp I have
</I>a
>><i> second default route to the redundancy box with a higher matrix. If one
</I>link
>><i> fails the data is routed to the redundancy box where it is masq on an ip
</I>>><i> (one assigned by the isp with the good link) address and sent out through
</I>>><i> the other isp. Every test I have done is showing the solution to work but
</I>it
>><i> has not been fully deployed yet.
</I>>><i>
</I>>><i> I would imagine that this type of solution would be worth using is you
</I>link
>><i> to two different isps and BGP is not available. I intend doubling up on
</I>the
>><i> crossrouter as it will become a single point of failure.
</I>>><i>
</I>>><i> If anyone knows of a better solution I would be interested to know.
</I>>><i>
</I>>><i> Hope this helps
</I>>><i>
</I>>><i> Regards
</I>>><i> Warren
</I>>><i>
</I>>><i> _______________________________________________
</I>>><i> LARTC mailing list / <A HREF="mailto:LARTC@mailman.ds9a.nl">LARTC@mailman.ds9a.nl</A>
</I>>><i> <A HREF="http://mailman.ds9a.nl/mailman/listinfo/lartc">http://mailman.ds9a.nl/mailman/listinfo/lartc</A> HOWTO:
</I><A HREF="http://ds9a.nl/2.4Routing/">http://ds9a.nl/2.4Routing/</A>
><i>
</I>><i>I think in this case, you may be able to do what you want with a single
</I>box,
><i>unless you need to route based on fwmark or something set in ipchains.
</I>><i>
</I>><i>If all you need to base the information on is source address, or something
</I>><i>already in the packet, a single box solution should be feasible.
</I>><i>
</I>><i>Can you elaborate on your current setup? How/what detects that the ISP has
</I>gone
><i>down? What switches you to forward to the other router? Are you running
</I>any
><i>routing/status_monitoring daemons?
</I>><i>
</I>><i>So far, the only way I've been able to detect that the ISP is down is a
</I>ping.
</PRE>
prev parent reply other threads:[~2000-11-18 16:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-13 22:58 [LARTC] A complicated routing scenario (for me at least) Andrew
2000-11-14 14:34 ` Arthur
2000-11-14 14:44 ` Wingtung.Leung
2000-11-14 20:15 ` Andrew
2000-11-14 21:47 ` Whit
2000-11-14 23:10 ` Wingtung.Leung
2000-11-15 10:49 ` Arthur
2000-11-15 11:27 ` Arthur
2000-11-15 14:57 ` Warren
2000-11-15 19:20 ` Andrew
2000-11-15 19:30 ` Arthur
2000-11-15 20:11 ` Andrew
2000-11-17 1:07 ` Andrew
2000-11-17 12:11 ` Mike
2000-11-17 12:24 ` Mike
2000-11-17 13:00 ` Arthur
2000-11-17 21:25 ` Mike
2000-11-18 16:28 ` Warren [this message]
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=marc-lartc-98373938216952@msgid-missing \
--to=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.