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 ElementElement IDDescriptionData TypeSemanticsUnits
VPN IdEnterpriseViptela VPN identifier. Viptela uses the enterprise ID for VIP_IANA_ENUM or 41916, and the VPN element ID is 4321.Unsigned32Identifier0-65535
sourceIPv4Address8IPv4 source address in the IP packet headerIpv4AddressDefault
destinationIPv4Address12IPv4 destination address in the IP packet headerIpv4AddressDefault
ipDiffServCodePoint195Value 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.Unsigned8Identifier0-65535
sourceTransportPort7Source 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.Unsigned16identifier
destinationTransportPort11Destination 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.Unsigned16identifier
protocolIdentifier4Value 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.Unsigned16Identifier
flowStartSeconds150Absolute timestamp of the first packet of this flowdateTime-Seconds
flowEndSeconds151Absolute timestamp of the last packet of this flow.dateTime-Seconds
octetTotalCount85Total 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.Unsigned64totalCounterOctets
octetDeltaCount1Number of octets since the previous report in incoming packets for this flow at the observation point. This number includes IP headers and IP payload.Unsigned64deltaCounterOctets
packetTotalCount86Total number of incoming packets for this flow at the observation point since initialization or re-initialization of the metering process for the observation point.Unsigned64totalCounterPackets
packetDeltaCount2Number of incoming packets since the previous report for this flow at this observation point.Unsigned64deltaCounterPackets
tcpControlBits6TCP 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.Unsigned64Octets
maximumIpTotalLength26Length of the largest packet observed for this flow. The packet length includes the IP headers and IP payload.Unsigned64Octets
minimumIpTotalLength25Length of the smallest packet observed for this flow. The packet length includes the IP headers and IP payload.Unsigned64Octets
ipNextHopIPv4Address15IPv4 address of the next IPv4 hop.IPv4AddressDefault
egressInterface14Index of the IP interface where packets of this flow are being sent.Unsigned32Default
ingressInterface10Index of the IP interface where packets of this flow are being received.Unsigned32Identifier
icmpTypeCodeIPv432Type and Code of the IPv4 ICMP message. The combination of both values is reported as (ICMP type * 256) + ICMP code.Unsigned16Identifier
flowEndReason136Reason for the flow termination. For values of this field, see the IANA IPFIX web page.Unsigned8Identifier
ipClassOfService5Value of type of service (TOS) field in the IPv4 packet header.Unsigned8Identifier
ipPrecedence196Value of IP precedence. This value is encoded in the first 3 bits of the IPv4 TOS field.Unsigned8Identifier
paddingOctets210Value of this Information Element is always a sequence of 0x00 values.octetArrayDefault

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:

0x01Idle TimeoutThe Flow was terminated because it was considered to be idle.
0x02Active TimeoutThe Flow was terminated for reporting purposes while it was still active, for example, after the maximum lifetime of unreported Flows was reached.
0x03End of Flow DetectedThe Flow was terminated because the Metering Process detected signals indicating the end of the Flow, for example, the TCP FIN flag.
0x04Forced EndThe Flow was terminated because of some external event, for example, a shutdown of the Metering Process initiated by a network management application.
0x05Lack of ResourcesThe 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:

0x06JitterFlow rerouted due to excessive jitter in VoIP transmissions
0x07Packet LossFlow rerouted due to excessive packet loss in UDP connections
0x08RetransmitsFlow rerouted due to excessive TCP retransmits
0x09RTTFlow 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