Initial Cisco FTDv support (#1783)

* add cisco ftdv support

* remove other kind aliases

* use proper kind for generate

* format

---------

Co-authored-by: Dmitry Teslya <[email protected]>
Co-authored-by: Roman Dodin <[email protected]>

clab/register.go

@@ -23,6 +23,7 @@ import (
 	srl "github.com/srl-labs/containerlab/nodes/srl"
 	vr_aoscx "github.com/srl-labs/containerlab/nodes/vr_aoscx"
 	vr_csr "github.com/srl-labs/containerlab/nodes/vr_csr"
+	vr_ftdv "github.com/srl-labs/containerlab/nodes/vr_ftdv"
 	vr_ftosv "github.com/srl-labs/containerlab/nodes/vr_ftosv"
 	vr_n9kv "github.com/srl-labs/containerlab/nodes/vr_n9kv"
 	vr_openbsd "github.com/srl-labs/containerlab/nodes/vr_openbsd"
@@ -61,6 +62,7 @@ func (c *CLab) RegisterNodes() {
 	vr_n9kv.Register(c.Reg)
 	vr_pan.Register(c.Reg)
 	vr_openbsd.Register(c.Reg)
+	vr_ftdv.Register(c.Reg)
 	vr_ros.Register(c.Reg)
 	vr_sros.Register(c.Reg)
 	vr_veos.Register(c.Reg)

cmd/generate.go

@@ -39,7 +39,7 @@ var interfaceFormat = map[string]string{
 
 var supportedKinds = []string{
 	"srl", "ceos", "linux", "bridge", "sonic-vs", "crpd", "vr-sros", "vr-vmx", "vr-vsrx",
-	"vr-vqfx", "vr-vjunosswitch", "vr-xrv9k", "vr-veos", "xrd", "rare", "openbsd",
+	"vr-vqfx", "vr-vjunosswitch", "vr-xrv9k", "vr-veos", "xrd", "rare", "openbsd", "cisco_ftdv",
 }
 
 const (

docs/index.md

@@ -38,8 +38,9 @@ In addition to native containerized NOSes, containerlab can launch traditional v
 * [Juniper vSRX](manual/kinds/vr-vsrx.md)
 * [Cisco IOS XRv9k](manual/kinds/vr-xrv9k.md)
 * [Cisco Nexus 9000v](manual/kinds/vr-n9kv.md)
-* [Dell FTOS10v](manual/kinds/vr-ftosv.md)
 * [Cisco CSR 1000v](manual/kinds/vr-csr.md)
+* [Cisco FTDv](manual/kinds/vr-ftdv.md)
+* [Dell FTOS10v](manual/kinds/vr-ftosv.md)
 * [Arista vEOS](manual/kinds/vr-veos.md)
 * [Palo Alto PAN](manual/kinds/vr-pan.md)
 * [IPInfusion OcNOS](manual/kinds/ipinfusion-ocnos.md)

docs/lab-examples/ftdv01.md

@@ -0,0 +1,75 @@
+|                               |                                                                                 |
+| ----------------------------- | ------------------------------------------------------------------------------- |
+| **Description**               | A Cisco FTDv connected to two Alpine Linux Hosts                                |
+| **Components**                | [Cisco FTDV][ftdv], [Multitool Alpine Linux][client]                            |
+| **Resource requirements**[^1] | :fontawesome-solid-microchip: 4 <br/>:fontawesome-solid-memory: 8 GB            |
+| **Topology file**             | [ftdv01.yml][topofile]                                                          |
+| **Name**                      | ftdv01                                                                          |
+| **Version information**[^2]   | `Cisco_Secure_Firewall_Threat_Defense_Virtual-7.2.5-208.qcow2`, `docker:24.0.6` |
+
+## Description
+
+This lab consists of one Cisco FTDv firewall connected to two Alpine Linux nodes.
+
+```
+client1<---->FTDv<---->client2
+```
+
+## Configuration
+
+The FTDv node takes about 1-2 minutes to complete its start up. Check using "docker container ls" until the FTDv container shows up as "healthy".
+
+```
+# docker container ls
+CONTAINER ID   IMAGE                                  COMMAND                  CREATED              STATUS                        PORTS                                       NAMES
+5682d73984d1   vrnetlab/vr-ftdv:7.2.5                 "/launch.py --userna…"   34 minutes ago   Up 34 minutes (healthy)   22/tcp, 80/tcp, 443/tcp, 5000/tcp, 8305/tcp, 10000-10099/tcp   clab-ftdv01-ftdv1
+1ebe3dae6846   wbitt/network-multitool:alpine-extra   "/bin/sh /docker-ent…"   34 minutes ago   Up 34 minutes             80/tcp, 443/tcp, 1180/tcp, 11443/tcp                           clab-ftdv01-client1
+9726c9bb9e21   wbitt/network-multitool:alpine-extra   "/bin/sh /docker-ent…"   34 minutes ago   Up 34 minutes             80/tcp, 443/tcp, 1180/tcp, 11443/tcp                           clab-ftdv01-client2
+```
+
+### ftdv1
+
+Log into the FTDv node using the Web UI and add the following configuration. Password is `Admin@123`.
+
+1. Click "Skip device setup" on the initial screen.
+2. In the dialog window "Are you sure you want to skip device setup?" check the "Start 90-day evaluation" box, select the "FTDv5 - Tiered" performance tier, and click "Confirm".
+3. In the "Interfaces" menu configure GigabitEthernet0/0 with the `192.168.1.1/30` IP, and GigabitEthernet0/1 with the `192.168.2.1/30` IP.
+4. Go to the "Policies" menu and add a test "allow all" policy (all fields should be left empty, and the action should be "allow").
+5. Deploy pending changes.
+
+### client1
+
+The two clients should be configured with the correct IP addresses and a route to the other client via the FTDv node.
+First attach to the container process `docker exec -it clab-ftdv01-client1 ash`
+
+```
+docker exec -it clab-ftdv01-client1 ash
+
+# ip -br a show dev eth1
+eth1@if3749      UP             192.168.1.2/30 fe80::a8c1:abff:feee:be5c/64
+
+# ip r
+default via 172.20.20.1 dev eth0
+172.20.20.0/24 dev eth0 proto kernel scope link src 172.20.20.4
+192.168.1.0/30 dev eth1 proto kernel scope link src 192.168.1.2
+192.168.2.0/30 via 192.168.1.1 dev eth1
+```
+
+## Verification
+
+Traceroute from client1 to client2 to verify the data-plane via the FTDv node.
+
+### client1
+
+```
+# traceroute 192.168.2.2
+traceroute to 192.168.2.2 (192.168.2.2), 30 hops max, 46 byte packets
+ 1  192.168.2.2 (192.168.2.2)  1.372 ms  0.909 ms  0.403 ms
+```
+
+[ftdv]: https://www.cisco.com/c/en/us/products/collateral/security/firepower-ngfw-virtual/threat-defense-virtual-ngfwv-ds.html
+[client]: https://github.com/wbitt/Network-MultiTool
+[topofile]: https://github.com/srl-labs/containerlab/tree/main/lab-examples/ftdv01/ftdv01.yml
+
+[^1]: Resource requirements are provisional. Consult with the installation guides for additional information.
+[^2]: The lab has been validated using these versions of the required tools/components. Using versions other than stated might lead to a non-operational setup process.

docs/manual/kinds/index.md

@@ -44,6 +44,7 @@ Within each predefined kind, we store the necessary information that is used to
 | **Cisco XRv9k**           | [`vr-xrv9k/vr-cisco_xrv9k`](vr-xrv9k.md)            | supported |    VM     |
 | **Cisco XRv**             | [`vr-xrv/vr-cisco_xrv`](vr-xrv.md)                  | supported |    VM     |
 | **Cisco Nexus 9000v**     | [`vr-n9kv/vr-cisco_n9kv`](vr-n9kv.md)               | supported |    VM     |
+| **Cisco FTDv**            | [`cisco_ftdv`](vr-ftdv.md)                          | supported |    VM     |
 | **Cumulus VX**            | [`cvx/cumulus_cvx`](cvx.md)                         | supported | container |
 | **SONiC**                 | [`sonic`](sonic-vs.md)                              | supported | container |
 | **Dell FTOS**             | [`vr-ftosv/vr-dell_ftos`](vr-ftosv.md)              | supported |    VM     |

docs/manual/kinds/vr-ftdv.md

@@ -0,0 +1,61 @@
+---
+search:
+  boost: 4
+---
+# Cisco FTDv
+
+[Cisco FTDv](https://www.cisco.com/c/en/us/products/collateral/security/firepower-ngfw-virtual/threat-defense-virtual-ngfwv-ds.html) is identified with `cisco_ftdv` kind in the [topology file](../topo-def-file.md). It is built using [vrnetlab](../vrnetlab.md) project and essentially is a Qemu VM packaged in a docker container format.
+
+## Managing FTDv nodes
+
+!!!note
+    Containers with Cisco FTDv inside will take ~1-2 min to fully boot.  
+    You can monitor the progress with `docker logs -f <container-name>`.
+
+Cisco FTDv node launched with containerlab can be managed via the following interfaces:
+
+=== "bash"
+    to connect to a `bash` shell of a running FTDv container:
+    ```bash
+    docker exec -it <container-name/id> bash
+    ```
+=== "CLI via SSH"
+    to connect to the FTDv shell (password `Admin@123`)
+    ```bash
+    ssh admin@<container-name>
+    ```
+=== "Telnet"
+    serial port (console) is exposed over TCP port 5000:
+    ```bash
+    # from container host
+    telnet <container-name> 5000
+    ```  
+    You can also connect to the container and use `telnet localhost 5000` if telnet is not available on your container host.
+=== "HTTPS"
+    HTTPS server is running over port 443 -- connect with any browser normally.
+
+!!!info
+    Default user credentials: `admin:Admin@123`
+
+## Interfaces mapping
+
+* `eth0` - management interface (Management0/0) connected to the containerlab management network
+* `eth1+` - first and subsequent data interfaces (GigabitEthernet0/0, GigabitEthernet0/1, etc.)
+
+When containerlab launches FTDv node, it will assign IPv4/6 address to the `eth0` interface. These addresses are used to reach the management plane of the router.
+
+Data interfaces `eth1+` need to be configured with IP addressing manually using Web UI.
+
+## Features and options
+
+### Node configuration
+
+Cisco FTDv nodes come up with a basic configuration where only the management interface and a default user are provisioned.
+
+Nodes are configured for local management with Firepower Device Management (FDM) On-Box management service. FDM is available via HTTPS and takes a few minutes to come up after node boot up.
+
+## Lab examples
+
+The following simple lab consists of two Linux hosts connected via one FTDv node:
+
+* [Cisco FTDv](../../lab-examples/ftdv01.md)