Junos 20.1r1 was released recently, and with it came a rather exciting feature – the ability to configure IPFIX flow export on the SRX Branch series! This update also includes the ability to support flow record exports in chassis clusters as well. This is a great feature to support traffic analysis through a myriad of tools, and even support basic Denial of Service Attack detection. With the addition of IPFIX we can also generate flow data for IPv6 traffic which previously was not supported on the SRX. Without further ado, let’s configure IPFIX!

Sampling Methods

Typically there are two ways to sample traffic on a Junos-based device:

• Enable sampling on the interface itself
• Create stateless filters to sample specific types of traffic

Both have their advantages and drawback, depending on the type of sampling required. Typically, if you’re looking for traffic analysis to answer the question of where is my bandwidth going? then I would enable interface sampling on the internal interfaces of the SRX. If you’re looking for DDoS detection, I’d recommend creating stateless filters to sample incoming traffic on the firewall’s external-facing interfaces. However, like many topics in network security, finding a balance between available resources and visibility is up to your network’s throughput and bandwidth demands.

For today’s example, I’ll be configuring interface-based sampling on the internal interface of my firewall, a small network secured by a SRX300.

Configuring IPFIX Sampling

To begin, we’ll need to create a sampling template under the services hierarchy, and then configure forwarding-options to forward the IPFIX flows to a server.

Services Template

Below is an example of the services template this required for this step:

services {
    flow-monitoring {
        version-ipfix {
            template ipv4-template {
                ipv4-template;
            }
            template ipv6-template {
                ipv6-template;
            }
        }
    }
}

The commands are as follows:

set services flow-monitoring version-ipfix template ipv4-template ipv4-template
set services flow-monitoring version-ipfix template ipv6-template ipv6-template

All these two commands do is define a base template for IPv4 and IPv6 traffic using the IPFIX protocol. In a later post we may get into the some other tweaks such as the template-refresh-rate, but this will do for now.

Forwarding Options Configuration

Let’s see the configuration under forwarding-options:

forwarding-options {
    sampling {
        instance {
            s1 {
                input {
                    rate 100;
                }
                family inet {
                    output {
                        flow-server 10.200.15.6 {
                            port 2055;
                            version-ipfix {
                                template {
                                    ipv4-template;
                                }
                            }
                        }
                        inline-jflow {
                            source-address 10.200.15.1;
                        }
                    }
                }
                family inet6 {
                    output {
                        flow-server 10.200.15.6 {
                            port 2055;
                            version-ipfix {
                                template {
                                    ipv6-template;
                                }
                            }
                        }
                        inline-jflow {
                            source-address 10.200.15.1;
                        }
                    }
                }
            }
        }
    }
}

This configuration is a bit more involved, as we need to specify several parameters to proceed. One of the more major things to notice is that IPFIX should be configured under an instance instead of under the sampling hierarchy. Simply put, the configuration will not commit there as many of the needed input/output commands will be hidden or otherwise disabled!

Input Rate

First, let’s set the input rate:

set forwarding-options sampling instance s1 input rate 100

This means that SRX300 will sample 1 out of every 100 packets, which should be appropriate for our small network. The lower this number is, the more packets will be sampled, which can increase the CPU load of the SRX. Pay attention to the Routing Engine and Forwarding Engine CPU which experimenting with this number!

IPv4 Flow Export

From there let’s configure the server where we’ll send the sampled IPv4 flows:

set forwarding-options sampling instance s1 family inet output flow-server 10.200.15.6 port 2055
set forwarding-options sampling instance s1 family inet output flow-server 10.200.15.6 version-ipfix template ipv4-template
set forwarding-options sampling instance s1 family inet output inline-jflow source-address 10.200.15.1

By default most Netflow listeners use UDP port 2055, so that’s what is configured here. In the second command we specify version-ipfix to set the format to IPFIX, and reference the template created under the services hierarchy. Lastly, we’ll specify inline-jflow and the source-address of the SRX (in my case, I used the IP address of the TRUST interface, but a loopback address would suffice as well). This tells the SRX to use its inline sampling for exporting packets.

IPv6 Flow Export

set forwarding-options sampling instance s1 family inet6 output flow-server 10.200.15.6 port 2055
set forwarding-options sampling instance s1 family inet6 output flow-server 10.200.15.6 version-ipfix template ipv6-template
set forwarding-options sampling instance s1 family inet6 output inline-jflow source-address 10.200.15.1

The configuration for IPv6 is very similar; we reference family inet6 instead of family inet. You may have also noticed that the flow-server and inline-jflow source-address are still IPv4 hosts. This means that your flow analysis tools don’t need to speak IPv6 in order to sample IPv6 flows!

Interface Configuration

Let’s see the interface configuration of ge-0/0/1, which is the TRUST interface of the SRX300:

interfaces {
    ge-0/0/1 {
        mac 4c:16:fc:dd:d9:b0;
        unit 0 {
            family inet {
                sampling {
                    input;
                    output;
                }
                address 10.200.15.1/24;
            }
            family inet6 {
                sampling {
                    input;
                    output;
                }
                address 2001:470:1f1d:15d::1/64;
            }
        }
    }
}

The commands needed here are rather simple; just make sure to enable sampling under both family inet and family inet6!

set interfaces ge-0/0/1 unit 0 family inet sampling input
set interfaces ge-0/0/1 unit 0 family inet sampling output
set interfaces ge-0/0/1 unit 0 family inet6 sampling input
set interfaces ge-0/0/1 unit 0 family inet6 sampling output

In this instance, I’m sampling packets that are both coming into (input) and leaving (output) the interface. Depending on your requirements/scenario this may not be entirely necessary. If you’re looking to sample traffic for DDoS as an example, it would be best to limit this with a stateless firewall filter, and apply it to all interfaces that send/receive traffic as an input filter. This method saves precious firewall resources – which is critical if you’re experiencing a DDoS attack.

Now let’s commit the changes:

[edit]
root@gatekeeper# commit 
commit complete

Validation

Now let’s validate our configuration, by running through some accounting commands:

chaynes@gatekeeper> show services accounting status inline-jflow  
  Status information
    FPC Slot: 0
    IPV4 export format: Version-IPFIX, IPV6 export format: Version-IPFIX
    BRIDGE export format: Not set, MPLS export format: Not set
    IPv4 Route Record Count: 17, IPv6 Route Record Count: 9, MPLS Route Record Count: 0
    Route Record Count: 26, AS Record Count: 1
    Route-Records Set: Yes, Config Set: Yes
    Service Status: PFE-0: Steady 
    Using Extended Flow Memory?: PFE-0: No 
    Flex Flow Sizing ENABLED?: PFE-0: No 
    IPv4 MAX FLOW Count: 0, IPv6 MAX FLOW Count: 0
    BRIDGE MAX FLOW Count: 0, MPLS MAX FLOW Count: 0
    MAX supported Flow Table size: 0

chaynes@gatekeeper> show services accounting flow inline-jflow 
  Flow information
    FPC Slot: 0
    Flow Packets: 260, Flow Bytes: 95523
    Active Flows: 27, Total Flows: 226
    Flows Exported: 200, Flow Packets Exported: 368
    Flows Inactive Timed Out: 199, Flows Active Timed Out: 191
    Total Flow Insert Count: 0

    IPv4 Flows:
    IPv4 Flow Packets: 153, IPv4 Flow Bytes: 32301
    IPv4 Active Flows: 15, IPv4 Total Flows: 146
    IPv4 Flows Exported: 132, IPv4 Flow Packets exported: 240
    IPv4 Flows Inactive Timed Out: 131, IPv4 Flows Active Timed Out: 126
    IPv4 Flow Insert Count: 0

    IPv6 Flows:
    IPv6 Flow Packets: 107, IPv6 Flow Bytes: 63222
    IPv6 Active Flows: 12, IPv6 Total Flows: 80
    IPv6 Flows Exported: 68, IPv6 Flow Packets Exported: 128
    IPv6 Flows Inactive Timed Out: 68, IPv6 Flows Active Timed Out: 65
    IPv6 Flow Insert Count: 0

chaynes@gatekeeper> show services accounting errors inline-jflow 
  Error information
    FPC Slot: 0
    Flow Creation Failures: 0
    Route Record Lookup Failures: 0, AS Lookup Failures: 0
    Export Packet Failures: 0
    Memory Overload: No, Memory Alloc Fail Count: 0

    IPv4:
    IPv4 Flow Creation Failures: 0
    IPv4 Route Record Lookup Failures: 0, IPv4 AS Lookup Failures: 0
    IPv4 Export Packet Failures: 0

Since we’re using the inline-jflow method some commands may not work, such as:

• show services accounting usage
• show services accounting aggregation
• show services accounting flow-detail

Soon, I’ll put up a few examples of how we can use this data for traffic analysis. Please let me know in the comments if there are any particular tools you’d like to see!