a minor editorial comment:
Jens Ott - PlusServer AG writes:
> Jack Bates schrieb:
>> Paul Vixie wrote:
>>
>> Do you have a miraculous way to stop DDOS? Is there now a way to quickly
>> and efficiently track down forged packets? Is there a remedy to shutting
>> down the *known* botnets, not to m
Florian Weimer wrote:
If you want to run a public exchange point, you need to solve the same
announcement validation problem. Multiple organizations appear to do
it successfully, so it can't be that difficult.
How exactly do you do "validation"? If I give you a list of ASes and
prefixes, wh
On Feb 14, 2009, at 5:43 PM, Florian Weimer wrote:
* Steven M. Bellovin:
As Randy and Valdis have pointed out, if this isn't done very
carefully
it's an open invitation to a new, very effective DoS technique. You
can't do this without authoritative knowledge of exactly who owns any
prefix; y
* Steven M. Bellovin:
> As Randy and Valdis have pointed out, if this isn't done very carefully
> it's an open invitation to a new, very effective DoS technique. You
> can't do this without authoritative knowledge of exactly who owns any
> prefix; you also have to be able to authenticate the requ
> > where you lose me is where "the attacker must always win".
>
> Do you have a miraculous way to stop DDOS? Is there now a way to quickly
> and efficiently track down forged packets? Is there a remedy to shutting
> down the *known* botnets, not to mention the unknown ones?
there are no silver b
If this router is not doing some kind of proxying, tuning tcp related
kernel bits will not impact "long fat pipe" or "long fat network" issues.
The place that needs to be tuned for larger window sizes/scaling is the
web server.
http://www.psc.edu/networking/projects/tcptune/#Linux
or search
Thanks for all the answers. I'm currently going down the path of looking at
IPtables' conntrack slowing the forwarding rate.
If I can't find any more docs then I'll boot the router with a kernel
without any IPtables built-in and see if that's it.
As Lee said "rollback" ! That's the last change to
Thanks for all the answers. I'm currently going down the path of looking at
IPtables' conntrack slowing the forwarding rate.
If I can't find any more docs then I'll boot the router with a kernel
without any IPtables built-in and see if that's it.
As Lee said "rollback" ! That's the last change to
On Sat, 14 Feb 2009, Chris wrote:
The RTTs vary massively because the router is forwarding from websites
on the LAN to visitors worldwide. Is that what you meant ?
And your TCP speed when doing testing is always 300-600 kilobyte/s
regardless of RTT between the boxes with which you're testing?
> I'm looking at TSO too as above, mentioned by Nickola. I'll maybe risk
> changing it with ethtool during a quiet network moment.
Turning off offloading might be something to try indeed.
Regarding the negotation issue, can you look at the other end of the
link and check what it's saying?
Lookin
On Fri, 13 Feb 2009 15:57:32 +0100
Jens Ott - PlusServer AG wrote:
> in the last 24 hours we received two denial of service attacks with
> something like 6-8GBit volume. It did not harm us too much, but e.g.
> one of our upstreams got his Amsix-Port exploded.
[...]
> Therefore I had the following
Could Charlie do long haul microwave to someone who can do BGP?
On 2/14/09, Francois Menard wrote:
> The rule with ARIN is that you only need to demonstrate that you WANT
> do do multihoming, not that you WILL do multihoming.
>
> That question would be better asked on the ARIN policy mailing list
Hi Mikael,
I just realised that I didn't respond to your post.
The RTTs vary massively because the router is forwarding from websites on
the LAN to visitors worldwide. Is that what you meant ?
Disabling TSO didn't work unfortunately.
Thanks again,
Chris
Thanks a lot, Lee.
On 2/14/09, Chris wrote:
> Thanks very much, Lee. My head's whirring. Am I right in thinking by turning
> on scaling (which I just did) then the window size is automatically set ?
No. Scaling just allows you to have a window size larger than 64KB.
These might help
http://www-didc.lbl.gov/TCP-
Thanks very much, Lee. My head's whirring. Am I right in thinking by turning
on scaling (which I just did) then the window size is automatically set ?
I'll do some more reading.
I'm looking at TSO too as above, mentioned by Nickola. I'll maybe risk
changing it with ethtool during a quiet network mo
On 2/14/09, Chris wrote:
> Thanks loads for the quick replies. I'll try and respond individually.
> Lee > I recently disabled tcp_window_scaling and it didn't solve the
> problem. I don't know enough about it. Should I enable it again ? Settings
> differing from defaults are copied in my first pos
The rule with ARIN is that you only need to demonstrate that you WANT
do do multihoming, not that you WILL do multihoming.
That question would be better asked on the ARIN policy mailing list.
I'm also on that list.
That was cleared with ARIN as part of the process to get that /22
I guess
The short story behind this deployment is that Charle's infrastructure
is at the tail end of a submarine cable on an island, where there is
only 1 competitor, but the ILEC, on the island side of the submarine
cable.
The ILEC owns the submarine cable
But the ILEC will not do BGP
The competi
Thanks, Nickola.
What's your opinion on these settings ? Do you recommend switching off "tcp
segmentation offload" ?
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
udp fragmentation offload: off
generic segmentation offload: on
Hello, Chris,
So, as it seems you have problem with TCP, and not UDP, maybe this is
something with regard to TCP segmentation offloading.
It could be a total shot in the dark, but can you see what
ethtool -k says?
Then you can have a look at 'man ethtool' and turn on/off the appropriate
stuff.
Thanks loads for the quick replies. I'll try and respond individually.
Lee > I recently disabled tcp_window_scaling and it didn't solve the
problem. I don't know enough about it. Should I enable it again ? Settings
differing from defaults are copied in my first post.
Mike > Strangely I'm not seein
On Sat, 14 Feb 2009, Lee wrote:
Try enabling window scaling
echo 1 > /proc/sys/net/ipv4/tcp_window_scaling
or, if you really want it disabled, configure a larger minimum window size
net.ipv4.tcp_rmem = 64240 87380 16777216
Without window scaling, you're limited to 64k window size anyway.
Ch
What about embedded systems (I'm thinking PCS, SCADA, ICS, etc.) that run a
micro version of *nix? Wonder how many of them will still be warm but confused
in January of 2038?
Marc
-Original Message-
From: Florian Weimer [mailto:f...@deneb.enyo.de]
Sent: Saturday, February 14, 2009 8:
* Mark Andrews:
> In message ,
> Nathan Malynn writes:
>> Question about 2k38: Aren't most Unixoid systems using 64-bit clocks now?
>
> No. Even if they were you have 32 bit timestamps in lots
> of things that have to be handled even if time/time64 returns
> a 64 bit timestamp.
> I'm losing the will to live with this networking headache ! Please feel free
> to point me at a Linux list if NANOG isn't suitable. I'm at a loss where
> else to ask.
The linux-net might be more appropriate indeed.
> With and without shaping and over different bandwidth providers using the
> e1
Try enabling window scaling
echo 1 > /proc/sys/net/ipv4/tcp_window_scaling
or, if you really want it disabled, configure a larger minimum window size
net.ipv4.tcp_rmem = 64240 87380 16777216
HTH,
Lee
On 2/14/09, Chris wrote:
> Hi All,
>
> I'm losing the will to live with this networking hea
Hi All,
I'm losing the will to live with this networking headache ! Please feel free
to point me at a Linux list if NANOG isn't suitable. I'm at a loss where
else to ask.
I've diagnosed some traffic oddities and after lots of head-scratching,
reading and trial and error I can say with certainty t
If all else fails, you could setup a pair of static IPIP or GRE
tunnels using the static provider-assigned address on your link into
the non-bgp speaking provider. Then, terminate the 'far side' of the
tunnel on a router collocated somewhere upstream of if the brain-dead
provider. This would get yo
In message ,
Nathan Malynn writes:
> Question about 2k38: Aren't most Unixoid systems using 64-bit clocks now?
No. Even if they were you have 32 bit timestamps in lots
of things that have to be handled even if time/time64 returns
a 64 bit timestamp.
> On Fri, Feb 13, 2
30 matches
Mail list logo
