Traffic Shapping

What I meant to shape on the core: Is traffic aggregation. This is
why most vendors trying to propose different solutions hence to scale
core, e.g., proposed IETF MPLS.
Regarding the shaping issue on the Cisco Ethernet is not appreciated
while the shaping preferred to be provisioned at the outboand
I would like also to add Cisco has powerful tools must be studied well
before installing third party solution. I agree that
traffic patterns must be studied well to evaluate what approach that
must be followed.

Ehab H. Hadi
Northern Telecom
Ottawa, ON

From Sat Apr 25 15:14:14 1998
Received: from localhost (daemon@localhost)
by (8.8.7/8.8.5) with SMTP id SAA20768;
Sat, 25 Apr 1998 18:05:57 -0400 (EDT)
Received: by (bulk_mailer v1.5); Sat, 25 Apr 1998 18:05:28


Received: (from majordom@localhost)
by (8.8.7/8.8.5) id SAA20729
for nanog-outgoing; Sat, 25 Apr 1998 18:05:27 -0400 (EDT)
Received: from ( [])
by (8.8.7/8.8.5) with ESMTP id SAA20725
for <>; Sat, 25 Apr 1998 18:05:21 -0400 (EDT)
Received: from ( [])
by (8.8.8/8.8.8) with ESMTP id RAA21337;
Sat, 25 Apr 1998 17:05:16 -0500 (CDT)
Message-Id: <>
To: "Ehab Hadi" <>
Subject: Re: Traffic Shapping
In-reply-to: Your message of "Sat, 25 Apr 1998 01:03:28 EDT."
Date: Sat, 25 Apr 1998 17:05:16 -0500
From: Jeremy Porter <>

Traffic shaping in the core of a network won't scale. "enterprise" or


networks haven't got much life left in them. (This is Nanog right?)
We use 2500 series ciscos for traffic shaping at T-1 and below, but


isn't terribly related to nanog either.
One just has to look at exchange point data to see what
traffic volumes are like, I don't know of anything that
can switch VC near 2gbps/sec particuarlly with the flow life times
of Internet traffic.
It's much cheaper to shape/filter at the borders and overengineer the
core. It also increases usefull lifetime of hardware. (No forklift

I think traffic shaping is very importent. I agree to the point
that the new traffic shaping approches tends to shape on near the
edges, but that would not prevent applying such approches in the
core especially if its an interprise net.
The shapping implemintation preferred to be implemented in switch
because the hardware is simply fast and efficient.
Would you please specify what kind of Cisco platform that you are

Ehab Hadi
Northern Telecom.
Interprise Networking
Ottawa, Ontario K1Y 4H7

From Fri Apr 24 09:39:40 1998
Received: from localhost (daemon@localhost)
by (8.8.7/8.8.5) with SMTP id MAA26391;
Fri, 24 Apr 1998 12:27:05 -0400 (EDT)
Received: by (bulk_mailer v1.5); Fri, 24 Apr 1998 12:25:12


Received: (from majordom@localhost)
by (8.8.7/8.8.5) id MAA26259
for nanog-outgoing; Fri, 24 Apr 1998 12:25:11 -0400 (EDT)
Received: from ( [])
by (8.8.7/8.8.5) with ESMTP id MAA26217
for <>; Fri, 24 Apr 1998 12:24:37 -0400 (EDT)
Received: from ( [])
by (8.8.8/8.8.8) with ESMTP id LAA14282;
Fri, 24 Apr 1998 11:24:30 -0500 (CDT)
Message-Id: <>
To: "Natambu Obleton" <>
Subject: Re: Traffic Shapping
In-reply-to: Your message of "Thu, 23 Apr 1998 17:51:16 MDT."
Date: Fri, 24 Apr 1998 11:24:29 -0500
From: Jeremy Porter <>

Sure we do it all the time. There are CPU limitations on the
amount of total traffic that can be pushed through a router that
is traffic shaping. I'm assuming because all the shaped traffic is
process switched. Also you will probably want to dedicate a router
to it.

Typically these are only useful near the customer connection, as
you can really only shape outbound packets. (unless you
traffic shape at your boarders, and have a "large" network, you've
already paid for the traffic by the time you discard it.)

Has anyone here successfully implement the traffic shaping option on