gRIBI configuration

To enable the gRIBI server:

  1. Configure gRIBI at system level using the following procedures:
    1. Enabling gRIBI server support at system level
    2. Enabling the gRIBI server for a network-instance
    3. (Optional) Configuring a UNIX socket for the gRIBI server
  2. Configure gRIBI at the network-instance level:

    Enabling gRIBI protocol support for the network-instance

Enabling gRIBI server support at system level

To configure the gRIBI server, you must enable gRIBI server support at the system level.
  1. Set the system gRIBI server admin-state to enable (default is disable):
    system gribi-server admin-state enable
  2. (Optional) Set the following system-level gRIBI server parameters:
    • timeout: sets the idle timeout in seconds on gRIBI clients
    • rate-limit: sets a limit on the number of connection attempts per minute
    • session-limit: sets a limit on the number of simultaneous active gRIBI sessions
    • trace-options: sets gRIBI trace options ([common | request | response])

Enable the gRIBI server support for the system

The following example enables the gRIBI server support at system level. It also sets the timeout, rate-limit, and session-limit values to their default values and sets the trace-options to common. 

--{ * candidate shared default }--[  ]--
# info system gribi-server
    system {
        gribi-server {
            admin-state enable
            timeout 7200
            rate-limit 60
            session-limit 20
            trace-options [
                common
            ]       
        }
    }

Enabling the gRIBI server for a network-instance

To configure the gRIBI server, you must also enable gRIBI server support on one or more network-instances under the system context.

On each network-instance, you can configure a unique gRIBI server socket. The gRIBI server can run on different ports using different authentication mechanisms on different network-instances. This allows you to, for example, run stricter restrictions on authentication and security on an in-band network-instance, while setting fewer restrictions on an out-of-band network-instance.

If the gRIBI server is not using UNIX sockets, sessions between the gRIBI client and the SR Linux device must be encrypted using Transport Layer Security (TLS). To specify the TLS profile for the gRIBI server, use the tls-profile option.

If use-authentication is set to true, SR Linux performs local authentication after validating the X.509 certificate from the client (and sending its own). In this case, the client must supply a username and password in the metadata of the RPC message (for example, a ModifyRequest or GetRequest). The SR Linux AAA manager authenticates this username and password following normal authentication logic.

  1. Set the network-instance gRIBI server admin-state to enable (default is disable):
    system gribi-server network-instance admin-state enable
  2. Set the following network-instance-level gRIBI server parameters:
    • use-authentication: enables or disables the use of username/password authentication for every gRIBI RPC request
    • port: TCP port the gRIBI server listens on for incoming connections
    • tls-profile: references the TLS profile to use on the gRIBI server (mandatory)
    • source-address: list of IP addresses the gRIBI server listens on within the network-instance

Enable the gRIBI server support for the default network-instance

The following example enables the gRIBI server support for the default network-instance. It also sets use-authentication and port to their default values and specifies values for the tls-profile and source-address. 

--{ * candidate shared default }--[  ]--
# info system gribi-server network-instance default
    system {
        gribi-server {
            network-instance default {
                admin-state enable
                use-authentication true
                port 57401
                tls-profile test-tls
                source-address [
                    10.10.10.1
                ]
            }
        }
    }

Configuring a UNIX socket for the gRIBI server

To configure a UNIX socket for the gRIBI server:

  1. Set the system gRIBI server UNIX socket admin-state to enable (default is disable):
    system gribi-server unix-socket admin-state enable
  2. Set the following parameters:
    • tls-profile: References the TLS profile to use on the gRIBI unix socket server. If none is specified, then TLS is not used.
    • use-authentication: Enables or disables the use of username/password authentication for every gRIBI RPC request (default: true).

The following example enables a UNIX socket using a TLS profile (gribi-unix-socket) and sets use-authentication to true. 

--{ * candidate shared default }--[  ]--
# info system gribi-server unix-socket
    system {
        gribi-server {
            unix-socket {
                admin-state enable
                use-authentication true
                tls-profile gribi-unix-socket
            }
        }
    }

Enabling gRIBI protocol support for the network-instance

In addition to enabling the gRIBI server support on the system and the network-instance, you must also administratively enable the gRIBI protocol support on the network-instance.

When the gRIBI protocol admin-state is set to disable, all IP entries and next-hop-groups associated with the network-instance are deleted from the gRIBI server database. The recovery of this state depends on the gRIBI clients to re-signal all of the deleted entries. While in a disabled state, no entries are accepted for this network-instance. (This is the same behavior when the network-instance does not exist at all.)

To enable gRIBI protocol support for the network-instance:

  1. Set the gRIBI protocol admin-state to enable (default is disable):
    network-instance <instance> protocols gribi admin-state enable
  2. (Optional) Set the following gRIBI protocol parameters for the network-instance:
    • default-metric: Sets the route table metric to use for all gRIBI-created IPv4 and IPv6 routes.
    • default-preference: Sets the default preference when deciding the route to use from different protocols (lower values indicate higher preference).
    • max-ecmp-hash-buckets-per-next-hop-group: Sets the maximum number of ECMP hash buckets per next-hop-group.
    • maximum-routes: Sets the maximum number of gRIBI routes (sum of IPv4 and IPv6 entries).

The following example enables the gRIBI protocol on the default network-instance. It also sets the default-metric, default-preference, max-ecmp-hash-buckets-per-next-hop-group, and maximum-routes parameters to their default values. 

--{ * candidate shared default }--[  ]--
# info network-instance default protocols gribi
    network-instance default {
        protocols {
            gribi {
                admin-state enable
                default-metric 1
                default-preference 4
                max-ecmp-hash-buckets-per-next-hop-group 128
                maximum-routes 0
            }
        }
    }