[unisog] Any GigaVUE 420 opinions?

Peter Van Epp vanepp at sfu.ca
Sat Aug 16 15:50:07 GMT 2008

On Fri, Aug 15, 2008 at 09:57:24AM -0700, John Ives wrote:
> Hash: SHA1
> Peter Van Epp wrote:
> > 	Is anyone using a GigaVUE-420 (http://www.gigamon.com/) at 10 gigs?
> We have one and are rather happy with it.  So far we haven't pushed more
> than 1.7 or so gigs through it at a time, but the performance has been
> what we expected and being able to pre-filter the packets going to each
> box has decreased the interrupt load on the IDS boxes by around 70%.  My
> plan (which we have partially implemented) is to use this to make a
> pseudo-cluster of snort boxes in which each box is a relatively
> inexpensive off-the-shelf system, each of which is identically
> configured (using cfengine or something similar to manage changes) and
> only watches part of the overall bandwidth.
	Thanks, thats useful. Just after posting I heard that Netoptics is 
going to release a similar box in the near future. Being a happy Netoptics
customer for 15 or more years I'll be giving that a hard look as well.
	While I need to go the other way (several slower ports to one fast one)
I believe these boxes are part of the solution for 10 gigs and are the only
option for 40 and 100 gig (which our ROADM 10gig network will support sometime
in the future). The current magic number at 10 gigs is 6.8 gigs. That is the
speed of a 16 lane pci-e card (you would look to need a 32 lane card to get
wire speed) and it happens to be the effective bandwidth of most current 
DIMMS. Since I don't see big changes (dram speed hasn't changed much in the 
last 25 years, density and interleaving are whats underlying the speed up). 
At least one capture vendor I know of has an honest marketing department that
tells you that their box will only capture 6.8 gigs on a 10 gig link :-). 
	Something to think about / push your mux vendor for is an api or more
probably protocol that can route input traffic by 5 tuples. The problem with
a static routed box (which is what you have now I think) is that a line speed
attack on a single 5 tuple will oveload it. To beat that we are going to need
to have a bgp like protocol that the IDS (or more correctly a management box
on the IDS) can use to dynamically reroute 5 tuple traffic between MUX ports. In
the case of the wire speed attack, if you have a 10 gig and 24 gig ports on
the mux box then you can distribute a full wire speed attack to 20 of those
ports on a round robin basis and  in fact take a node failure or two and use
spare nodes on the extra mux ports ($$$ of course :-)) to recover. The manager 
on the IDS can then deal with delivering the parallel streams (hopefully 
reduced in content) to be recombined in an analysis engine. Argus can already
do this although it doesn't look at user data nor try and defrag the stream.
The same type of thing is probably going to be the only solution (along with 
petabyte file stores and huge amounts of money :-)) for data capture at those 
speeds too. 
	Another very desirable option in the mux box would be to be able to 
time stamp the packet at the output of the PHY on the 10 gig link (as a DAG
card does). That eliminates latency issues in the multiplexing (and would make
my network researchers happy :-)). The exciting part of course is how do you 
associate the timing data with the packet. I suspect a dedicated interface
that outputs the time stamp (suitable for creating a pcap record from!) and 
enough header info to id the packet and what mux interface it was on would
do the trick.

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada

More information about the unisog mailing list