diff --git a/docs/cli/plugins/getting-started.md b/docs/cli/plugins/getting-started.md index 9fb0e546..3760885a 100644 --- a/docs/cli/plugins/getting-started.md +++ b/docs/cli/plugins/getting-started.md @@ -28,6 +28,13 @@ Last Booted: 2025-02-15T16:23:47.956Z Nothing sophisticated, yet it provides a good starting point for you to get familiar with the most important building blocks of the CLI plugin development. The full code is available in the [uptime-cli-plugin](https://github.com/srl-labs/uptime-cli-plugin) repository. +/// details | Video tutorial + type: subtle-note +For the fans of the video format: + +-{{youtube(url='https://www.youtube.com/embed/NtBnldprxLE')}}- +/// + ## Setting up the environment Spending some time on setting up the dev environment will greatly simplify code navigation and debugging. To assist you with the environment setup, our repo features a small script with some helper functions. @@ -414,7 +421,7 @@ You can find the leaf that contains the last booted time by browsing the SR Linu 1. Using the CLI - /// tab | `info flat from state` with `grep` + /// tab | `tree flat from state` with `grep` An efficient way to find the needed leaf if you know some keywords is to use the `info flat from state` command and pipe it to `grep`. Since we know that we are looking for the time when the SR Linux system was last booted, we could use something like this: diff --git a/docs/kb/cfgmgmt.md b/docs/kb/cfgmgmt.md deleted file mode 100644 index 25a22a07..00000000 --- a/docs/kb/cfgmgmt.md +++ /dev/null @@ -1,155 +0,0 @@ -SR Linux employs a transaction-based configuration management system. That allows for a number of changes to be made to the configuration with an explicit `commit` required to apply the changes as a single transaction. - -## Configuration file -The default location for the configuration file is `/etc/opt/srlinux/config.json`. - -If there is no configuration file present, a basic configuration file is auto-generated with the following defaults: - -* Creation of a management network instance -* Management interface is added to the mgmt network instance -* DHCP v4/v6 is enabled on mgmt interface -* A set of default of logs are created -* SSH server is enabled -* Some default IPv4/v6 CPM filters - -## Configuration modes - -Configuration modes define how the system is running when transactions are performed. Supported modes are the following: - -* **Running:** the default mode when logging in and displays displays the currently running or active configuration. -* **State:** the running configuration plus the addition of any dynamically added data. Some examples of state specific data are operational state of various elements, counters and statistics, BGP auto-discovered peer, LLDP peer information, etc. -* **Candidate:** this mode is used to modify configuration. Modifications are not applied until the `commit` is performed. When committed, the changes are copied to the running configuration and become -active. The candidate configuration configuration can itself be edited in the following modes: - * *Shared:* this is the default mode when entering the candidate mode with `enter candidate` command. This allows multiple users to modify the candidate configuration concurrently. When the configuration is committed, the changes from all of the users are applied. - * *Exclusive Candidate:* When entering candidate mode with `enter candidate exclusive`, it locks out other users from making changes to the candidate configuration. - You can enter candidate exclusive mode only under the following conditions: - * The current shared candidate configuration has not been modified. - * There are no other users in candidate shared mode. - * No other users have entered candidate exclusive mode. - * *Private:* A private candidate allows multiple users to modify a configuration; however when a user commits their changes, only the changes from that user are committed. - When a private candidate is created, private datastores are created and a snapshot is taken from the running database to create a baseline. When starting a private candidate, a default candidate is defined per user with the name `private-` unless a unique name is defined. - -!!!note - gNMI & JSON-RPC both use an exclusive candidate and an implicit commit when making a configuration change on the device. - -## Setting the configuration mode -After logging in to the CLI, you are initially placed in `running` mode. The following table provides commands to enter in a specific mode: - -| Candidate mode | Command to enter | -| :----------------------------------------- | :-------------------------------------- | -| Candidate shared | `enter candidate` | -| Candidate mode for named shared candidate | `enter candidate name ` | -| Candidate private | `enter candidate private` | -| Candidate mode for named private candidate | `enter candidate private name ` | -| Candidate exclusive | `enter candidate exclusive` | -| Exclusive mode for named candidate | `enter candidate exclusive name ` | -| Running | `enter running` | -| State | `enter state` | -| Show | `enter show` | - -## Committing configuration -Changes made during a configuration modification session do not take effect until a `commit` command is issued. Several options are available for `commit` command, below are the most notable ones: - -| Option | Action | -| :----------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `commit now` | Apply the changes, exit candidate mode, and enter running mode | -| `commit stay` | Apply the changes and then remain in candidate mode | -| `commit save` | Apply the changes and automatically save the commit to the startup configuration | -| `commit confirmed` | Apply the changes, but requires an explicit confirmation to become permanent. If the explicit confirmation is not issued within a specified time period, all changes are automatically reverted | - -## Deleting configuration -Use the `delete` command to delete configurations while in candidate mode. - -The following example displays the system banner configuration, deletes the configured banner, then displays the resulting system banner configuration: -```linenums="1" ---{ candidate shared default}--[ ]-- -A:leaf1# info system banner - system { - banner { - login-banner "Welcome to SRLinux!" - } - } - ---{ candidate shared default}--[ ]-- -A:leaf1# delete system banner - ---{ candidate shared default}--[ ]-- -A:leaf1# info system banner - system { - banner { - } - } -``` - -## Discarding configuration -You can discard previously applied configurations with the `discard` command. - -* To discard the changes and remain in candidate mode with a new candidate session, enter `discard stay`. -* To discard the changes, exit candidate mode, and enter running mode, enter `discard now`. - -## Displaying configuration diff -Use the `diff` command to get a comparison of configuration changes. Optional arguments can be used to indicate the source and destination datastore. - -The following use rules apply: -* If no arguments are specified, the diff is performed from the candidate to the baseline of the candidate. -* If a single argument is specified, the diff is performed from the current candidate to the specified candidate. -* If two arguments are specified, the first is treated as the source, and the second as the destination. - -Global arguments include: `baseline`, `candidate`, `checkpoint`, `factory`, `file`, `from`, `rescue`, `running`, and `startup`. - -The diff command can be used outside of candidate mode, but only if used with arguments. - -The following shows a basic `diff` command without arguments. In this example, the description and admin state of an interface are changed and the differences shown: -```linenums="1" ---{ candidate shared default }--[ ]-- -# interface ethernet-1/1 admin-state disable - ---{ * candidate shared default }--[ ]-- -# interface ethernet-1/2 description "updated" - ---{ * candidate shared default }--[ ]-- -# diff - interface ethernet-1/1 { -+ admin-state disable - } -+ interface ethernet-1/2 { -+ description updated -+ } -``` - -## Displaying configuration details -Use the `info` command to display the configuration. Entering the info command from the root context displays the entire configuration, or the configuration for a specified context. Entering the command from within a context limits the display to the configuration under that context. - -To display the entire configuration, enter `info` from the root context: -``` ---{ candidate shared default}--[ ]-- -# info - ---{ candidate }--[ ]-- -``` - -To display the configuration for a specific context, enter info and specify the context: -``` ---{ candidate shared default}--[ ]-- -# info system lldp - system { - lldp { - admin-state enable - hello-timer 600 - management-address mgmt0.0 { - type [ - IPv4 - ] - } - interface mgmt0 { - admin-state disable - } - } - } -``` - -The following `info` command options are rather useful: - -* `as-json` - to display JSON-formatted output -* `detail` - to display values for all parameters, including those not specifically configured -* `flat` - to display the output as a series of set statements, omitting indentation for any sub-contexts diff --git a/docs/kb/hwtypes.md b/docs/kb/hwtypes.md deleted file mode 100644 index b1d703fb..00000000 --- a/docs/kb/hwtypes.md +++ /dev/null @@ -1,41 +0,0 @@ -The SR Linux software supports the following Nokia hardware platforms[^1]: - -* 7250 IXR-6 -* 7250 IXR-10 -* 7220 IXR-D1 -* 7220 IXR-D2 -* 7220 IXR-D2L -* 7220 IXR-D3 -* 7220 IXR-D3L -* 7220 IXR-H2 -* 7220 IXR-H3 - -The `type` field under the node configuration sets the emulated hardware type in the containerlab file: - -```yaml -# part of the evpn01.clab.yml file - nodes: - leaf1: - kind: srl - type: ixrd3 # <- hardware type this node will emulate -``` - -The `type` field defines the hardware variant that this SR Linux node will emulate. The available `type` values are: - -| type value | HW platform | -| :--------- | :----------- | -| ixr6 | 7250 IXR-6 | -| ixr10 | 7250 IXR-10 | -| ixrd1 | 7220 IXR-D1 | -| ixrd2 | 7220 IXR-D2 | -| ixrd2l | 7220 IXR-D2L | -| ixrd3 | 7220 IXR-D3 | -| ixrd3l | 7220 IXR-D3L | -| ixrh2 | 7220 IXR-H2 | -| ixrh3 | 7220 IXR-H3 | - - -!!!tip - Containerlab-launched nodes are started as `ixrd2` hardware type unless set to a different [type](https://containerlab.srlinux.dev/manual/kinds/srl/#types) in the clab file. - -[^1]: SR Linux can also run on the whitebox/3rd party switches. \ No newline at end of file diff --git a/docs/kb/ifaces.md b/docs/kb/ifaces.md deleted file mode 100644 index 17bad396..00000000 --- a/docs/kb/ifaces.md +++ /dev/null @@ -1,83 +0,0 @@ -On the SR Linux, an interface is any physical or logical port through which packets can be sent to or received from other devices. - -## Loopback -Loopback interfaces are virtual interfaces that are always up, providing a stable -source or destination from which packets can always be originated or received. -The SR Linux supports up to 256 loopback interfaces system-wide, across all -network instances. Loopback interfaces are named `loN`, where N is 0 to 255. - -## System -The system interface is a type of loopback interface that has characteristics that -do not apply to regular loopback interfaces: - -- The system interface can be bound to the default network-instance only. -- The system interface does not support multiple IPv4 addresses or multiple -IPv6 addresses. -- The system interface cannot be administratively disabled. Once configured, it is always up. - -The SR Linux supports a single system interface named `system0`. When the system interface is bound to the default network-instance, and an IPv4 address is configured for it, the IPv4 address is the default local address for multi-hop BGP sessions to IPv4 neighbors established by the default network-instance, and it is the default IPv4 source address for IPv4 VXLAN tunnels established by the default network-instance. -The same functionality applies with respect to IPv6 addresses / IPv6 BGP neighbors / IPv6 VXLAN tunnels. - -## Network -Network interfaces carry transit traffic, as well as originate and terminate control plane traffic and in-band management traffic. - -The physical ports in line cards installed in the SR Linux are network interfaces. A typical line card has a number of front-panel cages, each accepting a pluggable transceiver. Each transceiver may support a single channel or multiple channels, supporting one Ethernet port or multiple Ethernet ports, depending on the transceiver type and its breakout options. - -In the SR Linux CLI, each network interface has a name that indicates its type and its location in the chassis. The location is specified with a combination of slot number and port number, using the following formats: `ethernet-slot/port`. For example, interface `ethernet-2/1` refers to the line card in slot 2 of the SR Linux chassis, and port 1 on that line card. - -On 7220 IXR-D3 systems, the QSFP28 connector ports (ports `1/3-1/33`) can operate in breakout mode. Each QSFP28 connector port operating in breakout -mode can have four breakout ports configured, each operating at 25G. Breakout ports are named using the following format: `ethernet-slot/port/breakout-port`. - -For example, if interface `ethernet 1/3` is enabled for breakout mode, its breakout ports are named as follows: - -- `ethernet 1/3/1` -- `ethernet 1/3/2` -- `ethernet 1/3/3` -- `ethernet 1/3/4` - -## Management -Management interfaces are used for out-of-band management traffic. The SR Linux supports a single management interface named `mgmt0`. The `mgmt0` interface supports the same functionality and defaults as a network -interface, except for the following: - -- Packets sent and received on the mgmt0 interface are processed -completely in software. -- The mgmt0 interface does not support multiple output queues, so there is -no output traffic differentiation based on forwarding class. -- The mgmt0 interface does not support pluggable optics. It is a fixed 10/100/ -1000-BaseT copper port. - -## Integrated Routing and Bridging (IRB) -IRB interfaces enable inter-subnet forwarding. Network instances of type mac-vrf are associated with a network instance of type ip-vrf via an IRB interface. - -## Subinterfaces -On the SR Linux, each type of interface can be subdivided into one or more -subinterfaces. A subinterface is a logical channel within its parent interface. - -Traffic belonging to one subinterface can be distinguished from traffic belonging to -other subinterfaces of the same port using encapsulation methods such as 802.1Q -VLAN tags. - -While each port can be considered a shared resource of the router that is usable by -all network instances, a subinterface can only be associated with one network -instance at a time. To move a subinterface from one network instance to another, you -must disassociate it from the first network instance before associating it with the -second network instance. - -You can configure ACL policies to filter IPv4 and/or IPv6 packets entering or leaving -a subinterface. - -The SR Linux supports policies for assigning traffic on a subinterface to forwarding -classes or remarking traffic at egress before it leaves the router. DSCP classifier -policies map incoming packets to the appropriate forwarding classes, and DSCP -rewrite-rule policies mark outgoing packets with an appropriate DSCP value based -on the forwarding class - -SR Linux subinterfaces can be specified as type routed or bridged: - -* Routed subinterfaces can be assigned to a network-instance of type mgmt, -default, or ip-vrf. -* Bridged subinterfaces can be assigned to a network-instance of type mac-vrf. - -Routed subinterfaces allow for configuration of IPv4 and IPv6 settings, and bridged -subinterfaces allow for configuration of bridge table and VLAN ingress/egress -mapping. \ No newline at end of file diff --git a/docs/kb/mgmt.md b/docs/kb/mgmt.md deleted file mode 100644 index 3e952fe8..00000000 --- a/docs/kb/mgmt.md +++ /dev/null @@ -1,87 +0,0 @@ -Nokia SR Linux is equipped with 100% YANG modelled management interfaces. -The supported management interfaces (CLI, JSON-RPC, and gNMI) access the common management API layer via a gRPC interface. -Since all interfaces act as a client towards a common management API, SR Linux provides complete consistency across all the management interfaces with regards to the capabilities available to each of them. - -## SR Linux CLI -The SR Linux CLI is an interactive interface for configuring, monitoring, and maintaining the SR Linux via an SSH or console session. - -Throughout the course of this quickstart we will use CLI as our main configuration interface and leave the gNMI and JSON interfaces for the more advanced scenarios. For that reason, we describe CLI interface here in a bit more details than the other interfaces. - -### Features -* **Output Modifiers.** - Advanced Linux output modifiers `grep`, `more`, `wc`, `head`, and `tail` are exposed directly through the SR Linux CLI. -* **Suggestions & List Completions.** - As commands are typed suggestions are provided. Tab can be used to list options available. -* **Output Format.** - When displaying info from a given datastore, the output can be formatted in one of three ways: - * **Text:** this is the default out, it is JSON-like but not quite JSON. - * **JSON:** the output will be in JSON format. - * **Table:** The CLI will try to format the output in a table, this doesn’t work for all data but can be very useful. -* **Aliases.** - An alias is used to map a CLI command to a shorter easier to remember command. For example, if a command is built to retrieve specific information from the state datastore and filter on specific fields while formatting the output as a table the CLI command could get quite long. - An alias could be configured so that a shorter string of text could be used to execute that long CLI command. Alias can be further enhanced to be dynamic which makes them extremely powerful because they are not limited to static CLI commands. - - - -### Accessing the CLI -After the SR Linux device is initialized, you can access the CLI using a console or SSH connection. - -Using the connection details provided by containerlab when we deployed the quickstart lab we can connect to any of the nodes via SSH protocol. For example, to connect to `leaf1`: - -``` -ssh admin@clab-quickstart-leaf1 -``` -``` -Warning: Permanently added 'clab-quickstart-leaf1,2001:172:20:20::8' (ECDSA) to the list of known hosts. -admin@clab-quickstart-leaf1's password: -Using configuration file(s): [] -Welcome to the srlinux CLI. -Type 'help' (and press ) if you need any help using this. ---{ running }--[ ]-- -A:leaf1# -``` - -### Prompt -By default, the SR Linux CLI prompt consists of two lines of text, indicating with an asterisk whether the configuration has been modified, the current mode and session type, the current CLI context, and the host name of the SR Linux device, in the -following format: -``` ---{ modified? mode_and_session_type }--[ context ]-- -hostname# -``` - -Example: -``` ---{ * candidate shared }--[ acl ]-- -3-node-srlinux-A# -``` - -The CLI prompt is configurable and can be changed within the `environment prompt` configuration context. - -In addition to the prompt, SR Linux CLI has a bottom toolbar. It appears at the bottom of the terminal window and displays: - -* the current mode and session type -* whether the configuration has been modified -* the user name and session ID of the current AAA session -* and the local time - -For example: -``` -Current mode: * candidate shared root (36) Wed 09:52PM -``` - -## gNMI -The gRPC-based gNMI protocol is used for the modification and retrieval of configuration from a target device, as well as the control and generation of telemetry streams from a target device to a data collection system. - -SR Linux can enable a gNMI server that allows external gNMI clients to connect to the device and modify the configuration and collect state information. - -Supported gNMI RPCs are: - -* Get -* Set -* Subscribe -* Capabilities - -## JSON-RPC -The SR Linux provides a JSON-based Remote Procedure Call (RPC) for both CLI commands and configuration. The JSON API allows the operator to retrieve and set the configuration and state, and provide a response in JSON format. This JSON-RPC API models the CLI implemented on the system. - -If output from a command cannot be displayed in JSON, the text output is wrapped in JSON to allow the application calling the API to retrieve the output. During configuration, if a TCP port is in use when the JSON-RPC server attempts to bind to it, the commit fails. The JSON-RPC supports both normal paths, as well as XPATHs. \ No newline at end of file diff --git a/docs/kb/netwinstance.md b/docs/kb/netwinstance.md deleted file mode 100644 index f2f4db58..00000000 --- a/docs/kb/netwinstance.md +++ /dev/null @@ -1,24 +0,0 @@ -On the SR Linux, you can configure one or more virtual routing instances, known as -network instances. Each network instance has its own interfaces, its own protocol -instances, its own route table, and its own FIB. - -When a packet arrives on a subinterface associated with a network instance, it is -forwarded according to the FIB of that network instance. Transit packets are normally -forwarded out another subinterface of the network instance. - -SR Linux supports the following types of network instances: - -* default -* ip-vrf -* mac-vrf - -The initial startup configuration for SR Linux has a single `default` network instance. - -By default, there are no ip-vrf or mac-vrf network instances; these must be created -by explicit configuration. The ip-vrf network instances are the building blocks of Layer -3 IP VPN services, and mac-vrf network instances are the building blocks of EVPN -services. - -Within a network instance, you can configure BGP, OSPF, and IS-IS protocol options -that apply only to that network instance. - diff --git a/docs/programmability/index.md b/docs/programmability/index.md index 2dc834ca..c42e94ed 100644 --- a/docs/programmability/index.md +++ b/docs/programmability/index.md @@ -38,7 +38,7 @@ title: Programmability Operators can leverage CLI plugins to customize the way CLI looks, feels, and reacts. - :material-progress-wrench: Article coming soon... + [:octicons-arrow-right-24: Reference](../cli/plugins/index.md) - :fontawesome-brands-golang:{ .lg .middle } **Go API** @@ -60,16 +60,6 @@ title: Programmability [:octicons-arrow-right-24: Checkout examples](../blog/tags.md#tag:event-handler) -- :octicons-flame-24:{ .lg .middle } **NAPALM** - - --- - - Familiar with a multi-vendor network automation interface that spits fire? - - With [`napalm-srlinux`](https://github.com/napalm-automation-community/napalm-srlinux) community driver we plug in the NAPALM ecosystem using gNMI as the underlying management interface. - - [:octicons-arrow-right-24: Try yourself](https://github.com/napalm-automation-community/napalm-srlinux) - - :material-ansible:{ .lg .middle } **Ansible** --- @@ -104,6 +94,16 @@ title: Programmability [:octicons-arrow-right-24: SNMP Framework](../snmp/snmp_framework.md) +- :octicons-flame-24:{ .lg .middle } **NAPALM** + + --- + + Familiar with a multi-vendor network automation interface that spits fire? + + With [`napalm-srlinux`](https://github.com/napalm-automation-community/napalm-srlinux) community driver we plug in the NAPALM ecosystem using gNMI as the underlying management interface. + + :material-progress-wrench: [Refactoring needed...](https://github.com/napalm-automation-community/napalm-srlinux) + [scraplipy-srl]: https://github.com/scrapli/scrapli_community/tree/main/scrapli_community/nokia/srlinux diff --git a/docs/tutorials/infrastructure/kne/topology.md b/docs/tutorials/infrastructure/kne/topology.md index cc843861..40dedba9 100644 --- a/docs/tutorials/infrastructure/kne/topology.md +++ b/docs/tutorials/infrastructure/kne/topology.md @@ -74,7 +74,7 @@ The vendor field must be set to `NOKIA` when working with Nokia SR Linux nodes. ### Model -With the `model` field a user indicates which particular model of a given Vendor should be used by the node. In the context of Nokia SR Linux, the `model` field drives the [hardware variant](../../../kb/hwtypes.md) that an SR Linux container will emulate. +With the `model` field a user indicates which particular model of a given Vendor should be used by the node. In the context of Nokia SR Linux, the `model` field drives the hardware variant that an SR Linux container will emulate. ```proto nodes: { diff --git a/docs/tutorials/l2evpn/evpn.md b/docs/tutorials/l2evpn/evpn.md index 283f1efd..c4fc07f4 100644 --- a/docs/tutorials/l2evpn/evpn.md +++ b/docs/tutorials/l2evpn/evpn.md @@ -2,7 +2,10 @@ comments: true --- - +# EVPN configuration + + + Ethernet Virtual Private Network (EVPN), along with Virtual eXtensible LAN (VXLAN), is a technology that allows Layer 2 and Layer 3 traffic to be tunneled across an IP network. @@ -133,7 +136,7 @@ Next we are configuring the interfaces from the leaf switches to the correspondi
-Configuration of an access interface is nothing special, we already [configured leaf-spine interfaces](fabric.md#leaf-spine-interfaces) at the fabric configuration stage, so the steps are all familiar. The only detail worth mentioning here is that we have to indicate the type of the subinterface to be [`bridged`](../../kb/ifaces.md#subinterfaces), this makes the interfaces only attachable to a network instance of `mac-vrf` type with MAC learning and layer-2 forwarding enabled. +Configuration of an access interface is nothing special, we already [configured leaf-spine interfaces](fabric.md#leaf-spine-interfaces) at the fabric configuration stage, so the steps are all familiar. The only detail worth mentioning here is that we have to indicate the type of the subinterface to be `bridged`, this makes the interfaces only attachable to a network instance of `mac-vrf` type with MAC learning and layer-2 forwarding enabled. The following config is applied to both leaf switches: diff --git a/docs/tutorials/l2evpn/fabric.md b/docs/tutorials/l2evpn/fabric.md index 863a887f..b9c281b2 100644 --- a/docs/tutorials/l2evpn/fabric.md +++ b/docs/tutorials/l2evpn/fabric.md @@ -2,7 +2,10 @@ comments: true --- - +# Fabric configuration + + + Prior to configuring EVPN based overlay, a routing protocol needs to be deployed in the fabric to advertise the reachability of all the leaf VXLAN Termination End Point (VTEP) addresses throughout the IP fabric. With SR Linux, the following routing protocols can be used in the underlay: @@ -19,7 +22,7 @@ Let's start with configuring the IP interfaces on the inter-switch links to ensu
-On each leaf and spine we will bring up the relevant [interface](../../kb/ifaces.md) and address its routed [subinterface](../../kb/ifaces.md#subinterfaces) to achieve L3 connectivity. +On each leaf and spine we will bring up the relevant [interface](../../get-started/interface.md) and address its routed subinterface to achieve L3 connectivity. We begin with connecting to the CLI of our nodes via SSH[^1]: @@ -28,7 +31,7 @@ We begin with connecting to the CLI of our nodes via SSH[^1]: ssh clab-evpn01-leaf1 ``` -Then on each node we enter into [candidate configuration mode](../../kb/cfgmgmt.md#configuration-modes) and proceed with the relevant interfaces' configuration. +Then on each node we enter into [candidate configuration mode](../../get-started/cli.md#cli-modes) and proceed with the relevant interfaces' configuration. Let's witness the step by step process of an interface configuration on a `leaf1` switch with providing the paste-able snippets for the rest of the nodes @@ -151,7 +154,7 @@ ethernet-1/1 is up, speed 10G, type None ==================================================== ``` -At this moment, the configured interfaces can not be used as they are not yet associated with any [network instance](../../kb/netwinstance.md). Below we are placing the interfaces to the network-instance `default` that is created automatically by SR Linux. +At this moment, the configured interfaces can not be used as they are not yet associated with any [network instance](../../get-started/network-instance.md). Below we are placing the interfaces to the network-instance `default` that is created automatically by SR Linux. /// tab | leaf1 & leaf2 @@ -466,7 +469,7 @@ routing-policy { As we will create a IBGP based EVPN control plane at a later stage, we need to configure loopback addresses for our leaf devices so that they can build an IBGP peering over those interfaces. -In the context of the VXLAN data plane, a special kind of a loopback needs to be created - [`system0`](../../kb/ifaces.md#system) interface. +In the context of the VXLAN data plane, a special kind of a loopback needs to be created - `system0` interface. /// info The `system0.0` interface hosts the loopback address used to originate and typically diff --git a/docs/tutorials/mpls/mpls-ldp/intro.md b/docs/tutorials/mpls/mpls-ldp/intro.md index f710ae6c..61921c1f 100644 --- a/docs/tutorials/mpls/mpls-ldp/intro.md +++ b/docs/tutorials/mpls/mpls-ldp/intro.md @@ -5,7 +5,7 @@ tags: - mpls --- - + | | | | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -21,7 +21,13 @@ Multiprotocol Label Switching (MPLS) is a label switching technology that provid This short tutorial will guide you through the steps required to build an [LDP-based](https://datatracker.ietf.org/doc/html/rfc5036) MPLS core consisting of three SR Linux routers. LDP-based MPLS tunnels are commonly used to enable [BGP-free core network](http://bgphelp.com/2017/02/12/bgp-free-core/). -The topology we will use for this interactive tutorial is dead simple - three routers connected in a point-to-point fashion: +/// warning +MPLS features are currently (at the time of this writing) supported only on SR Linux 7250 IXR-6e/10e and 7730 SXR platforms. Container images emulating these platforms require a license to operate. + +Without the license provided, the lab will not start. +/// + +The topology we will use for this interactive tutorial is quite simple - three routers connected in a point-to-point fashion:
diff --git a/docs/tutorials/mpls/mpls-ldp/routing.md b/docs/tutorials/mpls/mpls-ldp/routing.md index 30d2650e..9fa62008 100644 --- a/docs/tutorials/mpls/mpls-ldp/routing.md +++ b/docs/tutorials/mpls/mpls-ldp/routing.md @@ -2,7 +2,9 @@ comments: true --- - +# Routing + + Prior to any MPLS configuration, we need to set up routing in the network core. Configuration of interfaces and IGP is the core task explained in this section. @@ -12,7 +14,7 @@ Let's start with basic interfaces configuration following this diagram:
-The below config snippets configure regular `Ethernet-1/1`, `Ethernet-1/2` and a special loopback [`system0`](../../../kb/ifaces.md#system) interfaces. +The below config snippets configure regular `Ethernet-1/1`, `Ethernet-1/2` and a special loopback `system0` interfaces. === "srl1" ```srl