think of another creative way to do this? Is one option moving
these servers into a separate VLAN, then rate-limiting from there?
Rob
port / access. Aside from hard setting the l2 interface to
10mbit, can anyone think of another creative way to do this? Is one
option moving these servers into a separate VLAN, then rate-limiting
from there?
Is rate limiting by source IP address an acceptable to you? If so,
then you could do
I'm really interested in rate limiting outbound... with many unknown
dest IP's.
Rob
John Kristoff wrote:
On Thu, 30 Mar 2006 15:56:02 -0800
Robert Sherrard [EMAIL PROTECTED] wrote:
I've got a situation in which I'd like to rate limit a few servers
that hang off of my 6590's
On Thu, 30 Mar 2006 17:25:38 -0800
Robert Sherrard [EMAIL PROTECTED] wrote:
I'm really interested in rate limiting outbound... with many unknown
dest IP's.
That's what that example was intending to show. That is, rate limiting
traffic coming from the servers into the VLAN interface towards
Your first example makes sense... I think I'll give that a shot.
Rob
John Kristoff wrote:
On Thu, 30 Mar 2006 17:25:38 -0800
Robert Sherrard [EMAIL PROTECTED] wrote:
I'm really interested in rate limiting outbound... with many unknown
dest IP's.
That's what
Does anyone have any recommendations concerning hardware rate limiting
solutions with extensive API's? I remember packeteer from back in the
day and have been looking at some of their newer solutions that have XML
API's. Comments? Alternatives?
I would appreciate any feedback that can
of it).
It seems to be decent at what it does, but doesn't have as rich a
featureset as the Packeteer.
John
On Tue, Sep 13, 2005 at 04:32:25PM -0700, Micah McNelly wrote:
Does anyone have any recommendations concerning hardware rate limiting
solutions with extensive API's? I remember packeteer from back
We currently have three BGP and MBGP peering sessions, one of which is
an Internet2 peer. Our primary peering session (peer A) is a 100 Mbps
connection. Our secondary connection (peer B) also is a 100 Mbps
connection rate-limited to 19 Mbps (for financial reason). The
Internet 2 connection
in the near future).
I expect your answer will be in removing any rate limiting
configuration, and setting up some local-prefs on AS's to balance
traffic. Then your expensive 2nd link will take load (and incur
cost) upon failure of link 1.
We currently have local prefs in place. They work fine, but we
Completely possible.
- ferg
-- Sam Stickland [EMAIL PROTECTED] wrote:
Could it be that buffers and flow-control over the 14ms third party leg
are causing the rate-limiting leaky bucket to continue to overflow long
after it's full?
Sam
--
Fergie, a.k.a. Paul Ferguson
Engineering
--On 13 December 2004 13:18 + Sam Stickland [EMAIL PROTECTED]
wrote:
doesn't lock out traffic for such long periods of time.
Could it be that buffers and flow-control over the 14ms third party leg
are causing the rate-limiting leaky bucket to continue to overflow long
after it's full
On Mon, 13 Dec 2004, Alex Bligh wrote:
--On 13 December 2004 13:18 + Sam Stickland [EMAIL PROTECTED]
wrote:
doesn't lock out traffic for such long periods of time.
Could it be that buffers and flow-control over the 14ms third party leg
are causing the rate-limiting leaky bucket to continue
' end of the line, but nothing is done at the 'remote' end.
The remote end is some 14ms away across a third party MPLS network.
Obviously we need to shape at the remote end, but the current behaviour
intrigues me. Rate-limiting, while bad compared to shaping, in my
experience doesn't lock out
On Fri, 29 Aug 2003, Sean Donelan wrote:
On Fri, 29 Aug 2003, Christopher L. Morrow wrote:
That was a ccourt order, not much any US based corporation can do about
that, eh? Oh, yeah, and it didn't help stop any child pornographers, all
it did was hide their tracks from the authorities
Temkin, David wrote:
We've noticed that one of our upstreams (Global Crossing) has introduced
ICMP rate limiting 4/5 days ago. This means that any traceroutes/pings
through them look awful (up to 60% apparent packet loss). After
contacting their NOC, they said that the directive to install
Once upon a time, Jack Bates [EMAIL PROTECTED] said:
Are people idiots or do they just not possess equipment capable of
trashing 92 byte icmp traffic and letting the small amount of normal
traffic through unhindered?
Well, when we used the policy routing example from the Cisco advisory to
Once upon a time, Jack Bates [EMAIL PROTECTED] said:
Are people idiots or do they just not possess equipment capable of
trashing 92 byte icmp traffic and letting the small amount of normal
traffic through unhindered?
Well, when we used the policy routing example from the Cisco
On Thu, 28 Aug 2003, Christopher L. Morrow wrote:
perhaps a change in vendors is in order? I can't see why people would lie
about this, or why they'd listen to the 'request' from DHS in the first
place ;( Oh well.
http://www.wired.com/news/technology/0,1282,57804,00.html
Mike Fisher,
On Thu, 28 Aug 2003, Sean Donelan wrote:
On Thu, 28 Aug 2003, Christopher L. Morrow wrote:
perhaps a change in vendors is in order? I can't see why people would lie
about this, or why they'd listen to the 'request' from DHS in the first
place ;( Oh well.
Vadim Antonov wrote:
It should be pointed put that the ISPs have their share of blame for the
quick-spreading worms, beause they neglected very simple precautions --
such as giving cutomers pre-configured routers or DSL/cable modems with
firewalls disabled by default (instead of the standard
complaints from some of our customers and
forcing us to make routing adjustments as the customers notice
MFN/AboveNet has broken our connectivity to these destinations.
We've noticed that one of our upstreams (Global Crossing) has introduced
ICMP rate limiting 4/5 days ago. This means that any
Crossing) has introduced
ICMP rate limiting 4/5 days ago. This means that any traceroutes/pings
through them look awful (up to 60% apparent packet loss). After
contacting their NOC, they said that the directive to install the ICMP
rate limiting was from the Homeland Security folks
Not that Yipes is necessarily a transit provider by any means, but they have
done the same thing within the cores of their network. I was
troubleshooting an issue yesterday that was pointing to them for 15-20%
packet loss, and I called them and they stated that they started rate
limiting ICMP
and
forcing us to make routing adjustments as the customers notice
MFN/AboveNet has broken our connectivity to these destinations.
We've noticed that one of our upstreams (Global Crossing) has introduced
ICMP rate limiting 4/5 days ago. This means that any traceroutes/pings
through them look
Of the DDOS attacks I have had to deal with in the past year I have seen
none which were icmp based.
As attacks evolve and transform are we really to believe that rate limiting
icmp will have some value in the attacks of tomorrow?
-Gordon
On Wed, 27 Aug 2003, [EMAIL PROTECTED] wrote:
We
is from Jan 2002, if these were a problem then and still are now,
perhaps people should either 1) accept that this is part of normal
internet operations, or 2) decide that this is enough and it's time
to seriously do something about these things.
While rate limiting ICMP can be a good thing, it has
At 09:26 AM 8/28/2003, you wrote:
It takes some education to the customers, but after they understand why,
most are receptive.
Especially when they get DOS'ed.
We have been rate limiting ICMP for a long time, however, it is only
recently that the percentage limit has been reached and people have
On Thu, 28 Aug 2003, Gordon wrote:
Of the DDOS attacks I have had to deal with in the past year I have seen
none which were icmp based.
As attacks evolve and transform are we really to believe that rate limiting
icmp will have some value in the attacks of tomorrow?
The folks doing
sent
to them) which is causing complaints from some of our customers and
forcing us to make routing adjustments as the customers notice
MFN/AboveNet has broken our connectivity to these destinations.
We've noticed that one of our upstreams (Global Crossing) has introduced
ICMP rate limiting
On Thu, 28 Aug 2003, Christopher L. Morrow wrote:
Rate-limiting ICMP is 'ok' if you, as the provider, think its worthwhile
and you, as the provider, want to deal with the headache phone calls...
Would it be fair to say that UUNET haven't been asked by Homeland Security
to do the rate limiting
On Thu, 28 Aug 2003, Wayne E. Bouchard wrote:
While rate limiting ICMP can be a good thing, it has to be done
carefully and probably can't be uniform across the backbone. (think of
a common site that gets pinged whenever someone wants to test to see
if their connection went down or if it's
On Thu, 28 Aug 2003, Steve Carter wrote:
The rate-limiters have become more interesting recently, meaning they've
actually started dropping packets (quite a lot in some cases) because of
the widespread exploitation of unpatched windows machines.
Yep, the amount of ICMP traffic seems to be
and the community by rate limiting because the exploited are
not.
I agree with Wayne that we need to be smart (reads: very specific) about
how we rate limit during this event. When the event is over we can go
back to just a simple rate limit that protects us in a very general way
until the next event
On Thu, 28 Aug 2003, [EMAIL PROTECTED] wrote:
On Thu, 28 Aug 2003, Christopher L. Morrow wrote:
Rate-limiting ICMP is 'ok' if you, as the provider, think its worthwhile
and you, as the provider, want to deal with the headache phone calls...
Would it be fair to say that UUNET haven't
On Thu, 2003-08-28 at 17:37, Steve Carter wrote:
I speak for Global Crossing when I say that ICMP rate limiting has existed
on the Global Crossing network, inbound from peers, for a long time ... we
learned our lesson from the Yahoo DDoS attack (when they were one of our
customers) back
On Thu, Aug 28, 2003 at 03:55:26PM +, Christopher L. Morrow wrote:
On Thu, 28 Aug 2003, Wayne E. Bouchard wrote:
While rate limiting ICMP can be a good thing, it has to be done
carefully and probably can't be uniform across the backbone. (think of
a common site that gets pinged
At 12:39 PM 8/28/2003, you wrote:
Along these lines, how does this limiting affect akamai or other 'ping for
distance' type localization services? I'd think their data would get
somewhat skewed, right?
Perhaps they'll come up with a more advanced system of
monitoring?
probally
Along these lines, how does this limiting affect akamai or other 'ping
for distance' type localization services? I'd think their data would
get somewhat skewed, right?
using icmp to predict tcp performance has always been a silly idea; it
doesn't take any icmp rate limit policy changes to
On Thu, 28 Aug 2003, Christopher L. Morrow wrote:
Rate-limiting ICMP is 'ok' if you, as the provider, think its worthwhile
and you, as the provider, want to deal with the headache phone calls...
Would it be fair to say that UUNET haven't been asked by Homeland Security
to do the rate
anyone else been asked to rate limit by the U.S. Department of Homeland
Security?
Just about everyone with a large enough US office was asked by DHS, in a
public statement...
Isnt there a difference between we have been asked and we have been
ordered to?
Alex
As attacks evolve and transform are we really to believe that rate
limiting icmp will have some value in the attacks of tomorrow?
no. nor those of today. the only way we're going to flatten the increase
of attack volume, or even turn it into a decrease, is with various forms of
admission
On Thu, 28 Aug 2003 [EMAIL PROTECTED] wrote:
anyone else been asked to rate limit by the U.S. Department of Homeland
Security?
Just about everyone with a large enough US office was asked by DHS, in a
public statement...
Isnt there a difference between we have been asked and we have
http://tinyurl.com/li0s
Neither is really an 'order' so much as a 'suggestion'.. either way, its
kind of inappropriate to make this suggestion without knowing how each
operator can or could apply a fix... that is my opinion atleast.
The thing is - DHS told us so is the new favourite excuse
Inline.
On Thu, Aug 28, 2003 at 12:01:16PM -0400, Sean Donelan said something to the effect of:
On Thu, 28 Aug 2003, Steve Carter wrote:
The rate-limiters have become more interesting recently, meaning they've
actually started dropping packets (quite a lot in some cases) because of
the
On Thu, 28 Aug 2003 [EMAIL PROTECTED] wrote:
http://tinyurl.com/li0s
Neither is really an 'order' so much as a 'suggestion'.. either way, its
kind of inappropriate to make this suggestion without knowing how each
operator can or could apply a fix... that is my opinion atleast.
The
We have been doing that. During quiet times our Customer Service Reps
(CSR) are calling infected users telling them
a) Their computer has been compromised. In its current state it can
potentially be taken over by others or other users can look at the contents
of their private files etc.
b)
Selon Christopher L. Morrow [EMAIL PROTECTED]:
On Thu, 28 Aug 2003, [EMAIL PROTECTED] wrote:
On Thu, 28 Aug 2003, Christopher L. Morrow wrote:
Rate-limiting ICMP is 'ok' if you, as the provider, think its worthwhile
and you, as the provider, want to deal with the headache
On Thu, 28 Aug 2003, Mike Tancsa wrote:
The majority comply and are understanding.
and the rest?
-Dan
--
[-] Omae no subete no kichi wa ore no mono da. [-]
At 01:57 PM 28/08/2003 -0700, Dan Hollis wrote:
On Thu, 28 Aug 2003, Mike Tancsa wrote:
The majority comply and are understanding.
and the rest?
There will always be troublesome customers, but the VAST majority have been
compliant. If they dont want to comply to something as reasonable as this,
It should be pointed put that the ISPs have their share of blame for the
quick-spreading worms, beause they neglected very simple precautions --
such as giving cutomers pre-configured routers or DSL/cable modems with
firewalls disabled by default (instead of the standard end-user, let only
I'm still waiting for a P2P system running inside IPsec. With XP
and W2k making inroads on consumer computers there now is a significant
user base with access to luser-friendly systems carrying these
capabilities.
I'm not positive, but I thought Filetopia used SSL transfers on port 443 for
Since some p2p programs now use well known port numbers allocated to other
things eg port 80, is it even possible to block/rate limit them? And have folks
attempts at blocking caused this move to use such port numbers which imho is not
a good thing..
As long as there are some bits in the
Im interested in an informal poll of consumer ISPs
regarding application rate-limiting. For all you folks out there managing
broadband networks to residential end-users:
Are you controlling peer-to-peer traffic in some way (i.e. rate-limiting,
blocking, etc)?
Do you have plans
* [EMAIL PROTECTED] (Owings, Curtis L [GMG]) [Tue 22 Jul 2003, 20:10 CEST]:
I'm interested in an informal poll of consumer ISP's regarding
application rate-limiting. For all you folks out there managing
broadband networks to residential end-users:
We're asking everybody to turn off HTML when
On Tue, 22 Jul 2003, Niels Bakker wrote:
* [EMAIL PROTECTED] (Owings, Curtis L [GMG]) [Tue 22 Jul 2003, 20:10 CEST]:
I'm interested in an informal poll of consumer ISP's regarding
application rate-limiting. For all you folks out there managing
broadband networks to residential end-users
On Tue, 22 Jul 2003 20:13:35 +0200, Niels Bakker wrote:
We're asking everybody to turn off HTML when they post to mailing lists.
Here's some boilerplate I wrote for this purpose:
http://www.camblab.com/nugget/turnoff.txt
Repost in plain text... just a little too clicky on the send button
folks.
I'm interested in an informal poll of consumer ISP's regarding
application rate-limiting. For all you folks out there managing
broadband networks to residential end-users:
Are you controlling peer-to-peer traffic
Are you controlling peer-to-peer traffic in some way (i.e.
rate-limiting, blocking, etc)?
no
Do you have plans to control peer-to-peer traffic?
no
Are you imposing other total traffic download/upload limits?
no
Additional comment: we market based on no limits and so far have
met our
Are you controlling peer-to-peer traffic in some way (i.e.
rate-limiting, blocking, etc)?
no
Do you have plans to control peer-to-peer traffic?
Kittredge wrote:
Are you controlling peer-to-peer traffic in some way (i.e.
rate-limiting, blocking, etc)?
no
Do you have plans to control peer-to-peer traffic?
no
Are you imposing other total traffic download/upload limits?
no
Additional comment: we market based
Excellent point. It does depend on the traffic type.
Though I don't like to complicated my configs, you can always use CAR (cisco rate
limiting) through an ACL to protect against the file transfer from the core servers
issue you referred to below. It can make sure a high bandwidth xfer won't
; Andy Dills; prue; [EMAIL PROTECTED]
Subject: Re: RATE-Limiting and
Depends on the equipment you have installed. If you are running a
65xx/76xx if you are running mls with full flow masks you can set up a
microflow policer which would allow you to mark or drop traffic on a per
flow basis
62 matches
Mail list logo
