Gigamon...fixing problems you didn't know about

Date October 28, 2011

Yesterday, we stopped by the offices of Gigamon, a company that I first came across at VMworld. When I talked to them and learned what they did, I kind of slapped my forehead, and I thought, "wow. That's awesome. Why didn't *I* think of that???"

So I laughed when, during their presentation at Networking Field Day 2, my friend Kurt Bales said:

So yeah, apparently that's the standard response. They're in the unfortunate place of only having two categories of marketing contacts...there are people that have bought stuff from them, and there are people who haven't heard of them.

In order to best explain what they do, it might be better to describe how the industry functions without them.

Suppose you have a rack full of servers with a switch. You need to monitor a specific server's traffic, and say, to pipe it to an Intrusion Detection System. What are your options?

Well, on the low end, you could just plug in a hub to the server's port on the switch, then plug both the server and the IDS into the hub. Everything gets all of the traffic.

Of course, there are a lot of drawbacks....namely that if your server is moderately busy, you get collisions from the hub only being half duplex, so your throughput drops. Also, it doesn't scale....what if you need to monitor two servers? Get another hub? That's just not a good idea.

Most managed switches include a feature allowing a specific port to be a "monitor" or "mirror" port (on Ciscos, they're frequently referred to as SPAN ports). This means that you can plug the IDS directly into the switch, and specify that IDS's port as the mirror port, and suddenly it gets a copy of all of the traffic destined for that other server.

This scales slightly better - some switches allow you to mirror multiple source ports. The downside is that you are limited to the mirror port speed. If it's a 1Gb/s port, and you're mirroring 4 1Gb/s ports...it doesn't take a lot of concurrent traffic before you start to get dropped traffic on the mirror port.

Also, suppose you've got a couple of switches. In this case, you need an interface on the IDS for each of the switches. This might scale if you run small networks, but anything approaching more than half a dozen monitoring ports starts to need a seriously heavy set of CPUs to process everything, and the monitoring server becomes a HEAVY expense, plus it only scales so far.

In the end, in order to monitor the network, you need to either have a lot of IDS-type machines, or you need to make it a part-time only endeavor.

Gigamon apparently looked at the way things were and said, "We can do better".

What they've done is build machines that are essentially programmable pipelines for monitored data.

That sounds weird, so here's how it breaks down. You have a Gigamon device, say a GigaVue 212:

You take a SPAN port from your switch, and you plug it into one of those ports. Then, you take your IDS and plug it into another port. Then you configure the Gigavue to send traffic from the SPAN port to the IDS.

So far, 100% compatibility. Here's where things get awesome.

Suppose the reason you're monitoring is because you need to evaluate, say, HTTP traffic over time. You can configure the Gigavue such that ONLY HTTP goes to the IDS (or whatever the target is - you could use anything). You can finely tune it, too!

Suppose you've got an IDS going which receives all non-encrypted traffic, then some kind of weird network error crops up and you want to examine DNS packet headers. You can add a rule that redirects all DNS packet headers (yes, you can strip out the data and just look at headers) to another machine plugged into the Gigavue. That traffic doesn't impact the original monitoring whatsoever.

You can use as many ports as you have on the Gigavue, too, with all kinds of rules. You can have multiple input sources into multiple output ports, slicing and dicing according to the rules you set up. It'll also strip packet metainfo like VLAN tags and MPLS labels that sniffers usually have problems with.

There's kind of an amazing video that you should watch that covers a lot of stuff, which I'm embedding below:

I'm really impressed with them. If I ran a large infrastructure, you can bet that these devices would be part of my build-out. It wouldn't be recommended, it would be built into the fabric. I didn't know that tools like this existed, but now that I do, I'm going to recommend them.

Read more about them and check them out, because the technology is really sweet, and I can see them being a big thing in the future.



Disclosure:
This post mentions a company which paid my employer to partake in an event. I was not paid to write this post, nor was it requested of me. This company has provided me nothing of value besides things which would be considered normal conference swag, such as memory sticks, bags, or pamphlets of information. I write this entry of my own volition and stand by the contents. As always, if I say something is good, it is because I think it is good, not because someone asked me to say it is good.

  • Pingback: Networking Field Day 2: The Links()

  • http://www.frlinux.eu FRLinux

    This is truly awesome stuff, would love to hear about real users cases out there :)

  • Pingback: Why Gigamon Scares The Crap Out of Me — Evil Routers()

  • Pingback: Gigamon and the Great Pumpkin | Router Jockey()

  • LeftRightLeft

    Nice write up! Gigamon is a fantastic company. Their product offerings are great and their support is stellar. We currently run several of their devices porting traffic to multiple different packet capture, APM, and security tools. We literally have saved millions in hardware costs because of the ability to aggregate all of our sources to individual ports.

    ...enough of my evangelization though!

  • Raúl

    This steering functionality has been implemented in Allot's devices for 3 years now, providing more granularity and versatility regarding the conditions you can configure to divert the traffic (traffic itself or a just a copy), such us: IPs, VLANS (even C-VLAN and S-VLAN in QinQ environments), L7 applications, physical ports, time of the day (you could just divert traffic at a specific time of the day when a problem occurs), DSCP, etc, etc.