Recently we were contacted by a customer who wanted to make sure that we had Viptela IPFIX support in our IPFIX collector. Viptela was recently acquired by Cisco and exports IPFIX as part of their Software Defined Wide Area Network (SD-WAN) strategy. If Cisco’s current SD-WAN technology called IWAN becomes end of life’d and replaced with the Viptela solution, customers should be aware that the Viptela IPFIX export is significantly different from the home grown Cisco IWAN (SD-WAN) export. By the way, IWAN is basically a rename of Cisco performance routing which we started supporting back in 2011. From our observation, the Viptela flow export is a step backwards from Cisco IWAN!
List of Viptela IPFIX Elements
Both of these SD-WAN exports work with our NetFlow Reporting system without issue. Below is a list of the IPFIX elements Viptela is exporting. Notice the first element VPN Id. It is the only enterprise specific element as the rest are all IANA industry standard.
| Info Element | Element ID | Description | Data Type | Semantics | Units |
|---|---|---|---|---|---|
| VPN Id | Enterprise | Viptela VPN identifier. Viptela uses the enterprise ID for VIP_IANA_ENUM or 41916, and the VPN element ID is 4321. | Unsigned32 | Identifier | 0-65535 |
| sourceIPv4Address | 8 | IPv4 source address in the IP packet header | Ipv4Address | Default | – |
| destinationIPv4Address | 12 | IPv4 destination address in the IP packet header | Ipv4Address | Default | – |
| ipDiffServCodePoint | 195 | Value of a Differentiated Services Code Point (DSCP) encoded in the Differentiated Services field. This field spans the most significant 6 bits of the IPv4 TOS field. | Unsigned8 | Identifier | 0-65535 |
| sourceTransportPort | 7 | Source port identifier in the transport header. For the transport protocols UDP, TCP, and SCTP, this is the destination port number given in the respective header. | Unsigned16 | identifier | – |
| destinationTransportPort | 11 | Destination port identifier in the transport header. For the transport protocols UDP, TCP, and SCTP, this is the destination port number given in the respective header. | Unsigned16 | identifier | – |
| protocolIdentifier | 4 | Value of the protocol number in the Protocol field of the IP packet header. The protocol number identifies the IP packet payload type. Protocol numbers are defined in the IANA Protocol Numbers registry. | Unsigned16 | Identifier | – |
| flowStartSeconds | 150 | Absolute timestamp of the first packet of this flow | dateTime-Seconds | – | – |
| flowEndSeconds | 151 | Absolute timestamp of the last packet of this flow. | dateTime-Seconds | – | – |
| octetTotalCount | 85 | Total number of octets in incoming packets for this flow at the observation point since initialization or re-initialization of the metering process for the observation point. The count includes the IP headers and IP payload. | Unsigned64 | totalCounter | Octets |
| octetDeltaCount | 1 | Number of octets since the previous report in incoming packets for this flow at the observation point. This number includes IP headers and IP payload. | Unsigned64 | deltaCounter | Octets |
| packetTotalCount | 86 | Total number of incoming packets for this flow at the observation point since initialization or re-initialization of the metering process for the observation point. | Unsigned64 | totalCounter | Packets |
| packetDeltaCount | 2 | Number of incoming packets since the previous report for this flow at this observation point. | Unsigned64 | deltaCounter | Packets |
| tcpControlBits | 6 | TCP control bits observed for the packets of this flow. This information is encoded as a bit field; each TCP control bit has a bit in this set. The bit is set to 1 if any observed packet of this flow has the corresponding TCP control bit set to 1. Otherwise, the bit is set to 0. For values of this field, see the IANA IPFIX web page. | Unsigned64 | – | Octets |
| maximumIpTotalLength | 26 | Length of the largest packet observed for this flow. The packet length includes the IP headers and IP payload. | Unsigned64 | – | Octets |
| minimumIpTotalLength | 25 | Length of the smallest packet observed for this flow. The packet length includes the IP headers and IP payload. | Unsigned64 | – | Octets |
| ipNextHopIPv4Address | 15 | IPv4 address of the next IPv4 hop. | IPv4Address | Default | – |
| egressInterface | 14 | Index of the IP interface where packets of this flow are being sent. | Unsigned32 | Default | – |
| ingressInterface | 10 | Index of the IP interface where packets of this flow are being received. | Unsigned32 | Identifier | – |
| icmpTypeCodeIPv4 | 32 | Type and Code of the IPv4 ICMP message. The combination of both values is reported as (ICMP type * 256) + ICMP code. | Unsigned16 | Identifier | – |
| flowEndReason | 136 | Reason for the flow termination. For values of this field, see the IANA IPFIX web page. | Unsigned8 | Identifier | – |
| ipClassOfService | 5 | Value of type of service (TOS) field in the IPv4 packet header. | Unsigned8 | Identifier | – |
| ipPrecedence | 196 | Value of IP precedence. This value is encoded in the first 3 bits of the IPv4 TOS field. | Unsigned8 | Identifier | – |
| paddingOctets | 210 | Value of this Information Element is always a sequence of 0x00 values. | octetArray | Default | – |
Flow End Reason
As pointed out in the post listing all of the competing SD-WAN vendors, what is missing from all of these flow exports is “when/why traffic is rerouted.” We noticed in the above table that Viptela is exporting the ‘flowEndReason.’ We need to dig into their export with some customers to ascertain whether or not they are exporting anything more than was is listed on the IANA web site:
| 0x01 | Idle Timeout | The Flow was terminated because it was considered to be idle. |
| 0x02 | Active Timeout | The Flow was terminated for reporting purposes while it was still active, for example, after the maximum lifetime of unreported Flows was reached. |
| 0x03 | End of Flow Detected | The Flow was terminated because the Metering Process detected signals indicating the end of the Flow, for example, the TCP FIN flag. |
| 0x04 | Forced End | The Flow was terminated because of some external event, for example, a shutdown of the Metering Process initiated by a network management application. |
| 0x05 | Lack of Resources | The Flow was terminated because of lack of resources available to the Metering Process and/or the Exporting Process. |
Certainly, there is some value in the above details when exported in IPFIX; however, in an SD-WAN environment, companies are going to need specific details on which applications the SD-WAN is rerouting. The Viptela exports are a far cry from the IWAN flow details. For example, customers will want to know things like:
| 0x06 | Jitter | Flow rerouted due to excessive jitter in VoIP transmissions |
| 0x07 | Packet Loss | Flow rerouted due to excessive packet loss in UDP connections |
| 0x08 | Retransmits | Flow rerouted due to excessive TCP retransmits |
| 0x09 | RTT | Flow rerouted due to excessive TCP setup times |
Application Aware would be Nice
In addition to the above, customers are going to want information regarding which applications were rerouted as not all applications are a priority. Something similar to Cisco NBAR2 would be ideal as relying on source/destination port to determine the application is not always reliable. Perhaps the Viptela element ‘VPN ID’ will provide some insight into this.
Lastly, customers are going to want to know where the flow was rerouted to and the IPFIX reporting system can provide insight into this. Contact our team to learn more about our Viptela IPFIX support. You can also read this post on SD-WAN Short Comings which goes into specific detail on what SD-WAN vendors need to export ether as IPFIX or maybe JSON if they want help customers understand what is going on in their SD-WAN.
Related
Advanced Silver Peak monitoring with IPFIX
Competition generally ends up being good for the consumer. It keeps prices down and forces innovation as vendors compete for market share. A great
::
