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.
![](//www.cisco.com/univercd/illus/images/note.gif) 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).
![](//www.cisco.com/univercd/illus/images/note.gif) 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.