Quantifiable Proof and "Peering Profiles"...see below.
At 08:53 PM 12/16/2002 -0800, Joe Wood wrote:
On Mon, 16 Dec 2002, Joe Abley wrote:
> I think the idea was to say "well, from the mrtg graph, the difference
> between this circuit with all my _9327_ traffic and this circuit
> without any _
On Mon, Dec 16, 2002 at 11:41:12PM -0500, [EMAIL PROTECTED] wrote:
>
> > Also, that method has the same "knowing the routes" problem as netflow.
> > Whereever you are getting your list of ASN's route ASN.*"'s routes, there
> > is pretty much no way they are accurate (for an ASN of ANY size).
>
http://www.nwfusion.com/research/2002/1216isptest.html
-Hank
On Mon, 16 Dec 2002, Joe Abley wrote:
> I think the idea was to say "well, from the mrtg graph, the difference
> between this circuit with all my _9327_ traffic and this circuit
> without any _9327_ traffic, at what I might reasonably estimate their
> peak time to be, looks to be about 2 megs or
At 09:16 PM 12/16/2002 -0500, K. Scott Bethke wrote:
Impressive numbers but of course, slackers aside, if it was your connection
and resources wouldnt you want more accurate information than just a guess?
Yes, but I am also sympathetic to the challenges to ISPs in this economy,
and the challen
> > > based on ALL the ASN's of the people on the peering switch.. but in most
> > > cases anyone pushing any real traffic will probably not have fine grained
> > > samples enough to determine a peering relationship based on a single AS
> > > with this method. Maybe Im wrong but hey if you are
> On Monday 16 December 2002 07:37 pm, Joe Abley wrote:
> > If you are interested in traffic *to* a particular destination, surely
> > you could just tweak localpref on routes based on an as-path filter?
>
> And then quantify it how? Ie; useful Netflow-like "x Mbps to AS x, y Mbps to
> AS y" sta
> > based on ALL the ASN's of the people on the peering switch.. but in most
> > cases anyone pushing any real traffic will probably not have fine grained
> > samples enough to determine a peering relationship based on a single AS
> > with this method. Maybe Im wrong but hey if you are taking 2
> Hi all -
>
> Here is the problem: Everyone wants to know how much traffic would
> ultimately be passed in peering relationships at an IX before signing
> up/building into an IX.
>
> I heard an interesting solution recently to estimating the traffic volume
> destined to an AS in the absence
On Monday, Dec 16, 2002, at 22:47 Canada/Eastern, Grant A. Kirkwood
wrote:
On Monday 16 December 2002 07:37 pm, Joe Abley wrote:
If you are interested in traffic *to* a particular destination, surely
you could just tweak localpref on routes based on an as-path filter?
And then quantify it ho
On Monday 16 December 2002 07:37 pm, Joe Abley wrote:
> If you are interested in traffic *to* a particular destination, surely
> you could just tweak localpref on routes based on an as-path filter?
And then quantify it how? Ie; useful Netflow-like "x Mbps to AS x, y Mbps to
AS y" statistics?
--
On Monday, Dec 16, 2002, at 22:28 Canada/Eastern, Richard A Steenbergen
wrote:
On Mon, Dec 16, 2002 at 09:16:55PM -0500, K. Scott Bethke wrote:
based on ALL the ASN's of the people on the peering switch.. but in
most
cases anyone pushing any real traffic will probably not have fine
grained
On Mon, Dec 16, 2002 at 09:16:55PM -0500, K. Scott Bethke wrote:
>
> based on ALL the ASN's of the people on the peering switch.. but in most
> cases anyone pushing any real traffic will probably not have fine grained
> samples enough to determine a peering relationship based on a single AS
> w
On Mon, Dec 16, 2002 at 05:46:10PM -0800, William B. Norton wrote:
>
> 1) You adjust routing to prefer one transit provider or the other for the AS
> 2) Shift traffic to the particular AS from one transit provider to the
> other, noting the change in the loads on the transit providers.
Ouch. Am
Hi Bill,
Impressive numbers but of course, slackers aside, if it was your connection
and resources wouldnt you want more accurate information than just a guess?
This may be effective for an IX decision if you created some sort of a map
based on ALL the ASN's of the people on the peering switch..
Hi all -
Here is the problem: Everyone wants to know how much traffic would
ultimately be passed in peering relationships at an IX before signing
up/building into an IX.
I heard an interesting solution recently to estimating the traffic volume
destined to an AS in the absence of NetFlow or t
>
> Even though you are asking this question with regard to what can
> be done on the router itself, it's worth mentioning, if only for
> the archives, a non-router approach to the problem...especially if
> you are an enterprise network manager. It's even worth
> mentioning despite the fact that
I can send you screenshots of our tool if you are interested.
-Original Message-
From: Andre Chapuis [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 16, 2002 9:12 AM
To: [EMAIL PROTECTED]
Subject: Identifying DoS-attacked IP address(es)
Hi,
How do you identify a DoS-attacked IP addr
On Mon, 16 Dec 2002, Feger, James wrote:
>
> AT&T also does the basics. ACL's, null routes, tracking back to ingress.
as does sprint and C&W. MFN can sometimes help, depends on who you talk to
as I recall, and Verio is quick to fix problems... L3 had some problems in
the past, my last experien
Even though you are asking this question with regard to what can
be done on the router itself, it's worth mentioning, if only for
the archives, a non-router approach to the problem...especially if
you are an enterprise network manager. It's even worth
mentioning despite the fact that I work for a
AT&T also does the basics. ACL's, null routes, tracking back to ingress.
-james
On Mon, 16 Dec 2002, James-lists wrote:
>
> > I'm sure you can look in the archives of this list for
> messages from me
> > about this very thing... :) In short: "Every ISP should
> have 24/7 security
> > support
At 09:17 PM 12/16/2002 +, Christopher L. Morrow wrote:
On Mon, 16 Dec 2002, Livio Ricciulli wrote:
> FYI, we developed a system that sniffs FE,GE,DS3,OC3-48 POS and creates
> a model using the cross-product of:
> 1) source/destination address distributions
> 2) packet rate
> 3) protocol
Bu
> I'm sure you can look in the archives of this list for
messages from me
> about this very thing... :) In short: "Every ISP should
have 24/7 security
> support for customers under attack." That support should
include, acls,
> null routes, tracking the attack to the ingress. Rarely do
rate-limits
On Mon, 16 Dec 2002 21:17:07 GMT, "Christopher L. Morrow" said:
> On Mon, 16 Dec 2002, Livio Ricciulli wrote:
>> FYI, we developed a system that sniffs FE,GE,DS3,OC3-48 POS and creates
>> a model using the cross-product of:
>> 1) source/destination address distributions
>> 2) packet rate
>> 3) prot
On Mon, 16 Dec 2002, James-lists wrote:
>
> I am wondering how much help backbone providers give in
> identifying sources of a DoS and deciding what ACL's or
> rate-limits need to be placed to bring a DoS under control,
I'm sure you can look in the archives of this list for messages from me
abo
I am wondering how much help backbone providers give in
identifying sources of a DoS and deciding what ACL's or
rate-limits need to be placed to bring a DoS under control,
for their downstream clients. (Assuming it is their
downstream clients that are being DoS'ed).
I realize this will vary from p
who signed up a ticketing system to nanog??
--Chris
([EMAIL PROTECTED])
-- Forwarded message --
Date: Mon, 16 Dec 2002 16:22:09 -0500 (EST)
From: Candid Hosting Support <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [candidhosting.com #25891] AutoReply: RE: Identifying DoS
On Mon, 16 Dec 2002, Livio Ricciulli wrote:
> FYI, we developed a system that sniffs FE,GE,DS3,OC3-48 POS and creates
> a model using the cross-product of:
> 1) source/destination address distributions
> 2) packet rate
> 3) protocol
But I can't field deploy this 2 continents away at 4am with 10
On Mon, 16 Dec 2002, Neil J. McRae wrote:
> > if something is being attacked it'll show in the 'statically limited'
> > listing, trust me... this is how we do it all day, every day...
>
> Yes as have we, however you run out of memory/list entries
> quickly and when that happens CEF gets disabled
FYI, we developed a system that sniffs FE,GE,DS3,OC3-48 POS and creates
a model using the cross-product of:
1) source/destination address distributions
2) packet rate
3) protocol
This works very well to detect floods and does not require messing with
routers..
Livio.
-Original Message---
> if something is being attacked it'll show in the 'statically limited'
> listing, trust me... this is how we do it all day, every day...
Yes as have we, however you run out of memory/list entries
quickly and when that happens CEF gets disabled and it get pretty ugly.
This is more an issue for en
On Mon, 16 Dec 2002, Neil J. McRae wrote:
> Sampled netflow, or look at the traceback stuff in later
> IOS 12.0S versions. Avoid filter lists as the GSR engine cards
> have a statically limited number of entries.
>
if something is being attacked it'll show in the 'statically limited'
listing,
Sampled netflow, or look at the traceback stuff in later
IOS 12.0S versions. Avoid filter lists as the GSR engine cards
have a statically limited number of entries.
Regards,
Neil.
On Mon, 16 Dec 2002, Andre Chapuis wrote:
> Chris,
> I often see the input-interface load is 100%.
> André
Ok, check the link Barry sent, there is some good info there... Input from
the customer is 100%? If this is the case the customer can tell you what
is being attacked, no? :)
Alternately,
Chris,
I often see the input-interface load is 100%.
André
At 16:35 16.12.2002 +, Christopher L. Morrow wrote:
>On Mon, 16 Dec 2002, Andre Chapuis wrote:
>
>>
>> Hi,
>> How do you identify a DoS-attacked IP address(es) on your ingress border router,
>assuming the latter is a Cisco 12000 ? I
On Mon, 16 Dec 2002, Andre Chapuis wrote:
>
> Hi,
> How do you identify a DoS-attacked IP address(es) on your ingress border router,
>assuming the latter is a Cisco 12000 ? I used to use ip accounting but they removed
>it from the S-code.
What info do you have when you are trying to accomplis
Check out the following:
ftp://ftp-eng.cisco.com/cons/isp/security/
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
Of
> Andre Chapuis
> Sent: Monday, December 16, 2002 6:12 AM
> To: [EMAIL PROTECTED]
> Subject: Identifying DoS-attacked IP address(e
Hello Andre
The best way we use to identify DOS attacks is measuring and monitoring the backbone
circuits the packets/second in and out, normally most of the DOS attacks generated a
lot of packets/second, in our case we created an alarm that sends an email and page
each time any of our backbon
Hi,
How do you identify a DoS-attacked IP address(es) on your ingress border router,
assuming the latter is a Cisco 12000 ? I used to use ip accounting but they removed it
from the S-code.
Thanks,
André
-
Andre Chapuis
IP+ Engineering
Swisscom Ltd
Genfergasse 14
3050 Bern
+
39 matches
Mail list logo
