Gigamon IPFIX Configuration

Today I want to take a look at the Gigamon appliance and their IPFIX configuration. Recently I was asked a rather interesting question. An avid user of Scrutinizer had a very specific element he wanted to collect and monitor. He wanted to trend what SSL version his internal servers are currently running, as well as the most common version his users come across in the wild. Now, immediately my mind goes to decryption or deep packet inspection. I know that with a bit of work we could accomplish this using our FlowPro that already does DPI. But wait, there’s a simpler way? That’s right, among other elements Gigamon is exporting SSL info in their IPFIX exports! That’s very exciting.

Now, I’ve never had any hands on time configuring or playing with a Gigamon appliance. I will say, there is a bit of difference in the configuration if you’re mainly used to enabling NetFlow on a Cisco device. Let’s take a look at how to turn NetFlow on and start reporting on some of these awesome exports!

Before diving into our IPFIX configuration, there are two items I have to note. In order to generate the metadata required for IPFIX exports you would need to acquire a GigaSMART blade for the modular node HC2, HD4 and HD8. For HB1, GigaSMART is already in the unit. In addition to the correct hardware you will also need to acquire the metadata license. For generating IPFIX you will need the netflow/metadata license.

Now when configuring IPFIX on a Gigamon appliance there are a few extra steps we’ll need to take. First we’ll want to setup a GigaSMART group. Here we’re going to be creating a group to assign parameters to. For example I created my GigaSMART Group for NetFlow and De-duplication. With de-duplication you can set parameter such as counting the de-dupes versus dropping them. Which elements are included in de-duping, for instance should I look at the headers and include the TCP class, ToS, the TCP sequence. In your GigaSMART Group you can also set your flow sampling rate. Now, I do recommend using 1:1 for the best reliability and most complete picture. Another interesting segment is the ability to do SSL decryption. As awesome as that would be, we’ll have to visit this topic later as we’ll need to have our SSL key installed on the appliance.

Next we’ll want to create a tunnel port. Now this leads to one of those differences I mentioned. Gigamon does something different with their ports than traditional switch ports. Traditionally a switch port will receive and transmit. Gigamon has decided to modify this default behavior and have set roles per port. For example, a network port will only receive traffic and a tool port will only transmit data. Now our tunnel port we’re creating is going to be our tool port which will transmit our IPFIX data to a NetFlow collector. First we’ll choose the port we want to transmit from, then we can assign an IP address to the tunnel port. This will be our source IP for IPFIX traffic. Next we’ll assign a subnet mask and a default gateway. Now this leads to another interesting fact on the Gigamon setup, the default gateway we’re assigning here needs to be the IP of our NetFlow collector. Having them on the same subnet also makes life a little easier. I set the maximum transmission unit (MTU) to 1500. Then finally we’ll assign this to the GigaSMART Group we just setup.

Once the tool port is configured, you’ll also need to span some traffic to the appliance from a nearby switch. For this port we’ll want to configure it as a network port as it will only listen for traffic.

Now that we have our two ports setup, one to listen and one to transmit, we’ll need to setup our GigaSMART Operations. The GSOP gives us the ability to do some more very cool things like tunnel encapsulation and decapsulation. For this blog though, we’re just going to assign Netflow and Deduplication for our GSOP.

Excellent, so now we have our GigaSMART Group, our ports are configured and we’ve defined our GSOP. Now we can start to define our NetFlow record, exporter and monitor!

Under NetFlow/IPFIX Generation we’ll want to start with our record. This should be something most of us are familiar with, we’ll want to set our match and collect statements here. We can have up to 5 records tied to each monitor, so this gives us a little flexibility. However, in order to use multiple records with the same monitor they’ll need to contain the same key fields. Now in my testing, I have everything I need in IPFIX exports coming from 1 record. In this record I’m receiving my traditional NetFlow (i.e my source/destination IPs, source/destination transport ports) but I’m also exporting all of the SSL information including the issuer’s common name, ssl version, key size, full URL strings. There are a lot of options available for us.

Once I have my record defined, we’ll want to go ahead and configure our exporter. The exporter is pretty straight forward, we’ll want to give it an alias, specify the version of flow exports (in this case IPFIX), specifiy the template refresh ineterval (I have mine set to 60), assigning our tunnel port configured earlier and finally the transport configuration. The transport configuration is where we’ll want to specify the destination IP, the destination port, transport protocol, etc. Now in my example I’m using port 2002 as I’m sending the flow data to a UDP replicator before our NetFlow collector. If you’re sending straight to a collector you’ll want to use one of the pre-defined listening ports such as 2055,2056,9995,9996, etc.

Finally, we’ll want to configure our monitor. This is where we’ll specify our timeout rates and tie in our record. I recommend setting the active timeout to 60 as we’ll want to be receiving 1-minute updates even if the conversation is still alive. Here I have my inactive timeout set to 15, and again our sampling rate I have specified as 0 since I don’t want to perform any sampling. Lastly assign your flow record, we can use up to 5 records per monitor, but in this example I’ll just be using one.

Ok, just a few more steps before we can start analyzing all this new traffic! Next we’re going to create a map, which will tie our network interface and our tunnel interface together. Of course we’ll want to give our map an alias and a nice description of where traffic is coming in and which interface it’s leaving, as it’s good practice. Next we’ll want to specifiy our source port, this will be our network port where we’re receiving traffic. Then our destination port, which is the tool port we’re going to be exporting across. Then we’ll tie our GSOP to the map. Finally we’ll want to create a map rule, I defined my map rule by MAC address, and specified any MAC as the source and any MAC as the destination to allow the traffic through.

And finally our final step is going to be associating our monitor to our GigaSMART Group. If we get into editing our GigaSMART Group, about a thid of the way down is the NetFlow parameter, this is where we’ll associate the monitor we just created.

Now that our configuration is complete we can verify our setting via the CLI. We’ll want to SSH in using the admin user and these following commands will confirm our configuration:

sh tunneled-port stats all

-Here we can verify our tunnel port is configured correctly and ARP is resolving

Not that since this is a tunnel port, we’re only using this to transmit data therefor any traffic sent to this port is dropped.

sh apps netflow exporter stats all

-Verify that new records are being added and packets are being sent to our collector

sh apps netflow monitor stats all

-Verify flows are being added and that our sampling rate is 1:1

sh port params

-Verify our port roles are set correctly

sh port in-use

-Verify our configured ports are up

Congratulations! Now you have some awesome IPFIX data coming from your Gigamon appliance! Last, but not least, we’ll want to use our favorite NetFlow Collector to analyze this traffic.

For more information on Gigamon’s IPFIX exports take a look at their documentation here.

For more information about configuring NetFlow and Sflow feel free to browse our many blogs here.