Session Admission Control

The netconfd-pro server provides several CLI parameters to control the client sessions that are started within the server.

Admission control applies to client session startup. Authentication has already been done.
- The SSH or TLS session must be successfully started before any NETCONF session admission is applied.
- The transport layer provides a username string and protocol used to the netconfd-pro server.
The server checks each new session request in 3 ways:
- Protocol Control: the transport or application protocol must be enabled and properly configured.
- Username Control: the session username value must be allowed.
- Concurrent Limit Control: adding a new concurrent client session must be allowed.
Internal 'YControl' sessions are not subject to admission control except there must be an available concurrent session to allocate.
Sessions for any --superuser are subject to session admission control the same as a normal client session.

Protocol Control

There are multiple ways to setup client protocols for use in the server:

Boot-Time Protocol Control

The northbound protocols that are available to clients are configurable.

Each selected protocol must be enabled using a 'with-foo' type of parameter.
The protocol must be selected so it is properly initialized and cleaned up by the server.
Sessions for the protocol can be disabled in the CLI (starting 23.10T-9) using the --disabled-protocols CLI parameter.

Some protocols are not enabled by default, and/or require certain compiler make flags to be used to include the code in the server.

If the protocol is disabled then incoming client sessions will be dropped right away and the underlying transport session will be closed by the server.

If the protocol is enabled then incoming client sessions will not be dropped for this reason, however the session may not be admitted for other reasons.

Run-Time Protocol Control

There are new features added (starting in 23.10T-9) that allow protocols to be enabled or disabled at run-time, so the server does not have to be rebooted to enable or disable sessions for a particular protocol.

Run-time Protocol Operation
- <protocol-control> operation in yumaworks-system.yang
Run-time <edit-config> Operation
- 'disabled-protocols' leaf in yumaworks-server.yang allows protocols to be enabled or disabled, and the --disabled-protocols CLI parameter changed for the next reboot.
netconfd-pro SIL APIs:
- Allow custom RPC and action callbacks to access the same APIs used by the <protocol-control> operation.
Subsystem DB-API APIs:
- Use 'subrpc' operation to access the <protocol-control> operation
- Use 'protocol-control' subsystem request to access same functionality as the <protocol-control> operation, in case the yumaworks-system.yang and yumaworks-server.yang are not available.
db-api-app command:
- Use the sample db-api-app program to access the DB-API functions to control protocols.
- Example:
```
> db-api-app --protocol-action=enable --protocol=restconf
```

Username Control

The username provided to the NETCONF layer is normally accepted without any checking. Use the --allowed-user leaf-list parameter to specify all the allowed usernames.

If the username is identified as a --superuser then this parameter is ignored and the username is allowed.
Otherwise if this parameter is present at all, then only the specified username values will be allowed.
This parameter can be used to share OpenSSH with normal terminal usage, if not all SSH users are intended to be network management users.

Concurrent Limit Control

The server must have enough resources available to allow any session to be started.

Hard Session Control Block Limit

The total number of available session control blocks is 1023. The limit of '1024' in the CLI parameters is not actually allowed since one session control block is reserved for internal use.

There must be enough session control slots available to start a new session or the session request will be rejected and the transport session will be closed by the server.

Total Concurrent Client Sessions

The --max-sessions parameter controls the total number of concurrent client sessions that are allowed. The default value is '8'. The value can bet as high as '1024'. There must be enough session control blocks available for any YControl sessions from subsystems (if used).

The --max-cli-sessions parameter controls the number of 'yp-shell' client sessions that can be active at once. The --with-yp-shell parameter must be set to 'true' for this parameter to have any affect.

Total Concurrent Client Sessions By A Single User

The --max-user-sessions parameter controls the total number of concurrent client sessions that are allowed for each client. The default value is '0' which means that no concurrent session limit is placed on the same username. The value can bet as high as '1024'. There must be enough session control blocks available for any YControl sessions from subsystems (if used).

The --max-per-user-sessions parameter allows concurrent session limits to be set for specific users. This parameter overrides the --max-user-sessions parameter for the specified user. This allows the two parameters to be used together to allow certain users to have higher limits than others.

Session Parameter Configuration Example

The following example shows how these CLI parameters can be used together to support 3 'admin' and 2 'guest' users:

netconfd-pro {
  # many other parameters not shown

  # configure protocols
  with-gnmi false
  with-grpc false
  with-netconf true
  with-netconf-tls false
  with-restconf true
  with-snmp false
  with-yp-shell true

  # only allow 5 client usernames
  allowed-user admin1
  allowed-user admin2
  allowed-user admin3
  allowed-user guest1
  allowed-user guest2

  # limit concurrent sessions
  max-sessions 32
  max-cli-sessions 10
  max-user-sessions 10
  max-per-user-sessions guest1:1
  max-per-user-sessions guest2:1

}