[LARTC] need help cbq

2006-03-06 Thread timi koli 
i start reading for cbq init script but i haven't it on my linux machine and the tutorials that a read don't show how to install cbq on linux. sorry for my incopetence but i am in trouble now. any help will be apreciated very much thanks a lot

___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Dual ISP routing and NAT problem

2006-03-06 Thread Mart Frauenlob 

Hello,

nobody even commented this post?
What's wrong about it?

Thank you

Mart

Mart Frauenlob wrote:

Hello newsgroup,

I hope somebody with more routing experience then me can help me with 
the problem I have.


The setup is as described below. A dual internet provider routing, 
multiple local area networks, and a dmz network with one public and one 
private ip range.

I followed the instructions at lartc.org, and so far everything is working.
The default route is via 'PROV_STATIC', only packets comming from LAN 
192.168.111.0/24 are routed via 'PROV_DSL'.
Now if I want to do network address translation via iptables for certain 
traffic coming into the dsl interface ppp0,

packets never reach their destination.
DNAT into DMZ or any of the LANs over the eth0 interface works as expected.
So for example applying a DNAT rule like:
'iptables -t nat -A PREROUTING -i ppp0 -d 217.92.8.242 -p tcp --dport 80 
-j DNAT --to-destination 62.155.170.254'

fails.

Same for NAT attempts into the LANs 192.168.112.0/24 and 192.168.113.0/24.
While DNAT into LAN 192.168.111.0/24 works perfectly.

So I think the problem is that traffic from the DMZ and those two LANs 
have the ip rules applied to end up in the the table 'PROV_STATIC'.
Which usually is what I want, but not in this case, where I want port or 
protocol specific traffic to be routed differntly.
Is there a way to 'override' the default routing behaviour for i.e. http 
traffic?
I tried the iptables ROUTE target, but did not get it working, but could 
of course be my error.

Is there anything wrong with my current routing tables?

Thank you for any help you can give.

Best regards,

Mart

-
Setup:

Firewall / Router:
 2 external interfaces
 3 lan interfaces
 1 dmz interface

External interfaces:
1 - PROV_STATIC:
IP: 62.155.170.250
Network: 62.155.170.248/30
Interface: static interface eth0
global default route via: 62.155.170.249
2 - PROV_DSL:
IP: 217.92.8.242
Peer: 217.6.98.186
Interface: DSL interface ppp0 (pppoe over eth1)

DMZ interface:
IP_1: 62.155.170.253
Network_1: 62.155.170.252/30
IP_2: 192.168.0.1
Network_2: 192.168.0.0/24
Interface: eth4

LAN interfaces:
1: IP: 192.168.111.1
   Network: 192.168.111.0/24
   Interface: eth5
2: IP: 192.168.112.1
   Network: 192.168.112.0/24
   Interface: eth2
3: IP: 192.168.113.1
   Network: 192.168.113.0/24
   Interface: eth3

igor:/# ip route list table PROV_DSL
217.6.98.186 dev ppp0  proto kernel  scope link  src 217.92.8.242
62.155.170.248/30 dev eth0  scope link  src 62.155.170.250
62.155.170.252/30 dev eth4  proto kernel  scope link  src 62.155.170.253
192.168.112.0/24 dev eth2  proto kernel  scope link  src 192.168.112.1
192.168.113.0/24 dev eth3  proto kernel  scope link  src 192.168.113.1
192.168.0.0/24 dev eth4  proto kernel  scope link  src 192.168.0.1
192.168.111.0/24 dev eth5  proto kernel  scope link  src 192.168.111.1
10.0.0.0/8 via 192.168.111.3 dev eth5  proto kernel  src 192.168.111.1
127.0.0.0/8 dev lo  scope link
default via 217.6.98.186 dev ppp0


igor:/# ip route list table PROV_STATIC
217.6.98.186 dev ppp0  proto kernel  scope link  src 217.92.8.242
62.155.170.248/30 dev eth0  scope link  src 62.155.170.250
62.155.170.252/30 dev eth4  proto kernel  scope link  src 62.155.170.253
192.168.112.0/24 dev eth2  proto kernel  scope link  src 192.168.112.1
192.168.113.0/24 dev eth3  proto kernel  scope link  src 192.168.113.1
192.168.0.0/24 dev eth4  proto kernel  scope link  src 192.168.0.1
192.168.111.0/24 dev eth5  proto kernel  scope link  src 192.168.111.1
10.0.0.0/8 via 192.168.111.3 dev eth5  proto kernel  src 192.168.111.1
127.0.0.0/8 dev lo  scope link
default via 62.155.170.249 dev eth0


igor:/# ip route list
217.6.98.186 dev ppp0  proto kernel  scope link  src 217.92.8.242
62.155.170.248/30 dev eth0  proto kernel  scope link  src 62.155.170.250
62.155.170.252/30 dev eth4  proto kernel  scope link  src 62.155.170.253
192.168.112.0/24 dev eth2  proto kernel  scope link  src 192.168.112.1
192.168.113.0/24 dev eth3  proto kernel  scope link  src 192.168.113.1
192.168.0.0/24 dev eth4  proto kernel  scope link  src 192.168.0.1
192.168.111.0/24 dev eth5  proto kernel  scope link  src 192.168.111.1
10.0.0.0/8 via 192.168.111.3 dev eth5  proto kernel
default via 62.155.170.249 dev eth0


igor:/# ip rule list
0:  from all lookup local
32759:  from 192.168.0.0/24 lookup PROV_STATIC
32760:  from 62.155.170.252/30 lookup PROV_STATIC
32761:  from 192.168.113.0/24 lookup PROV_STATIC
32762:  from 192.168.112.0/24 lookup PROV_STATIC
32763:  from 192.168.111.0/24 lookup PROV_DSL
32764:  from 217.92.8.242 lookup PROV_DSL
32765:  from 62.155.170.250 lookup PROV_STATIC
32766:  from all lookup main
32767:  from all lookup default
-
___
LARTC mailing list

Re: [LARTC] Patch to allow for the ATM cell tax

2006-03-06 Thread Jesper Dangaard Brouer 



On Fri, 3 Mar 2006, Russell Stuart wrote:


On Thu, 2006-03-02 at 14:23 -0800, Stephen Hemminger wrote:

I will put it in iproute2 commands when a definitive set of patches
is sent to me. So far, it still looks like it needs some fine tuning.


Yes, they need some fine tuning.  My ultimate goal here is
to get something into the main line that makes tc/htb work
well for VOIP.  I don't care whether it is my patch, or
something else.

Jesper's patch is more mature, and as such is probably the
better starting point.  The only problem with using them
is this statement on his web site:

 Commercial use of my work including the ADSL-optimizer
 is not allowed without my knowledge and consent. The
 ADSL-optimizer will be released under the GNU public
 license.

 ...

4.  Jesper clarifying the license on his patch.


I'll simply drop this license restriction.
Now it is release 100% under GPL.

I just held a technical talk about the ADSL-optimizer (4/3-2006) at 
linuxforum.dk.  Where I promised the audience that I would try to get the 
patches to the kernel and TC into the main line.  It seem work on this 
front is already in progress, Cool! :-)


Hilsen
  Jesper Brouer

--
---
Master of Computer Science
Cand. scient datalog
Dept. of Computer Science, University of Copenhagen
---
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Balancing multiple connections and NAT

2006-03-06 Thread Jody Shumaker 
On 3/5/06, Andreas Hasenack [EMAIL PROTECTED] wrote:
 Em Qui 23 Fev 2006 20:41, Markus Schulz escreveu:
  you need a patch for NAT processing with multiple gateways. this will
  then save the routing information for each connection inside NAT
  structures, so that each packet of an established connection will be
  get routed over the same gateway. you can find the patches here:
  http://www.ssi.bg/~ja/#routes
  please read the guides (nano howto or dgd-usage) carefully.

 Any idea why these patches are not yet integrated into the upstream kernel?


Possibly disagreement on the features included, or any number of other
reasons.  Personally I had serious problems with the patches in that
they didn't fully function.  Multi-path routing was only choosing one
path, and if too many routes were requested a kernel panic would
occur.

- Jody
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[LARTC] complex; ifb, masq et omnia

2006-03-06 Thread Krzysztof Matusik 
Hi all.

I'm using Jamal's ifb virtual interface from new kernel. Redirecting incoming 
traffic from external interface like that:
# tc [blahbla] match u32 0 0 flowid 1:0 action mirred egress redirect dev ifb0
to ifb to shape it.

The problem is that I'm using MASQUERADE by netfilter also. That redirected 
traffic coming from internet gets to ifb _before_ DNAT is done. So I cannot 
filter or mark it in other way by ip dst address to differ between forwarded 
and incoming traffic to my node.

Goal is to find a solution how to let tc filter find the difference between 
forwarded and incoming traffic in that redirected traffic coming to ifb 
device so shaping/queueing could be done elegantly :-)
(well, infact this traffic goes off ifb device and then gets routed and masqed 
etc- by egress queue)

Anybody got any nice ideas?

Krzysztof
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc