[LARTC] [EMAIL PROTECTED]
Hi all, Im using iptables "SAME" Network Address Translation I just want to know how can I verify and log which private IP is using the Public IP. Can you please guide me on the step by step procedure or direct me to the site? Thanks, Wennie ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] about fw classifier
El Monday 19 June 2006 23:24, Frank Abel Cancio Bello escribió: > Hi all! > > On http://lartc.org/howto/lartc.adv-filter.html I read that a classifiers > available bases the decision on how the firewall has marked the packet and > on http://lartc.org/howto/lartc.qdisc.filters.html the following example: > > "tc filter add dev eth1 protocol ip parent 1:0 prio 1 handle 6 fw flowid > 1:1" "iptables -A PREROUTING -t mangle -i eth0 -j MARK --set-mark 6" > > My question is: > > In the actuality exist a way of build a classifier based on netfilter mark > value associated with a connection instead of netfilter mark value > associated with the packet? yes, iptables CONNMARK associate MARKs wtih conntrack'ed connections. It is in kernel's mainlin since 2.6.12, you can find some introductory infromation[1] over internet or do man iptables for furter information. [1]http://home.regit.org/?page_id=7 -- Luciano ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] about fw classifier
Hi all! On http://lartc.org/howto/lartc.adv-filter.html I read that a classifiers available bases the decision on how the firewall has marked the packet and on http://lartc.org/howto/lartc.qdisc.filters.html the following example: "tc filter add dev eth1 protocol ip parent 1:0 prio 1 handle 6 fw flowid 1:1" "iptables -A PREROUTING -t mangle -i eth0 -j MARK --set-mark 6" My question is: In the actuality exist a way of build a classifier based on netfilter mark value associated with a connection instead of netfilter mark value associated with the packet? Thanks in advance Salute Frank Abel __ XIII Convención Científica de Ingeniería y Arquitectura 28/noviembre al 1/diciembre de 2006 Cujae, Ciudad de la Habana, Cuba http://www.cujae.edu.cu/eventos/convencion ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL
jamal wrote: > You are still speaking ATM (and the above may still be valid), but: > Could you for example look at the netdevice->type and from that figure > out the link layer overhead and compensate for it. > Obviously a lot more useful if such activity is doable in user space > without any knowledge of the kernel? and therefore zero change to the > kernel and everything then becomes forward and backward compatible. It would be nice to have support for HFSC as well, which unfortunately needs to be done in the kernel since it doesn't use rate tables. What about qdiscs like SFQ (which uses the packet size in quantum calculations)? I guess it would make sense to use the wire-length there as well. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL
jamal wrote: > - For further reflection: Have you considered the case where the rate > table has already been considered on some link speed in user space and > then somewhere post-config the physical link speed changes? This would > happen in the case where ethernet AN is involved and the partner makes > some changes (use ethtool). > > I would say the last bullet is a more interesting problem than a corner > case of some link layer technology that has high overhead. > Your work would be more interesting if it was generic for many link > layers instead of just ATM. I've thought about this a couple of times, scaling the virtual clock rate should be enough for "simple" qdiscs like TBF or HTB, which have a linear relation between time and bandwidth. I haven't really thought about the effects on HFSC yet, on a small scale the relation is non-linear. But this is a different problem from trying to accomodate for link-layer overhead. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: [PATCH 2/2] NET: Accurate packet scheduling for ATM/ADSL (userspace)
On Thu, 15 Jun 2006, jamal wrote:
On Thu, 2006-15-06 at 10:47 +1000, Russell Stuart wrote:
On Wed, 2006-06-14 at 11:57 +0100, Alan Cox wrote:
The other problem I see with this code is it is very tightly tied to ATM
cell sizes, not to solving the generic question of packetisation.
Others have made this point also. I can't speak for Jesper,
but I did consider making it generic.
I also have considered to make it generic, but choose to make my patch as
non-intrusive as possible to the kernel (and try to handle as much in
userspace as possible).
Actually I do think that the kernel patch part is very generic.
The patch simply allow us to align the rate table/array.
With the kernel patch in place, we can work on the userspace TC program to
support more and more types of exotic link layer modeling.
The issue was that
doing so would add more code, but I don't personally know
of any real world situation that would use the generic
solution. I didn't fancy the thought of arguing on these
lists for code that no one would actually use.
;-)
If someone could put up their hand and say "Hey, I need
this," then expanding the patch to accommodate them would
be a pleasure. I like generic code too.
It is probably doable by just looking at netdevice->type and figuring
the link layer technology. Totally in user space and building the
compensated for tables there before telling the kernel (advantage is no
kernel changes and therefore it would work with older kernels as well).
I think you have got the setup all wrong.
The linux middlebox/router has two ethernet interfaces, one of the
ethernet interfaces is connected to the ADSL modem. Thus, the linux
ethernet card cannot determine that it is connected to an ADSL line.
The patch is the solution to the classical problem people
have when tryng to configure traffic control on an ADSL link?
Q: The packet scheduling does not work all the time?
A: Try to decrease to bandwidth.
The issue here is, that ATM does not have fixed overhead (due to alignment
and padding). This means that a fixed reduction of the bandwidth is not
the solution. We could reduce the bandwidth to the worst-case overhead,
which is 62%, I do not think that is a good solution...
With the patch, you can now simply configure HTB to use the rate that was
specified by the ISP.
Please read chapter 6 ("Achieving Queue Control") page 55-65, where I
demonstrate that the naive approach of reducing bandwidth does not work,
when the packet distribution change on the link.
http://www.adsl-optimizer.dk/thesis/
Cheers,
Jesper Brouer
--
---
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
---
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Linux QoS to support LLQ and WFQ
I would like to implement an architecture to support LLQ and WFQ with Qos linux elements ! Is possible use CBQ (you can set same parameters to control WRR process) or HTB (how can i controll DRR process) structure ? My idea is to classify packets by List flows, tos flows or connections flows (as CBWFQ on CISCO ) I saw also for WRR patch (http://www.zz9.dk/wrr), but I don't understand well how configure parameters to set bandwidth . I saw also for WFQ patch (http://home.sch.bme.hu/%7Etusi/wfq/) , but is poor of options ! Thanks for any comments and suggestions! Ale ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
