Details

Data templates Non-NAT Template (ID:256) https://www.iana.org/assignments/ipfix/ipfix.xhtmlThis is an aggregated flow. Keys for this flow record are: sourceIPv4Addres, destinationIPv4Address, destinationTransportPort, ingressVRFID, ApplicationID, protocolIdentifier. Source port is aggregated out. Template ID: 256Enterprise-Specific Fields (ID:32767) VeloCloud IANA-PEN: 45346 NAT Template (ID:259) Common + NAT template Template ID: 259 Notes:• Netflow exports are unidirectional flows. VeloCloud needs to export flow stats as two flow records or implement RFC5103 (Bidirectional Flow Export).• flowID will need to be constructed to be unique within the Enterprise.• LAN Side NAT: – Consider a flow which comes from a LAN client with IP 10.0.1.25 and destination 10.0.2.25. LAN side NAT is configured to SNAT source IP to 192.168.1.1. So, the flow record for this flow will be with SIP: 192.168.1.1 and DIP: 10.0.2.25. Flow Link Stats Template (ID:257) Flow stats broken down by link Template ID: 257Tunnel Stats Template (ID: 258) Sent every 1 minuteA tunnel is established over a link and has communication with a peer. A peer can be a Gateway (Edge to Cloud traffic), Hub (Edge to data center traffic) or Edge (dynamic Edge-to-Edge VPN traffic). The template below captures the stats of a tunnel. The “linkUUID” field lists the link established for the tunnel. The “interfaceIndex” field says to which peer it is communicating.Difference between tunnel and path:Path is a unidirectional entity and tunnel is bi-directional. TX and RX paths make up a tunnel.Note:1. Only connected tunnels will be exported. If a tunnel goes DEAD, this tunnel’s stats will not be exported from the next export interval. For example: if the tunnel stats template export interval is 300 seconds and the tunnel was exported at time t1 and the tunnel goes down at t1+100. Stats between (t1 and t1+100) will be exported at t1+300. And from the next interval, this tunnel’s stats will not be exported since the tunnel has gone DEAD.2. Number of tunnels down events will be exported as part of tunnel stats template.3. Formula for Loss computation: TX Loss Percent = ((packetsLostDeltaTxCount) / (packetsLostDeltaTxCount + packetsLostCompDeltaTxCount)) * 100RX Loss Percent = ((packetsLostDeltaRxCount) / (packetsLostDeltaRxCount + packetsLostCompDeltaRxCount)) * 100 Optional Templates Application Option Template (ID: 271) Reference: RFC 6759 Sent every 5 min or when changed. Only applications that have been referenced in flows are exported.ApplicationId format0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 20 | enterprise ID = 45346 ...|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|...Ent.ID.contd| app ID |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Classification Engine ID: 20 (PANA-L7-PEN) Proprietary layer 7 definition, including a Private Enterprise Number (PEN) [IANA-PEN] to identify that the application registry being used is not owned by the exporter manufacturer or to identify the original enterprise in the case of a mediator or third-party device. The Selector ID represents the enterprise unique global ID for the layer 7 applications. The Selector ID has a global significance for all devices from the same enterprise.• 45346 Is VMware SD-WAN PEN• App ID is internal application ID Interface Option Template (ID: 272) Interfaces in the VMware SD-WAN NetFlow context can be broadly classified into two types: 1. Physical – These are Ethernet (e.g. GE1, GE2), VLAN (e.g. br-network1), or IP interfaces (e.g. PPPoE or some USB modem interfaces). 2. SD-WAN – These are point-to-point interfaces between a pair of VMware SD-WAN devices. On the overlay there may be several tunnels between a pair of VMware SD-WAN devices. These tunnels use a proprietary protocol called VCMP that provides several features including encryption, retransmission, and more. The tunnels between two devices may be always present or may be created on-demand depending on the configuration. The end points of these tunnels are called “links” in VMware SD-WAN terminology. Typically, there is a "link" for each physical WAN-facing interface on an Edge. The diagram below depicts the relationship between physical/SD-WAN interfaces, links and tunnels. On both the nodes below, GE1, GE2 and GE3 are physical interfaces. GE1 and GE2 are WAN-side interfaces and have links defined over them. In contrast, GE3 is a LAN-side interface and thus does not have a link defined over it. Tunnels are formed between links on each node. The Node1-Node2 SD-WAN interface is the overlay interface on which traffic may be sent from Node1 to Node2. When traffic is sent on the Node1-Node2 SD-WAN interface, the individual packets may be either: Replicated on both the tunnels.Load-balanced between the two tunnels.Sent on only one tunnel. The treatment of the packets depends on the type of traffic, configuration, and network conditions. The interface option template (ID: 272) is sent every 5 min by default. The timer is configurable. SD-WAN segment ID to segment mapping template (ID: 273) The template below is sent every 10 min and utilizes VRF as the nomenclature to define a segment. Link Option Template (ID: 276) Sent every 5 minutesThe link option template provides a mapping between linkUUID and the interface index to which this link points. From the link option template, it is also possible to get the link name which is a configurable field in the VMware SD-WAN Orchestrator. NetFlow Source Address & Segmentation NetFlow source interface’s primary IP address should come from VMware SD-WAN Orchestrator. In the absence of the optional source interface configuration, the flow records would consume the management IP address as the source IP address for all segments. The Orchestrator UI needs to be modified to reflect this.When multiple Netflow exporting processes originate from the same IP, NetFlow provides the information element to ensure the uniqueness of the export. The options are: • Use different source interface for each segment.• If we consider segments distinct exporting processes, then use observation DomainId to distinguish between segments. Interface Mappings Interface numbering: 32-bit number (RFC2863). Ingress or egress is defined by source/destination route in flow container. Interface index is derived from route type and destination system ID or interface for direct traffic. The same mapping must be used for SNMPinterface table (ifTable - RFC1213).0..7 0..7 0..16destination_type reserved destination_if_idxdestination_type: • E2E• E2DC• CLOUD• ANY/DIRECT destination_if_idx • E2E, E2DC, CLOUD: map(next_hop_id) -> if_idx• ANY/DIRECT: map(link_logical_id) -> if_idx Filtering Allow NetFlow to be filtered by: • ingressVRFID (or all segments)• ApplicationID• sourceIPv4Address (mask)• destinationIPv4Address (mask)• protocolIdentifier Appendix A IPFIX Information element definitions: