Support for SNMPv2C Packet Header (Data Plane Only)

[biplamal]

Redocly View:
ReDoc Interactive Demo (redocly.github.io)
( New object at : set_config/flows/packet/snmpv2c )

SNMPv2-RFC3416
SNMPv2C-RFC1901
SNMP-TCP-Guide
SNMP-OID-Encoding-Example

Requirement:
The user able to define SNMPv2C data plane packet headers. Purpose is to flood DUT with SNMPv2C request and responses. The user should be able to configure different fields in PDU with ability to specify Increment/Decrement operations on certain applicable fields in the specified PDU.

Example usage:

f1 := config.Flows().Items()[0]
f1.SetName("f1:p1->p2").
TxRx().Port().SetTxName(p1.Name()).SetRxName(p2.Name())

f1.Duration().FixedPackets().SetPackets(100)
f1.Rate().SetPps(10)

f1.Packet().Add().Ethernet()
f1.Packet().Add().Ipv4()
f1.Packet().Add().Tcp()

// sample SNMPv2C get-request
SNMPv2C_1 := f1.Packet().Add().Snmpv2c()
SNMPv2C_1.SetCommunity("abc")
SNMPv2CGetReq := SNMPv2C_1.Data().GetRequest()
SNMPv2CGetReq .RequestId().SetValues([]uint32{1, 2})
varBind1 := SNMPv2CGetReq .VariableBindings().Add()
varBind1.SetObjectIdentifier([]uint64{1, 0, 8802, 1, 1, 1, 1, 1, 1, 0})

varBind2 := SNMPv2CGetReq .VariableBindings().Add()
varBind2.SetObjectIdentifier([]uint64{1, 0, 200, 1, 1, 1, 1, 1, 1, 0})

// sample SNMPv2C response
SNMPv2C_2 := f1.Packet().Add().Snmpv2c()
SNMPv2C_2.SetCommunity("abc")
SNMPv2CResp := SNMPv2C_2 .Data().Response()
SNMPv2CResp .RequestId().SetValues([]uint32{1, 2})
varBind1 := SNMPv2CResp.VariableBindings().Add()
varBind1.SetObjectIdentifier([]uint64{1, 0, 8802, 1, 1, 1, 1, 1, 1, 0})
varBind1.Value().Timeticks().Increment().SetStart(20).SetStep(2)

varBind2 := SNMPv2CResp.VariableBindings().Add()
varBind2.SetObjectIdentifier([]uint64{1, 0, 200, 1, 1, 1, 1, 1, 1, 0})
varBind2.Value().Counter().Decrement().SetStart(100).SetStep(1)

[apratimmukherjee]

Initial review.

[ashutshkumr]

Can't we accept object identifier as string ?

The reason being, if we were to accept array of uint64 as input, it would complicate how multiple values will be provided.

e.g. "1.0.8802.1.1.1.1.1.1.0" vs []uint64{1, 0, 8802, 1, 1, 1, 1, 1, 1, 0}

This would also be consistent with how we accept IP or MAC address today. Going forward, in models, oid would be another x-pattern (alongside ipv4, ipv6 and mac)

[alakendu]

According to SNMPv2-RFC3416 supported ApplicationSyntax are

   ApplicationSyntax ::= CHOICE {
         ipAddress-value        IpAddress,
         counter-value          Counter32,
         timeticks-value        TimeTicks,
         arbitrary-value        Opaque,
         big-counter-value      Counter64,
         unsigned-integer-value Unsigned32 }

SNMP Data Type is supporting single IP type (IpAddress) with SIZE (4)

IpAddress ::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4))

So, I am suspecting RFC talked about for IPv4 address NOT IPv6 address. Because if this is IPv6 then what is the length of it.

Could you please double check it otherwise we have to remove IPv6.

[alakendu]

We are proving OTG data type (e,g, <int32>, <uint32>, <string> etc) within all SNMP property. But those data types are not one-to-one mapping with ASN.1 type. say

• community and error_status are string but those are different ASN.1 type (which are 0x04 and 0x02)
• Same also true for request_id and integer_value, both are int32 with different ASN.1 type (0x02 and 0x41)

Yes, I agree this is not a goal for OTG model perspective. So, I am thinking it will better to mentioned what is the ANS.1 type for each field within description. It will reduced ramp-up and anomality at the time to developing SNMP protocol.

[ashutshkumr]

The value suffix in all the properties and choices inside variable binding seems redundant. Is this suffix suggested by RFC ? If not, I would very much propose to get rid of these.

[biplamal]

The value suffix in all the properties and choices inside variable binding seems redundant. Is this suffix suggested by RFC ? If not, I would very much propose to get rid of these.

Yes its suggested by rfc