Prior to the introduction of the NetFlow Reliable Export With SCTP feature in Cisco IOS Release 12.4(4)T exporting NetFlow
information was unreliable because NetFlow encapsulated the exported traffic in UDP packets for transmission to the NFC. Using
an unreliable transport protocol such as UDP for sending information across a network has two major disadvantages:
-
Lack of congestion awareness--The exporter sends packets as fast as it can generate them, without any regard to the bandwidth
available on the network. If the link is fully congested when the NetFlow router attempts to send, the packet might simply
be dropped, either before it is put on the exporter’s output queue or before it gets to the next hop's input queue.
-
Lack of reliability--With export over UDP, the collector has no method of signaling to the exporter that it didn't receive
an exported packet. Most versions of NetFlow export packet contain a sequence number, so the collector often knows when it
has lost a packet. But given that the exporter discards the export packet as soon as it has been sent and that the NetFlow
router lacks a mechanism to request a retransmission of the packet, exporting over UDP can be considered to be unreliable
The NetFlow Reliable Export With SCTP feature uses the SCTP to overcome the two major disadvantages of using UDP as the transport
layer protocol:
-
SCTP has a congestion control mechanism to ensure that the router does not send data to the collector faster than it can
receive it.
-
SCTP transmits messages in a reliable manner. SCTP messages are buffered on the router until they have been acknowledged
by the collector. Messages that are not acknowledged by the collector are retransmitted by the router.
SCTP is a reliable message-oriented transport layer protocol, which allows data to be transmitted between two end-points
in a reliable, partially reliable, or unreliable manner. An SCTP session consists of an association between two end-points,
which may contain one or more logical channels called streams. SCTP’s stream based transmission model facilitates the export
of a mix of different data types, such as NetFlow templates and NetFlow data, over the same connection. The maximum number
of inbound and outbound streams supported by an end-point is negotiated during the SCTP association initialization process.
When you configure the NetFlow Version 9 Export and NetFlow Reliable Export features, NetFlow creates a minimum of two streams--stream
0 for templates and options, and one or more streams for carrying data, as required. The following commands are not applicable
when you configure the NetFlow Version 9 Export and NetFlow Reliable Export features together because NetFlow Reliable Export
export connections use SCTP reliable stream 0 for NetFlow Version 9 Export, and these commands apply only to NetFlow export
connections that use UDP:
-
ip
flow-export
template
refresh-rate
-
ip
flow-export
template
timeout-rate
-
ip
flow-export
template
options
refresh-rate
-
ip
flow-export
template
options
timeout-rate
When more than one cache (main cache and one or more aggregation caches) is exporting data, each cache creates its own streams
with their own configured reliability levels. For example, you can configure the main cache to use SCTP in full reliability
mode and the NetFlow prefix aggregation cache to use partial reliability mode to send messages to the same collector using
the same SCTP port.

Note
|
When you are using SCTP as the transport protocol for exporting NetFlow traffic, the traffic is usually referred to as messages
instead of datagrams because SCTP is a message-oriented protocol. When you are using UDP as the transport protocol for exporting
NetFlow traffic, the traffic is usually referred to as datagrams because UDP is a datagram-oriented protocol.
|
Security
SCTP contains several built-in features to counter many common security threats such as the syn-flood type of DoS attack.
SCTP uses the following techniques to resist flooding attacks:
-
A four-way start-up handshake is used to ensure that anyone opening an association is a genuine caller, rather the someone
performing a 'syn-flood' type of DoS attack.
-
Cookies are used to defer commitment of resources at the responding SCTP node until the handshake is completed.
-
Verification Tags are used to prevent insertion of extraneous packets into the flow of an established association.
Reliability Options
SCTP allows data to be transmitted between two end-points (a router running NetFlow SCTP export and a collector that is receiving
and acknowledging the SCTP messages) in a reliable manner. In addition to the default behavior of full reliability, SCTP can
be configured for partially-reliable or unreliable transmission for applications that do not require full reliability.
When SCTP is operating in full reliability mode, it uses a selective-acknowledgment scheme to guarantee the ordered delivery
of messages. The SCTP protocol stack buffers messages until their receipt has been acknowledged by the receiving end-point.
(collector). SCTP has a congestion control mechanism that can be used to limit how much memory is consumed by SCTP for buffering
packets.
If a stream is specified as unreliable, then the packet is simply sent once and not buffered on the exporter. If the packet
is lost enroute to the receiver, the exporter cannot retransmit it.
When a stream is specified as partially-reliable a limit is placed on how much memory should be dedicated to storing un-acknowledged
packets. The limit on how much memory should be dedicated to storing unacknowledged packets is configurable by means of the
buffer-limit
limit command. If the limit on how much memory should be dedicated to storing unacknowledged packets is exceeded and the router
attempts to buffer another packet, the oldest unacknowledged packet is discarded. When SCTP discards the oldest unacknowledged
packet, a message called a forward-tsn (transmit sequence number) is sent to the collector to indicate that this packet will
not be received. This prevents NetFlow from consuming all the free memory on a router when a situation has arisen which requires
many packets to be buffered, for example when SCTP is experiencing long response times from an SCTP peer connection.
When SCTP is operating in partially reliable mode, the limit on how much memory should be dedicated to storing un-acknowledged
packets should initially be set as high as possible. The limit can be reduced if other processes on the router begin to run
out of memory. Deciding on the best value for the limit involves a trade-off between avoiding starving other processes of
the memory that they require to operate and dropping SCTP messages that have not been acknowledged by the collector.
Unreliable SCTP can be used when the collector that you are using doesn’t support UDP as a transport protocol for receiving
NetFlow export datagrams and you do not want to allocate the resources on your router required to provide reliable, or partially
reliable, SCTP connections.
Congestion Avoidance
SCTP uses congestion avoidance algorithms that are similar to those for TCP. An SCTP end-point advertises the size of its
receive window (rWnd) to ensure that a sender cannot flood it with more messages than it can store in its input queues.
Each SCTP sender also maintains a congestion window (cWnd), which determines the number of unacknowledged packets that can
be outstanding at a given time. SCTP uses the same 'slow-start' algorithm as TCP, in which it starts with a small cWnd and
gradually increases it until it reaches its optimum size.
Whenever a packet isn't acknowledged within the given timeout period, the value of cWnd is halved. This method of congestion
avoidance is known as added increase / multiplicative decrease and has been shown to be the most effective congestion avoidance
algorithm in most circumstances.
SCTP also employs the fast-retransmit algorithm whereby it retransmits a message if it receives acknowledgments from four
messages which were sent after the message in question. This is preferable to waiting for the timeout period to elapse and
triggering a retransmit of the message.
Options for Backup Collectors
You can configure a backup collector for SCTP. It is used as a message destination in the event that the primary collector
becomes unavailable. When connectivity with the primary collector has been lost, and a backup collector is configured, SCTP
begins using the backup collector. The default period of time that SCTP waits until it starts using the backup collector is
25 milliseconds (msec). You can configure a different value for interval with the
fail-over
time command.
The router sends periodic SCTP heartbeat messages to the SCTP collectors that you have configured. The router uses the SCTP
heartbeat message acknowledgements from the collectors to monitor the status of each collector. This allows an application,
such as NetFlow, to be quickly informed when connectivity to a collector is lost.
You can configure SCTP backup in fail-over or redundant mode. When the router is configured with SCTP backup in fail-over
mode, the router waits to activate the association with the backup collector until the router has not received acknowledgements
for the SCTP heartbeat messages from the primary collector for the time specified by the
fail-over
time command (or the default of 25 msec if this parameter has not been modified).

Note
|
SCTP retransmits messages that have not been acknowledged three times. The router will initiate fail-over after three retransmissions
of the same message are not acknowledged by the primary collector.
|
When the router is configured with SCTP backup in redundant mode, the router activates the association with the backup collector
immediately, and if NetFlow v9 export is configured the router sends the (options) templates in advance. The router will not
start sending other SCTP messages to a backup collector in redundant mode until the router has not received acknowledgments
for the SCTP heartbeat messages from the primary collector for the time specified by the
fail-over
time command. Fail-over mode is the preferred method when the backup collector is on the end of an expensive lower-bandwidth link
such as ISDN.
During the time that SCTP is using the backup collector, SCTP continues to try to restore the association with the primary
collector. This goes on until connectivity is restored or the primary SCTP collector is removed from the configuration.
When connectivity to the primary collector is available again, the router waits for a period of time before reverting to
using it as the primary destination. You configure the value of the period of time that SCTP waits until reverting to the
primary collector with the
restore-time
time command. The default period of time that SCTP waits until it reverts to the primary collector is 25 sec.
Under either fail-over mode any records which have been queued between losing connectivity with the primary destination and
establishing the association with the backup collector might be lost. A count is maintained of how many records were lost.
It can be viewed with the
show
ip
flow
export
sctp
verbose command.
To avoid a flapping SCTP association with a collector (the SCTP association goes up and down in quick succession), the time
period configured with the
restore-time
time command should be greater than the period of a typical connectivity problem. For example, your router is configured to use
IP fast convergence for its routing table and you have a LAN interface that is going up and down repeatedly (flapping). That
causes the IP route to the primary collector to be added and removed from the routing table repeatedly (route flapping) every
2000 msec (2 sec). you need to configure the restore time for a value greater than 2000 msecs.
The backup connection uses stream 0 for sending templates, options templates, and option data record. The data stream(s)
inherit the reliability settings of the primary connection.
Export to Multiple Collectors
You can configure your networking device to export NetFlow data to a maximum of two export destinations (collectors) per
cache (main and aggregation caches), using any combination of UDP and SCTP. A destination is identified by a unique combination
of hostname or IP address and port number or port type. The table below shows examples of permitted multiple NetFlow export
destinations for each cache.
Table 1. Examples of Permitted Multiple NetFlow Export Destinations for Each Cache
First Export Destination
|
Second Export Destination
|
ip
flow-export
10.25.89.32
100
udp
|
ip
flow-export
10.25.89.32
285
udp
|
ip
flow-export
10.25.89.32
100
udp
|
ip
flow-export
172.16.89.32
100
udp
|
ip
flow-export
10.25.89.32
100
udp
|
ip
flow-export
172.16.89.32
285
udp
|
ip
flow-export
10.25.89.32
100
udp
|
ip
flow-export
10.25.89.32
100
sctp
|
ip
flow-export
10.25.89.32
100
sctp
|
ip
flow-export
10.25.89.32
285
sctp
|
ip
flow-export
10.25.89.32
100
sctp
|
ip
flow-export
172.16.89.32
100
sctp
|
ip
flow-export
10.25.89.32
100
sctp
|
ip
flow-export
172.16.89.32
285
sctp
|
The most common use of the multiple-destination feature is to send the NetFlow cache entries to two different destinations
for redundancy. Therefore, in most cases the second destination IP address is not the same as the first IP address. The port
numbers can be the same when you are configuring two unique destination IP addresses. If you want to configure both instances
of the command to use the same destination IP address, you must use unique port numbers. You receive a warning message when
you configure the two instances of the command with the same IP address. The warning message is, "%Warning: Second destination
address is the same as previous address <ip-address>".
SCTP Support For Export Formats
SCTP based reliable transport is available for all NetFlow export formats: Versions 1, 5, 8 and 9.