Linux Advanced Routing and Traffic Control list
 help / color / mirror / Atom feed
From: Daniel Egger <egger@spotnic.de>
To: lartc@vger.kernel.org
Subject: RE: [LARTC] QoS (HTB) without IP address
Date: Tue, 31 Dec 2002 11:29:30 +0000	[thread overview]
Message-ID: <marc-lartc-104133426630090@msgid-missing> (raw)
In-Reply-To: <marc-lartc-104127774129042@msgid-missing>

Am Die, 2002-12-31 um 00.14 schrieb Martin A. Brown:

> Setting the problem of the tiny network aside, I'm interested in your
> suggestion, Daniel, that he use the same IP on both interfaces of the
> box--I've not tried that before.

The ip (and thus the size of the network) is irrelevant; actually it
shouldn't even matter if one has the same IP on all or interfaces IIRC.

My vision on the solution is unfortunately not really clear as we're
doing a lot more perverted things as part of a bussiness solution
which could simplify the simple setup a lot (upside down, eh? :) ) 

> Do you have an example config?

What I've been doing at some point was to simply route traffic from
one interface to another and vice versa using the incomming interface
as selector for the iptable rules.

Another (and probably more flexible aproach) would be to mark incomming
from one interface with some mark, handle as if it was "normal" traffic
inside the packet filters and then route the other interface based on
the firewall mark.

> Have you seen any problems with this configuration?

Yes, the first approach (we had taken originally) had the problem that
it was quite hard to intercept packets and handle them differently
like push them through an transparent proxy. Also (and this is nasty for
us) it's almost impossible to run services on the "bridge" and correctly
let them answer back to the client.

We're doing it sort of differently now: We still have the same IP
on both interfaces and the machine is almost transparent, but we
only have one default route pointing to the net and several host routes
into the client net which are set up on demand. That way we have
a mixture of a router and a bridge but can still provide services on
the machine. We also have lots of special services on the machine 
automatically creating routes on demand and doing arp faking so
it might not work that well without...

-- 
Daniel Egger <egger@spotnic.de>

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

      parent reply	other threads:[~2002-12-31 11:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-30 19:45 [LARTC] QoS (HTB) without IP address Martin A. Brown
2002-12-30 19:54 ` Gilles Douillet
2002-12-30 20:36 ` Gilles Douillet
2002-12-30 21:48 ` Stef Coene
2002-12-30 23:03 ` Daniel Egger
2002-12-30 23:14 ` Martin A. Brown
2002-12-30 23:23 ` Stef Coene
2002-12-31  4:57 ` S Mohan
2002-12-31  4:59 ` S Mohan
2002-12-31 11:29 ` Daniel Egger [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-104133426630090@msgid-missing \
    --to=egger@spotnic.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox