What comes first? Do you spend big on security and monitoring tools, appliances and software? Or deploy a smart aggregation layer fabric to support and feed these toolsets?
Introduction
IPS, IDS, DDoS protection, monitoring toolsets, Network Performance Monitoring, malware detection… All these toolsets are relevant and important in their own right. However they all have one thing in common, Packets! They all need to be fed packets to be at their most useful.
This short article describes the importance of designing a resilient and smart aggregation fabric before feeding these toolset the packets they require.
Smart Aggregation Layer
The aggregation layer or ‘fabric’ should simply be a cost effective switching solution with some filtering, packet manipulation (tagging) capabilities. With the ability to copy / replicate packets at line rate to multiple destination interfaces.
In the effort to resist using buzzwords which have little meaning lets dissect the title here:
Smart - The aggregation layer should perform at least the following functions in hardware or at line rate:
- Replication
- Filtering
- Load-balancing
- VLAN tagging
- Trigger Policies
- IP Tunnel Termination
- Time stamping
- De-duplication
- Protocol stripping/de-encapsulation
To get the most out of your security and monitoring toolsets, features such as filtering, VLAN tagging and load balancing are a must. These will provide your tools with the packets you want to see, when you want to see them. There is no point in deploying a great inline or out-of-band security appliance only to waste a significant amount of the devices resources on filtering or tagging packets into groups for further analysis.
Aggregation - The hardware layer should be able to aggregate large amounts of source interfaces from multiple sources and utilize these as required, whether this means on-demand or always on.
- Support multiple SFP types
- Be able to ingest data from fibre TAPs (2x TX interfaces from TAP split into separate interfaces on agg layer switch for RX / TX separation)
- 1G, 10G, 40G support per interface (or at least a mix)
Layer - The solution should be able to be built in a layered approach and not require large amounts of hardware from day one if not scaling to the entire network.
- Interconnect/Stacking technologies
- Device performing packet manipulation, IP termination, or trigger policies if not performed on each access aggregation switch should be able to ingest 24, 48 or more ports. Running these services from a single server device is not scalable nor cost effective.
Summary
In summary, the above is a brief checklist of features which should be expected from any serious packet broker, aggregation layer solution. Once a solid foundation is built for tool chaining, packet feeds, security and monitoring raw packet data, the selection efficiency of the connecting tools will become a much easier process.
This eliminates the requirement for replicating traffic inline with critical production infrastructure, introduces the ability to test, proof-of-concept new tools with as much raw data as the tool can ingest, at reduced deployment times and allows the monitoring toolsets to perform the analytics and monitoring functions rather than filter, slice, or aggregate packet data in addition to monitoring.