Anuket Project

  • Created by Unknown User (maryamtahhan), last modified on Jan 29, 2018

MIB support Requirements

Implement infrastructure in Open vSwitch with DPDK to allow for:

  • Exposing Information about the interfaces bound to OVS with DPDK.
  • Exposing the Stats relevant to the MIBs below for both virtual and physical interfaces (where applicable), as well as on the flow level (where applicable)
  • Exposing Link Status per interface for OVS with DPDK Interfaces (both physical and virtual).
  • Exposing Interface information - such as Link Speed, MTU... as listed by the table in the requirements section.
  • Ensure Alignment where possible for all exposed registers in terms of naming or ids.
  • A mechanism for enabling and disabling of monitoring of interface.

Networking MIBs to be supported (IF supported by the virtual switch) where possible:

PriorityMIB NameRFCDescriptionFields of interest
 IF-MIBRFC2863Network interface sub-layersInterfaceIndex, ifIndex,InterfaceIndexOrZero,ifTableLastChange, ifNumber, ifTable, ifDescr, ifType, ifMtu, ifSpeed, ifPhysAddress, ifAdminStatus, ifOperStatus, ifLastChange, ifInOctets, ifInUcastPkts, ifInDiscards, ifInErrors, ifInUnknownProtos, ifOutOctets, ifOutUcastPkts, ifOutNUcastPkts, ifOutDiscards, ifOutErrors, ifName, ifInMulticastPkts, ifInBroadcastPkts, ifOutMulticastPkts, ifOutBroadcastPkts, ifHCInOctets, ifHCInUcastPkts, ifHCInMulticastPkts, ifHCInBroadcastPkts, ifHCOutOctets, ifHCOutUcastPkts, ifHCOutMulticastPkts, ifHCOutBroadcastPkts, ifLinkUpDownTrapEnable, ifHighSpeed, ifPromiscuousMode, ifConnectorPresent, ifAlias, ifCounterDiscontinuityTime, ifStackEntry, ifRcvAddressTable, ifRcvAddressEntry, 
*NOTE1*: use the High Capacity variations of the stats registers where appropriate. 
*NOTE2*: trap support to be defined
*NOTE3* – The groups:
  • ifFixedLengthGroup
  • ifHCFixedLengthGroup
  • ifPacketGroup
  • ifHCPacketGroup
  • ifVHCPacketGroup
    are mutually exclusive; at most one of these groups is implemented for a particular interface. When any of these groups is implemented for a particular interface, then ifCounterDiscontinuityGroup must also be implemented for that interface.
 EtherLike-MIBRFC3635Ethernet like network interfacesifRcvAddressTable, ifType, ifXxxOctets,ifXxxcastPkts, ifMtu, ifSpeed, ifHighSpeed, ifPhysAddress, Specific Interface MIB Objects
 IP-MIBRFC4293IP and ICMP without routing infoIP Statistics Tables, ICMP Statistics Tables
 IP-FORWARD_MIBRFC4292CIDR multipath IP routes
 TCP-MIBRFC4022TCP stack counters and info
 UDP-MIBRFC4133UDP counters and info
 IPV6 MIBsRFC2465 RFC2466 RFC2452 RFC2454IPv6 equivalentsIpv6IfIcmpEntries, ipv6IcmpGroup
 SCTP-MIBRFC3873SCTP protocol

Other Stats and information to be supported by OVS with DPDK where possible:

  • Interface aggregate and peak bitrate over a configurable period of time.
  • Statistical Latency for packets
  • Link Status per interface

Functional Requirements :

  • Stats support and exposure for physical and virtual interfaces.
  • Last cleared time for statistics, average bit rate should also be exposed if supported by the vswitch.
  • period of time to aggregate bitrate should be configurable if supported by the vswitch.
  • Integration with the relevant OVS application/utility to expose statistics.
  • A mechanism for retrieving Link Status per interface

Deliverables

 

1. MIB information exposed for physical and virtual interfaces

  • Description: MIBs exposed for physical and virtual interfaces

2. Link Status exposed for physical and virtual interfaces

  • Description: Link Status exposed for physical and virtual interfaces

 

IPFIX Requirements

Provisioning and Monitoring with Flow Telemetry, Reporting of flow telemetry via IPFIX as per RFC. The standard below the minimum counters that needs to be exposed.

https://tools.ietf.org/html/rfc3917

  • Flow Counters/statistics used in IPFIX reports are defined in RFC 5102, section 5.10/5.11 page 70-80 this is a MIN.
  • Assume any "method" can be used for this.

 

All IPFix sampling has been implemented using OVS upcall mechanism. Based on the exporter configuration described in above “User guide”, certain number of packets are sampled through upcall execution. Each packet which “has been chosen” to be sampled is analyzed, and based on its content proper counters/data fields in IPFix interface are calculated. Majority of implementation takes place in ofproto/ofproto-dpif-ipfix.c and  ofproto/ofproto-dpif-ipfix.h.

 

IPFIX – templates

IPFIX exporter/measurement engine upon connection to IPFix collector needs to send a data structure which is called – “IPFIX template”. Such template is literally set of data (counters) which will be sent to collector. If any new counter will have to be added in IPFix in OVS, existing template needs to be extended. Current templates are defined in:

 

static uint16_t

ipfix_define_template_fields(enum ipfix_proto_l2 l2, enum ipfix_proto_l3 l3,

   enum ipfix_proto_l4 l4,
   enum ipfix_proto_tunnel tunnel,

                             bool virtual_obs_id_set,

                             struct dp_packet *msg)

IPFIX – data collection

 

General rule is that measurement process implemented in ofproto/ofproto-dpif-ipfix.c and  ofproto/ofproto-dpif-ipfix.h, receives packets from upcall mechanism based on defined sampling rule (explained above). 

This packet then is parsed and all relevant IPFIX counters are updated:

 

ipfix_cache_entry_init(struct ipfix_flow_cache_entry *entry,

                       const struct dp_packet *packet, const struct flow *flow,

                       uint64_t packet_delta_count, uint32_t obs_domain_id,

                       uint32_t obs_point_id, odp_port_t output_odp_port,

                       enum nx_action_sample_direction direction,

                       const struct dpif_ipfix_port *tunnel_port,

                       const struct flow_tnl *tunnel_key,

                       struct dpif_ipfix_global_stats *stats)

 

Sometimes additional information is needed, and thus some basic interface is used between measurement process and netdev to provide it.

Next step, if there are any other messages pending, those will be aggregated into single message:

 

ipfix_cache_aggregate_entries(struct ipfix_flow_cache_entry *from_entry,

                              struct ipfix_flow_cache_entry *to_entry)

 

Collected data is than sent by “Exporter process” to the IPFix collector. Message creation is handled by following function:

 

static void

ipfix_put_data_set(uint32_t export_time_sec,

                   struct ipfix_flow_cache_entry *entry,

                   enum ipfix_flow_end_reason flow_end_reason,

                   const char *virtual_obs_id,

                   uint8_t virtual_obs_len,

                   struct dp_packet *msg)

 

 

IPFIX – adding new counters.

If new counter will have to be added to IPFix measurement process, it is mandatory to:

  • Update template
  • Update parsing of the packet through “ipfix_cache_entry_init”.
  • Update aggregation function “ipfix_cache_aggregate_entries”.
  • Update sending function “ipfix_put_data_set”.

 

 

PATCH summary

 


List of implemented counters for IPFIX

Counter name

Link

Upstreamed

Commit ID

octetDeltaCount
octetDeltaSumOfSquares
octetTotalCount
octetTotalSumOfSquares
packetDeltaCount
packetTotalCount

 

 

https://patchwork.ozlabs.org/patch/752829/

 

 

 

Y

fe520682421dd361fa33afb9f48a525daa1501ed

droppedOctetDeltaCount
droppedPacketDeltaCount
droppedOctetTotalCount
droppedPacketTotalCount

 

https://patchwork.ozlabs.org/patch/775166/

https://patchwork.ozlabs.org/patch/788373/

 

Y

564230b6c982fc5b6df06b139a938edce874a5f7

postMCastPacketDeltaCount
postMCastOctetDeltaCount
postMCastPacketTotalCount
postMCastOctetTotalCount

 

https://patchwork.ozlabs.org/patch/780701/

Y

ebfe9a219027dc88f7fa36fc550ff0fa03922211

tcpSynTotalCount
tcpFinTotalCount
tcpRstTotalCount
tcpPshTotalCount
tcpAckTotalCount
tcpUrgTotalCount

 

 

https://patchwork.ozlabs.org/patch/761013/

Y

0b4f83e2dce44625daa56983c34ccd14a32bf762

 

List of implemented counters for MIBs support

Counters

Link/Comment

Upstreamed

Commit ID

octetTotalCount

droppedPacketTotalCount

Implemented through MSP-5822

Y

fe520682421dd361fa33afb9f48a525daa1501ed

ingressUnicastPacketTotalCount
egressUnicastPacketTotalCount
ingressBroadcastPacketTotalCount
egressBroadcastPacketTotalCount

ingressMulticastPacketTotalCount

 

https://patchwork.ozlabs.org/patch/780701/

Y

ebfe9a219027dc88f7fa36fc550ff0fa03922211

notSentPacketTotalCount

https://patchwork.ozlabs.org/patch/784630/

Y

d564c4bb536985acb246b9c4a72a0b1af2f9ede7

interfaceName
ingressInterface
egressInterface

ifDescr
ifType

 

https://patchwork.ozlabs.org/patch/837802/

https://patchwork.ozlabs.org/patch/837803/

N

 

 

 

List of Counters which are not implemented

ifOutErrors

There was no proper mapping found in IPFIX.

ifHCOutOctets

64bit: the total number of octets transmitted out of the interface - mapped to IPFIX postOctetTotalCount.
First of all there is no clear way to map outgoing packets from interface on IPFIX sampling level. In fact it not possible to do. Sampling mechanism is not aware of any interface specific data, thus counter which can be mapped to ifHCOutOctets doesn't exist. When initial mapping was done, it was assumed that post counter would describe data which we need, however its definition, is entirely different:

The definition of this Information Element is identical to the definition of Information Element 'octetTotalCount', except that it reports a potentially modified value caused by a middlebox function after the packet passed the Observation Point.


Middlebox is any function that can potentially change the packet, so in practice this could be for example: NAT. When packet leaves middlebox function and passes observation point, it is still not determined that packet will reach output port, and will be send out from the interface. This counter was meant to describe totally different information, and it is not connected with outgoing octets from interface.

 

 

Summary

 

“Have any known limitations been documented? (interoperability issues, additional work not planned, etc…)”
There are no limitations.

“Have all known dependencies been documented? “
There are no additional dependencies.

“Have all known bugs been addressed for plugin?”
No bugs have been reported. All the problems were solved during implementation and integration phase.

“Have all TODOs been closed?”
No pending TODOs are left. 

 

  • No labels