From: Jamal Hadi <hadi@shell.cyberus.ca>
To: netdev@oss.sgi.com
Subject: Real World Traffic WAS(Re: Route cache performance tests (fwd)
Date: Wed, 11 Jun 2003 08:09:52 -0400 (EDT) [thread overview]
Message-ID: <20030611080924.D39831@shell.cyberus.ca> (raw)
I think is interesting enough for general consumption
---------- Forwarded message ----------
Date: Wed, 11 Jun 2003 07:38:41 -0400 (EDT)
From: Jamal Hadi <hadi@shell.cyberus.ca>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: Pekka Savola <pekkas@netcore.fi>, ralph+d@istop.com,
Simon Kirby <sim@netnation.com>, CIT/Paul <xerox@foonet.net>,
'David S. Miller' <davem@redhat.com>
Subject: Real World Traffic WAS(Re: Route cache performance tests
Ok time to start changing topics; this thread is already over two
hundred emails ;->
On Tue, 10 Jun 2003, Florian Weimer wrote:
> Pekka Savola <pekkas@netcore.fi> writes:
>
> > I really hope you're kidding about Sprint core routers.
>
> Some of the IP carriers have far too little traffic in their backbone,
> to a degree that it's an economic disaster. You need some spare
> capacity in order to deal with some aspects of IP traffic, but not a
> factor of 10 or something similar.
>
I think this is what might be happening at those sprint routers.
Note that though the pps is low the flows per secs is very high.
Look at the info on nyc-21:
The 95th percentile of traffic is around 63Kpps.
Then look at the 95th percentile for number of flows: 72K flows
this implies that each flow is getting to send less than 1pps.
I think the number of flows is also interesting. May help in formulizing
the garbage collection.
376K flows(flowi/dst cache) stored at the worst case. In the worst case
88K flows are active every second.
Pekka, do you have similar data you collect as well?
> I once asked a networking engineer at another rather large NSP to do
> some DoS backtracking for me. The network apparently used GSRs
> throughout its core. Unfortunately, GSRs are very shy in the standard
> configuration and they won't reveal much data about the traffic they
> are routing. So this guy issued "ip route-cache flow" on the
> interface on which the traffic was leaving his AS. It took him over
> an hour to get that line card up again. Ouch. The funny thing is,
> however, that the engineer insisted that this had always worked for
> him on all other routers. ("ip route-cache flow" turns on flow-based
> process switching, and the line card CPU and its buses are certainly
> not powerful enough for that! If it causes no problems, you could
> certainly use a 72xx or 75xx, maybe even a PC running Linux 8-) to
> route that traffic.)
isnt that equivalent to what we do with route caching?
cheers,
jamal
next reply other threads:[~2003-06-11 12:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-11 12:09 Jamal Hadi [this message]
2003-06-11 17:00 ` Real World Traffic WAS(Re: Route cache performance tests (fwd) Pekka Savola
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030611080924.D39831@shell.cyberus.ca \
--to=hadi@shell.cyberus.ca \
--cc=netdev@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).