duplicate notification subscription on netopeer2-server

[srikanthsubbaramu]

Hi Michal,

i have a question, if a establish-sub is repeatedly used from same session , we are accepting the subscription and generating a new subscription in effect, its a duplicate subscription, at server should we not have a check for this or is it entirely on the client to manage its subscriptions?

in one of negative testing scenarios, an app repeatedly kept subscribing for same notification , which eventually hit fd limit and lead to netopeer2-server crash,

so just wanted to understand if we should check at server.

sample:

> establish-sub --stream NETCONF --filter-xpath /_ran-nr-nrm-cmAgent-oru-rpc:notification-result-execute-ru-rpc
DATA
<id xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">16</id>

> establish-sub --stream NETCONF --filter-xpath /_ran-nr-nrm-cmAgent-oru-rpc:notification-result-execute-ru-rpc
DATA
<id xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">17</id>

below is notification

  notification notification-result-execute-ru-rpc {
    description
      "Relays the RU's rpc-reply for one dispatched rpc-request.
       Correlated to the original request by ru-id + txn-id.
       xml carries the raw rpc-reply content from the RU.";
    leaf ru-id {
      type string;
      mandatory true;
      description
        "ru-id of the O-RU that replied.";
    }
    leaf txn-id {
      type string;
      mandatory true;
      description
        "Echoed from the originating rpc-request.";
    }
    anydata xml {
      description
        "Raw rpc-reply body from the RU, e.g.
         <status>SUCCEEDED</status>
         <wait-time>5</wait-time>
         <measurement-id>1</measurement-id>";
    }
  }

in one negative case testing, there were about 300 fds consumed for same notification
113 /dev/shm/srsub__ran-nr-nrm-cmAgent-oru-rpc.notif {

[michalvasko]

There are no rules, to my knowledge, limiting similar subscriptions on a NETCONF session so the server behaves correctly.

[svashok]

Hi Michal, I have a basic question:

Netconf server can create 'n' number of subscriptions from 'm' number of clients simultaneously. For each subscription, server will send Netconf notification based on the param/state change, so more subscriptions will lead to more notifications flood from server.

When a particular client is creating subscription for an XPATH (say cell operational-state change), a subscription entry gets added in the Netconf server. When another client (different IP address) is creating subscription for the same XPATH, server can create additional subscription entry, but if the same client is trying to create a duplicate subscription for same XPATH, server must either ignore this or respond with 'subscription already exists'. Instead, server keeps on creating additional subscription entries even though there are duplicates which will lead to unnecessary flood of notifications sent for each subscription entry, which seems to be incorrect.

I feel this logic must be FIXED / OPTIMIZED. Please let me know your view or your justification for the existing mechanism.

[michalvasko]

Justification of the current behavior is very simple, the RFC lists all the reasons an establish-subscription can fail because of, there is no "subscription-exists" or anything like that. There is insufficient-resources error but I am not sure at what point to generate this error but it could perhaps be supported somehow to avoid hitting any resource limits.

[svashok]

Hi Michal, we are indeed hitting the resource limit at server due to a bug on the client side, multiple duplicate subscriptions are being created repeatedly for the same client. So please consider implementing this boundary condition to protect the server side, and you may remove the 'invalid' tag from the ticket if you agree. Thanks!

[michalvasko]

I could not think of a generic way how this can be implemented. The most straightforward solution for you is to write a patch for the establish-subscription callback for netopeer2 that will refuse duplicate subscriptions, for example. To avoid having to maintain a patch, you could also write your own small sysrepo app (or just a plugin) that will also subscribe to establish-subscription RPC and can refuse it for any reason. You cannot directly track duplicate subscriptions that way (you can if you store every created subscription) but you can monitor system state and return insufficient-resources error if necessary.