I am looking for some help,I basically want
to forward/route traffic via sandy (see attatchment)between two
lan's.
Thank you in advance for your
assistance.
fullnetwork.gif
Description: GIF image
___
LARTC mailing list
LARTC@mailman.ds9a.nl
I am looking for some help, I basically want to forward/route
traffic via
sandy (see attatchment) between two lan's.
This looks like a question from a networking course exam ;-)
A you sure this is a real-life situation?
Anyway, this seems to be a very simple layout that you don't need
Andreas,if I want that A,B,C can borrow bandwidth from each other? How i can the structure of HTB tree?Stefano2006/5/28, Andreas Klauer
[EMAIL PROTECTED]:On Sun, May 28, 2006 at 02:04:57AM +0200, Stefano Mainardi wrote:
Like I said above, in the case that B is not producing traffic, 7/8 of the
Hi,
I have a linux box which balances load between two interfaces ( say WAN1
and WAN2). I have masquerading on for any request coming from LAN to the
outside world.
The setup is in such a way that WAN1 drops packets with source ip
belonging to WAN2's network and viceversa.
For some strange
On Tue, 2006-05-30 at 20:02 +0530, Vinod Chandran wrote:
It seems to me that the root of the problem is the creation of the two
cache entries. Any idea why this happens, and how it can be avoided.
What does ip route get say? I think this tool will be the key to the
solution, look at the src
Hi Erik,
Ip route get returns
192.168.26.73 via 192.168.19.76 dev eth1 src 192.168.19.29
cache mtu 1500 advmss 1460
Here too it gives me WAN1s IP address which is the same as the
masqueraded one, but the packets are seen going out through WAN2.
Thanks and Regards,
Vinod C
Erik Slagter
On Tuesday 30 May 2006 11:32, Vinod Chandran wrote:
Hi,
I have a linux box which balances load between two interfaces ( say WAN1
and WAN2). I have masquerading on for any request coming from LAN to the
outside world.
If WAN ips are static, you can use
iptables -t nat ... -o WAN1 -j SNAT
AFAICR using MASQUERADE with multipath is not recommended (but maybe this
is outdated, plz correct me if I'm wrong)
I have had problems using MASQUERADE with multipath on a 2.4.31 kernel box,
with two outbound default routes I got messages about rustys brain broke
and things like ICMP etc
My apologies for sending email disclaimer crap to the list, I forgot the
magic string to prevent it from being appended :(.
Oops.
Andy
JOSEDV001TAG
-Original Message-
From: Andrew Lyon [mailto:[EMAIL PROTECTED]
Sent: 30 May 2006 17:13
To: 'lartc@mailman.ds9a.nl'
Subject: RE: [LARTC]
Luciano Ruete wrote:
snip
Besides that, you need to solve the problems that multipath will arise, like
TOS situation described above or route cache expiration, that could made
long
term conns to be routed over a new iface. The solutions i know are
CONNMARK(kernel=2.6.12) and julian's
On Tuesday 30 May 2006 13:23, Jason Boxman wrote:
Luciano Ruete wrote:
snip
Besides that, you need to solve the problems that multipath will arise,
like TOS situation described above or route cache expiration, that could
made long
term conns to be routed over a new iface. The solutions
Ok, I ran into a different issue with using the tc filters which
basically puts me right back to using the iptables classify target --
which means that I am running right back into the same problem I was on
before.
As a refresher, the problem is that the classify target, while matching
in the
Eliot, Wireless and Server Administrator, Great Lakes Internet wrote:
Ok, I ran into a different issue with using the tc filters which
basically puts me right back to using the iptables classify target --
which means that I am running right back into the same problem I was on
before.
snip
On Tuesday 30 May 2006 16:25, Eliot, Wireless and Server Administrator, Great
Lakes Internet wrote:
[snip]
You'll notice that the iptables rules show matches for class 5:510,
5:511, and others; yet, the only class taking traffic here is 5:2.
just to exaust possibilities...
i think that 5:2
Ok, I tried this:
tc qdisc add dev wivl4 parent 5:510 handle 475:0 sfq
tc qdisc add dev wivl4 parent 5:511 handle 476:0 sfq
tc qdisc add dev wivl4 parent 5:512 handle 477:0 sfq
iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 510 -j
CLASSIFY --set-class 475:0
iptables -A POSTROUTING -t
From iptables libipt_classify.c:
static void
print_class(unsigned int priority, int numeric)
{
printf(%x:%x , TC_H_MAJ(priority)16, TC_H_MIN(priority));
}
/* Prints out the targinfo. */
static void
print(const struct ipt_ip *ip,
const struct ipt_entry_target *target,
int
Chain POSTROUTING (policy ACCEPT 222K packets, 157M bytes)
pkts bytes target prot opt in out source
destination
6401 3653K CLASSIFY all -- * wivl4 0.0.0.0/0
0.0.0.0/0 MARK match 0x1fe CLASSIFY set 1db:0
It matches like normal, but this time is pointing to a hex
Jason == Jason Boxman [EMAIL PROTECTED] writes:
Jason Luciano Ruete wrote: snip
Besides that, you need to solve the problems that multipath
will arise, like TOS situation described above or route cache
expiration, that could made long term conns to be routed over a
new
18 matches
Mail list logo