In this blog, I will go over Gigamon NetFlow support. As you’ve probably already seen, if you follow our blogs, many new devices are now supporting NetFlow/IPFIX, and Gigamon is no different. Gigamon has created some highly advanced network taps that allow the user to generate NetFlow/IPFIX; from there, they send this data to an external collector, for further reporting. This can be a huge help to those of you that have devices on your network that do not natively support NetFlow/IPFIX.Now with the help of Gigamon you can get some visibility in areas that would otherwise be impossible. I will outline some of the different NetFlow exports that Gigamon can do, as well as the different versions below.
Gigamon NetFlow/IPFIX Support:
The following 3 NetFlow protocol formats are available in the Gigamon NetFlow implementation. I would verify that your NetFlow monitoring tool supports one or all of the following to ensure you don’t run into issues down the road.
- NetFlow v5
- NetFlow V9
- IPFIX
NetFlow/IPFIX Record Configuration:
For NetFlow v5 record, Gigamon solution comes with a pre-defined NetFlow v5 record, which is not user-editable.
For NetFlow v9 and IPFIX records, the user is able to configure record fields (both keys and non-keys) as mentioned below.
The user can specify the number of ‘match’ key fields in a NetFlow record. The different supported combinations are mentioned in the table below.
| parameters | |||
| datalink | |||
| mac | source | ||
| destination | |||
| vlan | |||
| ipv4 | dscp | ||
| header-length | |||
| id | |||
| option-map | |||
| precedence | |||
| protocol | |||
| tos | |||
| version | |||
| destination | address | ||
| mask | [minimum-mask <mask>] | ||
| prefix | |||
| fragmentation | flags | ||
| id | |||
| offset | |||
| section | header-size <size> | ||
| payload-size <size> | |||
| source | address | ||
| mask | [minimum-mask <mask>] | ||
| prefix | |||
| total-length | |||
| ttl | |||
| ipv6 | dscp | ||
| flow-label | |||
| next-header | |||
| payload-length | |||
| precedence | |||
| protocol | |||
| traffic-class | |||
| version | |||
| destination | address | ||
| mask | [minimum-mask <mask>] | ||
| prefix | |||
| extension-map | |||
| fragmentation | flags | ||
| id | |||
| offset | |||
| hop-limit | |||
| length | header | ||
| payload | |||
| total | |||
| section | header-size <size> | ||
| payload-size <size> | |||
| source | address | ||
| mask | [minimum-mask <mask>] | ||
| prefix | |||
| transport | destination-port | ||
| igmp | type | ||
| source-port | |||
| icmp | ipv4 | code | |
| type | |||
| ipv6 | code | ||
| type | |||
| udp | destination-port | ||
| message-length | |||
| source-port | |||
| tcp | ack-number | ||
| destination-port | |||
| flags | [ack] | [cwr] | [ece] | [fin] | [psh] | [rst] | [syn] | [urg] | ||
| header-length | |||
| sequence-number | |||
| source-port | |||
| urgent-pointer | |||
| window-size | |||
The user could specify number of ‘collect’ non-key fields in a NetFlow record. The different supported combinations are mentioned in the table below.
| collect_type | parameters | ||
| counter | bytes | [long] | |
| packets | [long] | ||
| datalink | dot1q | vlan | |
| mac | source | ||
| destination | |||
| vlan | |||
| ipv4 | dscp | ||
| header-length | |||
| id | |||
| option-map | |||
| precedence | |||
| protocol | |||
| tos | |||
| version | |||
| destination | address | ||
| mask | [minimum-mask <mask>] | ||
| prefix | |||
| fragmentation | flags | ||
| id | |||
| offset | |||
| section | header-size | <size> | |
| payload-size | <size> | ||
| source | address | ||
| mask | [minimum-mask <mask>] | ||
| prefix | |||
| total-length | [minimum] | ||
| [maximum] | |||
| ttl | |||
| ipv6 | dscp | ||
| flow-label | |||
| next-header | |||
| payload-length | |||
| precedence | |||
| protocol | |||
| traffic-class | |||
| version | |||
| destination | address | ||
| mask | [minimum-mask <mask>] | ||
| prefix | |||
| extension-map | |||
| fragmentation | flags | ||
| id | |||
| offset | |||
| hop-limit | [maximum] | ||
| [minimum] | |||
| length | header | ||
| payload | |||
| total | [maximum] | ||
| [minimum] | |||
| section | header-size <size> | ||
| payload-size <size> | |||
| source | address | ||
| mask | [minimum-mask <mask>] | ||
| prefix | |||
| timestamp | sys-uptime | first | |
| last | |||
| transport | destination-port | ||
| igmp | type | ||
| source-port | |||
| icmp | ipv4 | code | |
| type | |||
| ipv6 | code | ||
| type | |||
| udp | destination-port | ||
| message-length | |||
| source-port | |||
| tcp | ack-number | ||
| destination-port | |||
| flags | [ack] | [cwr] | [ece] | [fin] | [psh] | [rst] | [syn] | [urg] | ||
| header-length | |||
| sequence-number | |||
| source-port | |||
| urgent-pointer | |||
| window-size | |||
Future of IPFIX
As you can see, from the table above, Gigamon supports manyIPFIX/NetFlow fields. I wonder if they’re looking to export some of their own IPFIX fields in the future. In which case, they can open up a huge range of new and exciting IPFIX exports; all of which you can send to your NetFlow monitoring tool, for further reporting and analysis on such juicy information. If you need any help setting up Gigamon Netflow on your devices, or have some stories about threat detection with IPFIX feel free to let us know!
Related
Expanding Horizons: Scrutinizer’s Latest Release Deepens Visibility from Core to the Cloud
In an ocean of data and interconnected devices ranging from physical and virtual networks to the cloud, ensuring complete visibility and monitoring of your
::
