On Fri, Nov 14, 2003 at 03:28:47PM -0500, Richard A Steenbergen wrote:
>
> You're a little off on the implementation of the layer 3 switches. They do
> not use "flows" persay, but rather their hardware destination lookups are
> not pre-programmed. This means that when you hit a new destination whi
On Thu, Nov 13, 2003 at 08:51:30AM -0500, Haesu wrote:
>
> Yup, and we use it extensively at the border (Netflow) to do accounting and
> traffic statistics as well. But still, Cisco relies on use of CEF to actually
> route, I believe Netflow is used for accounting purposes now (although back
> in
On Thu, Nov 13, 2003 at 01:54:33PM +0100, Anders Lowinger wrote:
> >It only takes x num. of kpps with diverse destinations to knock off a
> >router running flow based caching.
>
> Yep, that is true and its hard to work around.
>
> >Extreme switches use flow based caching (called ipfdb) and any DoS
Andre Oppermann wrote:
Makes sense.
Can we ever have a packet that has a source address with INADDR_BROADCAST
or IN_MULTICAST? I can't think of such a case.
Can we ever have a packet with destination address INADDR_ANY? Maybe
for BOOTP? But then the source address would be 0.0.0.0 too?
IIRC, in
Andre Oppermann wrote:
If we stored special "for us" /32 routes in the routing table for
addresses configured on this host, we could avoid the above 2 loops,
which can quite expensive.
Good idea. I will look at that after 5.2 code freeze.
Question from someone who doesn't really understand the cod
> Everything is not black or white.
>
> A flow cache can accelerate for example Access Control Lists
> and/or firewalling, since only the first packet needs to be
> verified.
That is true , yea. But also note that ACLs in provider environment
are often used during times of diverse DoS attacks whi
Haesu wrote:
I agree in that flow cache is bad and it should not be used.
Everything is not black or white.
A flow cache can accelerate for example Access Control Lists
and/or firewalling, since only the first packet needs to be
verified.
Cisco just added ACL bypass for firewall, which is a simila
Jesper Skriver wrote:
>
> On Thu, Nov 13, 2003 at 12:13:14AM +0100, Andre Oppermann wrote:
> > Jesper Skriver wrote:
> > >
> > > On Sun, Nov 09, 2003 at 05:19:07PM +0100, Andre Oppermann wrote:
> > > > Hello all,
> > > >
> > > > this patch contains three things (to be separated for committing):
>
On Thu, Nov 13, 2003 at 12:13:14AM +0100, Andre Oppermann wrote:
> Jesper Skriver wrote:
> >
> > On Sun, Nov 09, 2003 at 05:19:07PM +0100, Andre Oppermann wrote:
> > > Hello all,
> > >
> > > this patch contains three things (to be separated for committing):
> ...
> > > ip_fastforward
> > >
> > >
Jesper Skriver wrote:
>
> On Sun, Nov 09, 2003 at 05:19:07PM +0100, Andre Oppermann wrote:
> > Hello all,
> >
> > this patch contains three things (to be separated for committing):
...
> > ip_fastforward
> >
> > - removes ip_flow forwarding code
> > - adds full direct process-to-completion IP
On Sun, Nov 09, 2003 at 05:19:07PM +0100, Andre Oppermann wrote:
> Hello all,
>
> this patch contains three things (to be separated for committing):
>
> tcp_hostcache
>
> - removes protocol cloning from routing table (IPv4+6)
> - removes rtentry pointer from inpcb and in6pcb
> - removes i
Hajimu UMEMOTO wrote:
>
> Hi,
>
> > On Wed, 12 Nov 2003 16:22:38 +0100
> > Andre Oppermann <[EMAIL PROTECTED]> said:
>
> oppermann> Ok, I found the bug. It was in the ipv6 hash function where I made
> oppermann> a mistake with the hashmask.
> oppermann> The updated patch is here:
> opper
Hi,
> On Wed, 12 Nov 2003 16:22:38 +0100
> Andre Oppermann <[EMAIL PROTECTED]> said:
oppermann> Ok, I found the bug. It was in the ipv6 hash function where I made
oppermann> a mistake with the hashmask.
oppermann> The updated patch is here:
oppermann> http://www.nrg4u.com/freebsd/tcphost
I agree in that flow cache is bad and it should not be used.
It only takes x num. of kpps with diverse destinations to knock off a router running
flow based caching.
Extreme switches use flow based caching (called ipfdb) and any DoS attack that uses
diverse destinations will kill it pretty quickl
Hajimu UMEMOTO wrote:
>
> Hi,
>
> > On Tue, 11 Nov 2003 19:26:41 +0100
> > Andre Oppermann <[EMAIL PROTECTED]> said:
>
> oppermann> I have fixed the panic. It was a stupid braino in the test whether
> oppermann> we have to free the allocated route. It was trying to free a null
> opperman
popsong old wrote:
>
> --- Andre Oppermann <[EMAIL PROTECTED]> wrote:
> > > BTW, we'll get even better performance if we keep both
> > > interfaces' MAC addresses in cache (and call
> > > ifp->if_start directly). This requires to keep
> > > ethernet header in mbuf untouched and is only relevant
>
popsong old wrote:
Ah, my fault. I didn't read your patch carefully and assumed that ip
fastforward do flow caching as ip_flow does. However, I think ip flow
caching is a good thing and maybe implementing it in ip fastforward is
a good idea.
Caching flows has mixed results, it works for you if
--- Andre Oppermann <[EMAIL PROTECTED]> wrote:
> > BTW, we'll get even better performance if we keep both
> > interfaces' MAC addresses in cache (and call
> > ifp->if_start directly). This requires to keep
> > ethernet header in mbuf untouched and is only relevant
> > in ethernet though. I implemen
Hajimu UMEMOTO wrote:
>
> Hi,
>
> > On Tue, 11 Nov 2003 19:26:41 +0100
> > Andre Oppermann <[EMAIL PROTECTED]> said:
>
> oppermann> I have fixed the panic. It was a stupid braino in the test whether
> oppermann> we have to free the allocated route. It was trying to free a null
> opperman
t; 0043 600
>
> - Original Message -
> From: "Andre Oppermann" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Sunday
Hi,
> On Tue, 11 Nov 2003 19:26:41 +0100
> Andre Oppermann <[EMAIL PROTECTED]> said:
oppermann> I have fixed the panic. It was a stupid braino in the test whether
oppermann> we have to free the allocated route. It was trying to free a null
oppermann> pointer route which obviously doesn't
Hajimu UMEMOTO wrote:
>
> Hi,
>
> > On Sun, 09 Nov 2003 17:19:07 +0100
> > Andre Oppermann <[EMAIL PROTECTED]> said:
>
> oppermann> The patch is here (relative to -CURRENT as of 2003-11-09):
>
> oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031109.patch
>
> It p
Hi,
> On Tue, 11 Nov 2003 18:06:05 +0100
> Andre Oppermann <[EMAIL PROTECTED]> said:
oppermann> However there is a problem in netkey/key.c with the static variable
oppermann> ipsec_esp_auth which is unused if IPSEC_ESP is not defined.
Thanks. I've just committed to define ipsec_esp_auth
Hajimu UMEMOTO wrote:
>
> Hi,
>
> > On Sun, 09 Nov 2003 17:19:07 +0100
> > Andre Oppermann <[EMAIL PROTECTED]> said:
>
> oppermann> The patch is here (relative to -CURRENT as of 2003-11-09):
> oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031109.patch
>
> The pat
Hi,
> On Sun, 09 Nov 2003 17:19:07 +0100
> Andre Oppermann <[EMAIL PROTECTED]> said:
oppermann> The patch is here (relative to -CURRENT as of 2003-11-09):
oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031109.patch
It panics at boot around invoking rtsol(8):
Fata
TECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, November 09, 2003 11:19 AM
Subject: tcp hostcache and ip fastforward for review
> Hello all,
>
> this patch contains three things (to be separated for committing):
>
>
Hi,
> On Sun, 09 Nov 2003 17:19:07 +0100
> Andre Oppermann <[EMAIL PROTECTED]> said:
oppermann> The patch is here (relative to -CURRENT as of 2003-11-09):
oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031109.patch
The patch cannot be compiled:
cc -c -O -pipe -mar
popsong old wrote:
>
> > ip_fastforward
>
> > - removes ip_flow forwarding code
> > - adds full direct process-to-completion IPv4
> forwarding code
> > - handles ip fragmentation incl. hw support
> (ip_flow did not)
> > - supports ipfw and ipfilter (ip_flow did not)
> > - supports divert and
> ip_fastforward
> - removes ip_flow forwarding code
> - adds full direct process-to-completion IPv4
forwarding code
> - handles ip fragmentation incl. hw support
(ip_flow did not)
> - supports ipfw and ipfilter (ip_flow did not)
> - supports divert and ipfw fwd (ip_flow did not)
> - drops a
Leo Bicknell wrote:
>
> In a message written on Mon, Nov 10, 2003 at 01:45:48PM -0600, Mike Silbersack wrote:
> > > At the moment is visible via "sysctl -a net.inet.tcp.hostcache.list".
> > > Syncache ain't visible via netstat either. So far you had to use
> > > route get x.x.x.x to see the rtmetr
In a message written on Mon, Nov 10, 2003 at 01:45:48PM -0600, Mike Silbersack wrote:
> > At the moment is visible via "sysctl -a net.inet.tcp.hostcache.list".
> > Syncache ain't visible via netstat either. So far you had to use
> > route get x.x.x.x to see the rtmetrics for a (host-)route. So I'm
On Mon, 10 Nov 2003, Andre Oppermann wrote:
> > - Ensures that a cached entry isn't added until the 3WHS is completed.
> >
> > This should help make synfloods with random source addresses less
> > damaging.
>
> The cache will only be updated if the tcp connection is being closed.
> All update
Hajimu UMEMOTO wrote:
>
> Hi,
>
> > On Sun, 09 Nov 2003 17:19:07 +0100
> > Andre Oppermann <[EMAIL PROTECTED]> said:
>
> oppermann> Hajimu-san, I'm looking especially for comments on whether my changes
> oppermann> to IPv6 are correct wrt IPv6 concepts. (I hope they are).
>
> I don't se
Hi,
> On Sun, 09 Nov 2003 17:19:07 +0100
> Andre Oppermann <[EMAIL PROTECTED]> said:
oppermann> Hajimu-san, I'm looking especially for comments on whether my changes
oppermann> to IPv6 are correct wrt IPv6 concepts. (I hope they are).
I don't see the patch in detail, yet, it seems your c
On Nov 10, 2003, at 1:39 AM, Andre Oppermann wrote:
Jonathan Mini wrote:
All in all I don't think it is worth adding this complexity.
I agree.
This is actually a small value for TCP connections which are being
used to forward messages, especially on gigabit links.
Heavily-intensive
web applicati
Mike Silbersack wrote:
>
> On Sun, 9 Nov 2003, Andre Oppermann wrote:
>
> > Hello all,
> >
> > this patch contains three things (to be separated for committing):
>
> I don't have much time free in the next week, so I cannot do a complete
> review. However, I just did a quick readthrough.
>
> >
Jonathan Mini wrote:
>
> On Nov 9, 2003, at 2:47 PM, Andre Oppermann wrote:
>
> > Jonathan Mini wrote:
> >>
> >> On Nov 9, 2003, at 8:19 AM, Andre Oppermann wrote:
> >>
> >>> - DoS attack 2: make MSS very low on local side of connection
> >>> and send mny small packet to remote host. Fo
On Sun, 9 Nov 2003, Andre Oppermann wrote:
> Hello all,
>
> this patch contains three things (to be separated for committing):
I don't have much time free in the next week, so I cannot do a complete
review. However, I just did a quick readthrough.
> tcp_hostcache
This looks good to me, I've
On Nov 9, 2003, at 2:47 PM, Andre Oppermann wrote:
Jonathan Mini wrote:
On Nov 9, 2003, at 8:19 AM, Andre Oppermann wrote:
- DoS attack 2: make MSS very low on local side of connection
and send mny small packet to remote host. For every packet
(eg. 2 bytes payload) a sowakeup is don
Jonathan Mini wrote:
>
> On Nov 9, 2003, at 8:19 AM, Andre Oppermann wrote:
>
> > - DoS attack 2: make MSS very low on local side of connection
> > and send mny small packet to remote host. For every packet
> > (eg. 2 bytes payload) a sowakeup is done to the listening
> > proces
On Nov 9, 2003, at 8:19 AM, Andre Oppermann wrote:
- DoS attack 2: make MSS very low on local side of connection
and send mny small packet to remote host. For every packet
(eg. 2 bytes payload) a sowakeup is done to the listening
process. Consumes a lot of CPU there.
This sounds
Hello all,
this patch contains three things (to be separated for committing):
tcp_hostcache
- removes protocol cloning from routing table (IPv4+6)
- removes rtentry pointer from inpcb and in6pcb
- removes ip route cache in ip_input.c (locking much easier)
- removes most (tcp specific) m
42 matches
Mail list logo
