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!

Viptela IPFIX Support

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.

James Lawrence

James Lawrence

I currently live in Kennebunk, Maine with my wife and 3 children. When I am not working and going to school full time, I enjoy fishing, camping, and playing video games with my oldest son. I do enjoy working outside and gardening is one of my favorite things to do in the seasons that allow it.

Related