Deployed 6327f9b with MkDocs version: 1.4.2

manual/kinds/srl/index.html

@@ -42,7 +42,7 @@
 </span></code></pre></div> <h3 id="breakout-interfaces">Breakout interfaces<a class="headerlink" href="#breakout-interfaces" title="Permanent link">#</a></h3> <p>If the interface is intended to be configured as a breakout interface, its name must be changed accordingly.</p> <p>The breakout interfaces will have the name <code>eX-Y-Z</code> where <code>Z</code> is the breakout port number. For example, if interface <code>ethernet-1/3</code> on an IXR-D3 system is meant to act as a breakout 100Gb to 4x25Gb, then the interfaces in the topology must use the following naming:</p> <div class="language-yaml highlight"><pre><span></span><code><span id="__span-7-1"><a href="#__codelineno-7-1" id="__codelineno-7-1" name="__codelineno-7-1"></a><span class="w">  </span><span class="nt">links</span><span class="p">:</span>
 </span><span id="__span-7-2"><a href="#__codelineno-7-2" id="__codelineno-7-2" name="__codelineno-7-2"></a><span class="w">    </span><span class="c1"># srlinux's first breakout port ethernet-1/3/1 is connected to sros port 2</span>
 </span><span id="__span-7-3"><a href="#__codelineno-7-3" id="__codelineno-7-3" name="__codelineno-7-3"></a><span class="w">    </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">endpoints</span><span class="p">:</span><span class="w"> </span><span class="p p-Indicator">[</span><span class="s">"srlinux:e1-3-1"</span><span class="p p-Indicator">,</span><span class="w"> </span><span class="s">"sros:eth2"</span><span class="p p-Indicator">]</span>
-</span></code></pre></div> <h2 id="features-and-options">Features and options<a class="headerlink" href="#features-and-options" title="Permanent link">#</a></h2> <h3 id="types">Types<a class="headerlink" href="#types" title="Permanent link">#</a></h3> <p>For SR Linux nodes <a href="../../nodes/#type"><code>type</code></a> defines the hardware variant that this node will emulate.</p> <p>The available type values are: <code>ixrd1</code>, <code>ixrd2</code>, <code>ixrd3</code>, <code>ixrd2l</code>, <code>ixrd3l</code>, <code>ixrd4</code>, <code>ixrd5</code>, <code>ixrd5t</code>, <code>ixrh2</code>, <code>ixrh3</code> and <code>ixrh4</code>, which correspond to a hardware variant of Nokia 7220 IXR chassis.</p> <p>Nokia 7250 IXR chassis identified with types <code>ixr6e</code> and <code>ixr10e</code> require a valid license to operate.</p> <p>Nokia 7730 SXR models are identified with types <code>sxr1x44s</code>, <code>sxr1d32d</code> and require a valid license to operate.</p> <p>If type is not set in the clab file <code>ixrd2</code> value will be used by containerlab.</p> <p>Based on the provided type, containerlab will generate the topology file that will be mounted to the SR Linux container and make it boot in a chosen HW variant.</p> <h3 id="node-configuration">Node configuration<a class="headerlink" href="#node-configuration" title="Permanent link">#</a></h3> <p>SR Linux uses a <code>/etc/opt/srlinux/config.json</code> file to persist its configuration. By default, containerlab starts nodes of <code>srl</code> kind with a basic "default" config, and with the <code>startup-config</code> parameter, it is possible to provide a custom config file that will be used as a startup one.</p> <h4 id="default-node-configuration">Default node configuration<a class="headerlink" href="#default-node-configuration" title="Permanent link">#</a></h4> <p>When a node is defined without the <code>startup-config</code> statement present, containerlab will make <a href="https://github.com/srl-labs/containerlab/blob/main/nodes/srl/srl.go#L38">additional configurations</a> on top of the factory config:</p> <div class="language-yaml highlight"><pre><span></span><code><span id="__span-8-1"><a href="#__codelineno-8-1" id="__codelineno-8-1" name="__codelineno-8-1"></a><span class="c1"># example of a topo file that does not define a custom startup-config</span>
+</span></code></pre></div> <h2 id="features-and-options">Features and options<a class="headerlink" href="#features-and-options" title="Permanent link">#</a></h2> <h3 id="types">Types<a class="headerlink" href="#types" title="Permanent link">#</a></h3> <p>For SR Linux nodes <a href="../../nodes/#type"><code>type</code></a> defines the hardware variant that this node will emulate.</p> <p>The available type values are: <code>ixrd1</code>, <code>ixrd2</code>, <code>ixrd3</code>, <code>ixrd2l</code>, <code>ixrd3l</code>, <code>ixrd4</code>, <code>ixrd5</code>, <code>ixrd5t</code>, <code>ixrh2</code>, <code>ixrh3</code> and <code>ixrh4</code>, which correspond to a hardware variant of Nokia 7220 IXR chassis.</p> <p>Nokia 7250 IXR chassis identified with types <code>ixr6e</code> and <code>ixr10e</code> require a valid license to operate.</p> <p>Nokia 7730 SXR models are identified with types <code>sxr1x44s</code>, <code>sxr1d32d</code> and require a valid license to operate.</p> <p>If type is not set in the clab file <code>ixrd2</code> value will be used by containerlab.</p> <p>Based on the provided type, containerlab will generate the topology file that will be mounted to the SR Linux container and make it boot in a chosen HW variant.</p> <h3 id="node-configuration">Node configuration<a class="headerlink" href="#node-configuration" title="Permanent link">#</a></h3> <p>SR Linux uses a <code>/etc/opt/srlinux/config.json</code> file to persist its configuration. By default, containerlab starts nodes of <code>srl</code> kind with a basic "default" config, and with the <code>startup-config</code> parameter, it is possible to provide a custom config file that will be used as a startup one.</p> <h4 id="default-node-configuration">Default node configuration<a class="headerlink" href="#default-node-configuration" title="Permanent link">#</a></h4> <p>When a node is defined without the <code>startup-config</code> statement present, containerlab will make <a href="https://github.com/srl-labs/containerlab/blob/srl-template-in-a-file/nodes/srl/srl_default_config.go.tpl">additional configurations</a> on top of the factory config:</p> <div class="language-yaml highlight"><pre><span></span><code><span id="__span-8-1"><a href="#__codelineno-8-1" id="__codelineno-8-1" name="__codelineno-8-1"></a><span class="c1"># example of a topo file that does not define a custom startup-config</span>
 </span><span id="__span-8-2"><a href="#__codelineno-8-2" id="__codelineno-8-2" name="__codelineno-8-2"></a><span class="c1"># as a result, the default configuration will be used by this node</span>
 </span><span id="__span-8-3"><a href="#__codelineno-8-3" id="__codelineno-8-3" name="__codelineno-8-3"></a>
 </span><span id="__span-8-4"><a href="#__codelineno-8-4" id="__codelineno-8-4" name="__codelineno-8-4"></a><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">srl_lab</span>
@@ -51,7 +51,7 @@
 </span><span id="__span-8-7"><a href="#__codelineno-8-7" id="__codelineno-8-7" name="__codelineno-8-7"></a><span class="w">    </span><span class="nt">srl1</span><span class="p">:</span>
 </span><span id="__span-8-8"><a href="#__codelineno-8-8" id="__codelineno-8-8" name="__codelineno-8-8"></a><span class="w">      </span><span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">srl</span>
 </span><span id="__span-8-9"><a href="#__codelineno-8-9" id="__codelineno-8-9" name="__codelineno-8-9"></a><span class="w">      </span><span class="nt">type</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ixrd3</span>
-</span></code></pre></div> <p>The generated config will be saved by the path <code>clab-&lt;lab_name&gt;/&lt;node-name&gt;/config/config.json</code>. Using the example topology presented above, the exact path to the config will be <code>clab-srl_lab/srl1/config/config.json</code>.</p> <p>Additional configurations that containerlab adds on top of the factory config:</p> <ul> <li>enabling interfaces (<code>admin-state enable</code>) referenced in the topology's <code>links</code> section</li> <li>enabling LLDP</li> <li>enabling gNMI/JSON-RPC</li> <li>creating tls server certificate</li> <li>setting <code>mgmt0 subinterface 0 ip-mtu</code> to the MTU value of the underlying container runtime network</li> </ul> <p>A configuration checkpoint named <code>clab-initial</code> is generated by containerlab once default and user-provided configs are applied. The checkpoint may be used to quickly revert configuration changes made by a user to a state that was present after the node was started.</p> <h4 id="user-defined-startup-config">User defined startup config<a class="headerlink" href="#user-defined-startup-config" title="Permanent link">#</a></h4> <p>It is possible to make SR Linux nodes boot up with a user-defined config instead of a built-in one. With a <a href="../../nodes/#startup-config"><code>startup-config</code></a> property of the node/kind a user sets the path to the local config file that will be used as a startup config.</p> <p>The startup configuration file can be provided in two formats:</p> <ul> <li>full SR Linux config in JSON format</li> <li>partial config in SR Linux CLI format</li> </ul> <h5 id="cli">CLI<a class="headerlink" href="#cli" title="Permanent link">#</a></h5> <p>A typical lab scenario is to make nodes boot with a pre-configured use case. The easiest way to do that is to capture the intended changes as CLI commands.</p> <p>On SR Linux, users can configure the system and capture the changes in the form of CLI instructions using the <code>info</code> command. These CLI commands can be saved in a file<sup id="fnref:3"><a class="footnote-ref" href="#fn:3">3</a></sup> and used as a startup configuration.</p> <details class="info"> <summary>CLI config examples</summary> <p>these snippets can be the contents of <code>myconfig.cli</code> file referenced in the topology below</p> <div class="tabbed-set tabbed-alternate" data-tabs="2:2"><input checked="checked" id="__tabbed_2_1" name="__tabbed_2" type="radio"/><input id="__tabbed_2_2" name="__tabbed_2" type="radio"/><div class="tabbed-labels"><label for="__tabbed_2_1">Regular config</label><label for="__tabbed_2_2">Flat config</label></div> <div class="tabbed-content"> <div class="tabbed-block"> <div class="language-bash highlight"><pre><span></span><code><span id="__span-9-1"><a href="#__codelineno-9-1" id="__codelineno-9-1" name="__codelineno-9-1"></a>network-instance<span class="w"> </span>default<span class="w"> </span><span class="o">{</span>
+</span></code></pre></div> <p>The rendered config can be found at <code>/tmp/clab-default-config</code> path on SR Linux filesystem and will be saved by the path <code>clab-&lt;lab_name&gt;/&lt;node-name&gt;/config/config.json</code>. Using the example topology presented above, the exact path to the config will be <code>clab-srl_lab/srl1/config/config.json</code>.</p> <p>Additional configurations that containerlab adds on top of the factory config:</p> <ul> <li>enabling interfaces (<code>admin-state enable</code>) referenced in the topology's <code>links</code> section</li> <li>enabling LLDP</li> <li>enabling gNMI/gNOI/JSON-RPC as well as enabling unix-socket access for gRPC services</li> <li>creating tls server certificate</li> <li>setting <code>mgmt0 subinterface 0 ip-mtu</code> to the MTU value of the underlying container runtime network</li> </ul> <p>A configuration checkpoint named <code>clab-initial</code> is generated by containerlab once default and user-provided configs are applied. The checkpoint may be used to quickly revert configuration changes made by a user to a state that was present after the node was started.</p> <h4 id="user-defined-startup-config">User defined startup config<a class="headerlink" href="#user-defined-startup-config" title="Permanent link">#</a></h4> <p>It is possible to make SR Linux nodes boot up with a user-defined config instead of a built-in one. With a <a href="../../nodes/#startup-config"><code>startup-config</code></a> property of the node/kind a user sets the path to the local config file that will be used as a startup config.</p> <p>The startup configuration file can be provided in two formats:</p> <ul> <li>full SR Linux config in JSON format</li> <li>partial config in SR Linux CLI format</li> </ul> <h5 id="cli">CLI<a class="headerlink" href="#cli" title="Permanent link">#</a></h5> <p>A typical lab scenario is to make nodes boot with a pre-configured use case. The easiest way to do that is to capture the intended changes as CLI commands.</p> <p>On SR Linux, users can configure the system and capture the changes in the form of CLI instructions using the <code>info</code> command. These CLI commands can be saved in a file<sup id="fnref:3"><a class="footnote-ref" href="#fn:3">3</a></sup> and used as a startup configuration.</p> <details class="info"> <summary>CLI config examples</summary> <p>these snippets can be the contents of <code>myconfig.cli</code> file referenced in the topology below</p> <div class="tabbed-set tabbed-alternate" data-tabs="2:2"><input checked="checked" id="__tabbed_2_1" name="__tabbed_2" type="radio"/><input id="__tabbed_2_2" name="__tabbed_2" type="radio"/><div class="tabbed-labels"><label for="__tabbed_2_1">Regular config</label><label for="__tabbed_2_2">Flat config</label></div> <div class="tabbed-content"> <div class="tabbed-block"> <div class="language-bash highlight"><pre><span></span><code><span id="__span-9-1"><a href="#__codelineno-9-1" id="__codelineno-9-1" name="__codelineno-9-1"></a>network-instance<span class="w"> </span>default<span class="w"> </span><span class="o">{</span>
 </span><span id="__span-9-2"><a href="#__codelineno-9-2" id="__codelineno-9-2" name="__codelineno-9-2"></a><span class="w">    </span>interface<span class="w"> </span>ethernet-1/1.0<span class="w"> </span><span class="o">{</span>
 </span><span id="__span-9-3"><a href="#__codelineno-9-3" id="__codelineno-9-3" name="__codelineno-9-3"></a><span class="w">    </span><span class="o">}</span>
 </span><span id="__span-9-4"><a href="#__codelineno-9-4" id="__codelineno-9-4" name="__codelineno-9-4"></a><span class="w">    </span>interface<span class="w"> </span>ethernet-1/2.0<span class="w"> </span><span class="o">{</span>