Re: A weird routing question.
- From: none <""testr\"@(none)">
- Date: Fri, 28 Sep 2007 15:38:19 +0200
none wrote:
Hi all,
Generally speaking, in an IP network, any IP packet which reach a node
(workstation, gateway, router...), and whichever the incoming interface,
will either be caught and absorbed by this node if it is the intended
recipient, or redirected for output (IP forwarding) through [another]
interface in respect to the current routing policy.
But I have a weird goal to achieve:
On a linux box 'A' which has interfaces eth0, eth1, eth2, eth3, I would
like to do a special treatment on packets incoming via eth0 and whose
source is <some-network>.
I would like these packets be unconditionaly redirected unmodified for
output via interface eth1.
That is:
- even if they were targeted (destination IP) at my box 'A', they will
be re-emitted through eth1.
- even if they would have been forwarded through eth2 or eth3, they
will be re-emitted through eth1 too.
Any idea to help me reach this goal?
Sincerely,
Le Testeur
Hello all,
I especially thank the four people (until now) who afforded taking time
to answer me. I must say you: even if my goal has puzzled you a bit,
your answers helped me a bit to grasp what the directions I shall
investigate are.
Now, it's my turn to expose why I explained my original goal that way:
I have a box 'A' with interface (ethernet) eth0 and I wanted to do
ingress SHAPING on eth0 : each stream family/network would be allocated
a dedicated bandwidth.
But up to now, Linux has very poor support for ingress SHAPING : it only
allows a 'blind' ingress BANDWIDTH LIMITING.
I heard of the IMQ (InterMediate Queueing device) to get rid of this
ingress technical limitation. But I run a too heavily patched and a too
hard to build Linux kernel to afford entering the process to patch the
kernel and the toolset for IMQ compliance.
So it happened to me that I could make my box 'A' to reflect (like a
mirror) some of the packets incoming on interface eth0 (physical
ethernet) to some Virtual TAP tap2 * and get them back (whichever the
means) on Virtual TAP tap3 * to do Real & Effective egress SHAPING on
Virtual TAP tap2, thus to do Effective ingress SHAPING on eth0 which is
my initial goal.
* The both interfaces being provided by the Linux Universal TUN/TAP driver.
Then I straightly considered using a UML (User Mode Linux) virtual
machine, which has a full network stack, to join the two Virtual TAPs
tap2 & tap3 and make them communicate to create the missing 'tunnel'. In
this scenario, it would not have been to complicated to provide my box
'A' with functional networking & a good 'ingress SHAPING'.
The point where the whole story became funny and a bit weird was when I
decided not to waste system resources to a whole virtual machine (like
UML). Then I bet I could reach the same initial goal with different
technical means. I decided to join my two Virtual TAP interfaces by a
bare tunnel. I failed to use Vtun for this purpose, but I managed to use
OpenVPN which I was already used to.
For this purpose, I thought to allocate my two Virtual TAP interfaces'
IP addresses on the same [virtual] ethernet segment, which I don't know
if it is really usefull.
But now, I'm stuck at two key points:
- 1) Grasp the mechanisms involved in this overall networking scheme,
with all the meaningful details.
- 2) Do the proper routing/forwarding/masquerading on my box, the box 'A'.
Please, say me if I am an awkward/clumsy/stubborn system/network admin.
I would much appreciate if you could make me suggestions on how to
achieve my goal.
I'm hearing for you all.
Thanks,
Le Testeur
.
- References:
- A weird routing question.
- From: none
- A weird routing question.
- Prev by Date: Re: netfilter & SIP
- Next by Date: Re: netfilter & SIP
- Previous by thread: Re: A weird routing question.
- Next by thread: Problems with autofs and .hidden files
- Index(es):
Relevant Pages
|
