I wonder if anybody one there has had experience with both xedia and
packeteer and would let me know what the strengths and weaknesses was of
each
Michael Gibson
Team Leader, Network Operations - Netcom Canada
Telephone: 416-341-5751 Fax: 416-341-5725
magibson@netcom.ca
I'm doing such a comparison right now..
Here are the things I am concerned about:
Xedia: Does T3/ATM interfaces and routes
Packeteer: Bridge Ethernet only.
Xedia: 600 individual profiles
Packeteer: 4096 (I think, double checking that with them)
Xedia: Doesn't need two routers
Packeteer: Since it only bridges, it has to be between two intelligent
devices. I don't think looping it out and back to the same Cisco would
work.
Since I need more profiles, I am leaning toward a Packeteer.
If anyone else has notes, I would like to hear them.
----------------- Brian Curnow ----------------
Packeteer replied.. Only 512 classes currently managed, but they claim
they are going to raise that 'significantly' in the next '3' months.
----------------- Brian Curnow ----------------
I've been using the Packetshapper 4000 and have been having terrible
performance when I consistantly push out 20Mbps+. The pshaper4k sits
between my edge router and my backbone FE switch (so all traffic goes
through it).
Withouth going into too much detail, when the box inline with power on
(and shaping on or off), I get about 10% packet drop and anywhere from
20ms-1000ms delay going through that box. If I power it off or take it
out of the picture, problem goes away.
I've hit some limits because before I was consistantly above 20Mbps, the
box worked very well. I've had the tech guys take a look at it and they
did mention I was hitting some hard limits.
- mz
Matthew:
What version of code are you running in your 4000 -- I see no such latency
issues nor packet drop and we regularly push 20+ Mb through our boxes...
sits between a Cisco 75xx and Catalyst 5000 Switch.
Are you using the same cable/cables when you place the packetshaper
in the network vs. when it is out? Also, have you looked at the CLI for
the NIC stats?
Chris
I got some followups/corrections on key points which I feel I should
distribute:
The person from Xedia who told me 600 was the class limit, emailed me
again and realized that I might really mean how many end points under
control of those classes. The answer I came away with is that the Xedia
can support a lot more end points (users) than 600. Hope I got that
right. 
An engineer at UU.net also said 600 was too low, and that it is more an
issue of how much RAM is in the box. He said thousands, which sounds
promising.
So, if I had to buy today, it looks like Xedia is the one to have if
you're doing things on a large scale.
----------------- Brian Curnow ----------------
Matthew:
What version of code are you running in your 4000 -- I see no such latency
issues nor packet drop and we regularly push 20+ Mb through our boxes...
sits between a Cisco 75xx and Catalyst 5000 Switch.
PacketShaper v3.1.3g14 1998-09-15.
Are you using the same cable/cables when you place the packetshaper
in the network vs. when it is out? Also, have you looked at the CLI for
the NIC stats?
Yeah, same cables.
I believe the issues was in the number of sessions the box was handling,
not the amount of bandwidth. I believe we were looking at "mib tcp" -
some of the values we were seeing were nearing the limits of the box.
One of the websites that we host, but don't shape, typically gets
200-300 hits per second during peak. Which, of course, has a direct
impact on bandwidth.
The technical explaination that made the most sense to me was the
increase in hits per second meant an increase is hosts the p4k was
managing.
I can track down my emails and talk to you offline about this, if you're
interested.
- mz
We had similar problems like this. While our problems haven't gone
entirely away, support at packeteer gave us some suggestions which
dramatically fixed some of the problems...
- Upgrade to the latest code (3.1.3g I believe)
- Make sure your available bandwidth is set to 45MB not 100MB.
- Make sure both NIC cards are set the same (if you do a 'net nic 0' and
'net nic 1' in the CLI, it will show you whether or not they're both
running at full duplex, half, or a combination of both). If they're set
differently (e.g. we had one set to 100 Half and the other 100 Full), it
will think it's got more bandwidth available than it actually does (so I'm
told)
One of the main problems we're dealing with now is incoming traffic. If
you upload something (ftp) over the physical LAN, it will use most if not
all available bandwidth, however if you upload something over a T1, etc,
that 20K you might get over ethernet becomes 4K (we've cancelled out the
possibility of it being the network it's going through). I think this may
have something to do with the shaper sending certain TCP retries or
sending back packets in way that a 100MB ethernet link can recover
quickly, but the general internet cannot.
Another issue (which is likely related to the first), is if you reach a
customer's peak burstable rate, transfers freeze up for 3-5 seconds, as if
it's stopping all packets going to through the partition rather than
allowing the peak amount through. This isn't a big deal for customers
using 50% of their bandwidth, but for 256k or 512k partitions it presents
a problem.
packeteer is looking into this.
I was told that the xedia boxes only shape outgoing bandwidth, not
incoming. I haven't had the chance to ask xedia about this yet, and
haven't gotten their box in yet, so I'm not positive if this is true, but
you may want to check it out before buying.