Dear colleagues,
This is a resend of APNIC message issued Feb this year, many of you
have not removed the filters creating problems for many networks in
Australia and other APNIC covered countries, as the below mentioned
'near future' has been well underway for some couple of months.
It would
Could IPtables control traffic with inspecting layer7
information?
As someone suggested, bandwidth allocation could be
done with TCP protocol control ( ACK dropping or so);
How can we do that? NBAR only limit the bandwidth, and
to our experience with cisco7609 it cost a lot of cpu
time!
On Wed, 7 Dec 2005, Joe Shen wrote:
Could IPtables control traffic with inspecting layer7
information?
Not layer 7. IPtables works on L3 L4 (and another similar system
for linux called ebtables provides filtering at L2) but it can
be used for setting up qos depending on where from (and
There are quite a few modules for iptables that will reach
up to Layer 7, including several specifically for file
sharing applications...
And one really nifty one that makes non-passive ftp work
through NAT.
-e
-Original Message-
From: william(at)elan.net [mailto:[EMAIL PROTECTED]
On Mon, 5 Dec 2005, Douglas Otis wrote:
A less than elegant solution as an alternative to deleting the message, is
to hold the data phase pending the scan.
Contrary to your vision of this option, it is not only elegant; it happens
to be the *correct* thing to do.
Dropping the message on the
On Tue, 6 Dec 2005, Ejay Hire wrote:
There are quite a few modules for iptables that will reach
up to Layer 7, including several specifically for file
sharing applications...
And one really nifty one that makes non-passive ftp work
through NAT.
These are action modules - they receive the
Somebody else emailed me privately link for L7 filtering with linux
(its all experimental and requires custom linux patches for now):
http://l7-filter.sourceforge.net/L7-HOWTO-Netfilter
Also in previous post it was supposed to be:
For ebtables it is http://ebtables.sourceforge.net (this is
On Dec 6, 2005, at 8:19 AM, Todd Vierling wrote:
On Mon, 5 Dec 2005, Douglas Otis wrote:
A less than elegant solution as an alternative to deleting the
message, is
to hold the data phase pending the scan.
Contrary to your vision of this option, it is not only elegant; it
happens
to
On Tue, 6 Dec 2005, Douglas Otis wrote:
A less than elegant solution as an alternative to deleting the message, is
to hold the data phase pending the scan.
Contrary to your vision of this option, it is not only elegant; it happens
to be the *correct* thing to do.
Holding at the
Stephen Stuart wrote:
I am a little confused here. You yourself say that a valid metric
starts from 1, then how come 0 be valid for a directly connected
route. Are you saying that seeing a RIP metric of 0 on the wire is
valid?
A metric of 0 from a host would mean that the host itself is the
On Dec 6, 2005, at 2:15 PM, Todd Vierling wrote:
On Tue, 6 Dec 2005, Douglas Otis wrote:
Holding at the data phase does usually avoid the need for a DSN,
but this
technique may require some added (less than elegant) operations
depending upon
where the scan engine exists within the
Am all the more confused now :)
In pre-RFC1058 implementations the sender increments the metric, so a
directly-connected route's metric is 1 on the wire.
In post-RFC1058 implementations the receiver increments the metric, so
a directly-connected route's metric is 0 on the wire.
12 matches
Mail list logo
