[189428] in North American Network Operators' Group
Re: Network traffic simulator
daemon@ATHENA.MIT.EDU (Saku Ytti)
Wed May 25 16:44:13 2016
X-Original-To: nanog@nanog.org
In-Reply-To: <1557596034.107538.1464208479799.JavaMail.zimbra@cluecentral.net>
Date: Wed, 25 May 2016 23:44:09 +0300
From: Saku Ytti <saku@ytti.fi>
To: Sabri Berisha <sabri@cluecentral.net>
Cc: NANOG <nanog@nanog.org>, Mitchell Lewis <mitchell@dash-networks.com>
Errors-To: nanog-bounces@nanog.org
On 25 May 2016 at 23:34, Sabri Berisha <sabri@cluecentral.net> wrote:
> This depends very much on which Ixia product you're using. In IxExplorer =
and IxNetwork require a lot of manual labor when setting up a test. IxLoad =
has a little less, but still. It is important to realize that most of the t=
ests can be automated using TCL scripts. The company I'm currently with has=
an entire team doing nothing but test automation using Ixia TCL.
I think the problems I pointed out are not fixable by TCL. The
hardware itself simply cannot burst for any reasonable period, it only
paces.
You could create multiple streams and have TCL turn the burst on
occasionally, but how to synchronise this in nanosecond level with the
main stream, and at least in tens of microseconds resolution in
duration? You can't do that, it takes easily 10s to command it to do
something on TCL.
Lot can be done, but for device costing that much, and virtually no
QoS testing can be done, I'm not happy camper. QoS by nature is not
paced. And QoS configuration which looks perfect in IXIA may not work
in real-life. And in my case conversely, real-life problem we had, we
could not replicate in lab with IXIA. I know two other companies who
experienced same, and IXIA SE was unable to solve it.
It is very clear development of software is being dominated by
hardware vendors, not by SPs.
--=20
++ytti
