Add cJunosEvolved

[kmo7]

• adding cJunosEvolved to containerlab
• adding the cJunosEvolved lab example and it's doc
• adding the cJunosEvolved description manual

[hellt]

thanks @kmo7

@vista- could you give this a try when you have time given you are my Juniper buddy 👯

[vista-]

Thank you very much for your contribution @kmo7! I left some comments and suggestions. Since I don't think this is a publicly available product yet (or is it? some clarification would be helpful :)), I think it would be best to hold off on merging this until its released, just for the sake of the maintainers' sanity ;)

Unless the release is imminent, of course, we'd love to help you launch with Clab support built-in!

[kmo7]

cJunosEvolved will be released at the end of this month and at that time, the link mentioned in the doc will be available. We wanted to put this up for review early, so it can be merged in to containerlab when it is released. If it helps, I can post the results of my testing, showing cJunosEvolved coming up and pinging Srlinux fine, etc on this review (or would you like it committed to the repo in the lab-examples document at the end? I am the developer for cJunosEvolved, but we cannot provide an image till the official release goes out. We can however meet and answer questions if you like? Thanks. Juniper Business Use Only From: Roman Dodin ***@***.***> Sent: Thursday, June 12, 2025 1:25 AM To: srl-labs/containerlab ***@***.***> Cc: Kaveh Moezzi ***@***.***>; Mention ***@***.***> Subject: Re: [srl-labs/containerlab] Add cJunosEvolved (PR #2617) [External Email. Be cautious of content] @hellt commented on this pull request.

________________________________ In docs/manual/kinds/cjunosevolved.md<https://urldefense.com/v3/__https:/github.com/srl-labs/containerlab/pull/2617*discussion_r2142044318__;Iw!!NEt6yMaO-gk!FC9U6NzJd_mfwpBP4SMUHvfjVfH5XjuO6E0LEnrG_a6q7fMkQaVqE1-AdXMGPtGj5xcCDEKtrchhVTOzD0lcXUm7RA$>:

+## How to obtain the image

+ +The container image can be freely downloaded from the [Juniper support portal](https://support.juniper.net/support/downloads/?p=cjunos-evolved) without a Juniper account. Type cJunosEvolved in the `Find a Product` search box. It seems the support portal does not list cjunos evolved as a product available for download — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/srl-labs/containerlab/pull/2617*pullrequestreview-2920052451__;Iw!!NEt6yMaO-gk!FC9U6NzJd_mfwpBP4SMUHvfjVfH5XjuO6E0LEnrG_a6q7fMkQaVqE1-AdXMGPtGj5xcCDEKtrchhVTOzD0l0wDmffg$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AVFQEDKY2IC6AC2BC75YPOT3DE2N3AVCNFSM6AAAAAB7DYGFKCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDSMRQGA2TENBVGE__;!!NEt6yMaO-gk!FC9U6NzJd_mfwpBP4SMUHvfjVfH5XjuO6E0LEnrG_a6q7fMkQaVqE1-AdXMGPtGj5xcCDEKtrchhVTOzD0lD_Xchfg$>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[hellt]

Thanks @kmo7 for the comments. It is great seeing contributions for new systems coming ahead of the release time, love it.

Given our reliance on you doing the testing, I'd say the path forward is to address existing comments and then re-checking that the same MVP reproduction with srl-cjunos works

[hellt]

@kmo7 ping us here when the image becomes available, @vista- and myself will do some hands-on testing and then we merge this one

[kmo7]

Great. Will do. You can both can ping me on here if you need to discuss something after you start testing.

[vista-]

We can also be reached via Discord if need be :)

[vista-]

@kmo7 I rebased your branch onto latest main to add a recent commit that fixes the CI/CD pipeline, just as a heads-up

[kmo7]

@kmo7 I rebased your branch onto latest main to add a recent commit that fixes the CI/CD pipeline, just as a heads-up

Thanks Vista, i don't see this commit reflected in containerlab.dev yet, e.g. on the front page where vendor notes are listed.
https://containerlab.dev/ or in the nodes directory: https://github.com/srl-labs/containerlab/tree/main/nodes

Are you waiting on the image from us or the rebase operation to be done>

[nleiva]

Hi all,

Might be too early, but would it be possible to add a pre-config hook to the cJunosEvolved router kind in Containerlab to execute a couple of operational commands that generate TLS certificates directly on the container?

The commands are:

request security pki generate-key-pair certificate-id myname
request security pki local-certificate generate-self-signed certificate-id myname subject CN=abc domain-name clab.com ip-address 1.2.3.4 email [email protected]

This would enable the configuration of TLS-based services like RESTCONF in the startup-config:

services {
    rest {
        https {
            port 3000;
            server-certificate myname;
        }
    }
}

Let me know if that’s feasible or if there’s a preferred approach.

Thanks!
Nicolas

[vista-]

Hi @kmo7,

Congrats on launching cJunosEvo! Thank you again for your hard work with preparing this PR.

I just tried out the cJunosEvo image, just a few observations:

The way the startup configuration to the node is provided does not really match the way most other Containerlab kinds do it: they just append the generated config required for management connectivity to the provided config.

cJunosEvolved, on the other hand, expects the provided startup config to contain the mgmt config to template into.

This essentially means a user would have to manually edit the configuration saved from the node in order for it to be usable in the next deploy (which might not assign the same management IP address to the node).

Rather than your current approach for generating an initial startup configuration, perhaps it would be better to put this logic (rendering a default config template and merging it with the user-provided startup config) into Containerlab? Check out how it's done with cRPD, it's fairly easy to template in runtime variables: https://github.com/srl-labs/containerlab/blob/main/nodes/crpd/crpd.go#L155

Some further notes:

• The default config loaded on the node is a bit lackluster. I would suggest adding the following:
  • Hostname should be included for easy identification of nodes in the topology
  • NETCONF and gNMI should be pre-enabled in the default config
  • system { management-instance; } helps avoid issues down the line where you might kill your own management connectivity
• I would add "Node can take 5+ minutes to boot" to the Kind documentation, since some users won't look in the container logs to find out if it's actually booting or not.
• Perhaps define a health check command to give feedback to the user/containerlab when the node has finished booting?

[kmo7]

Hi @kmo7,

Congrats on launching cJunosEvo! Thank you again for your hard work with preparing this PR.

I just tried out the cJunosEvo image, just a few observations:

The way the startup configuration to the node is provided does not really match the way most other Containerlab kinds do it: they just append the generated config required for management connectivity to the provided config.

cJunosEvolved, on the other hand, expects the provided startup config to contain the mgmt config to template into.

This essentially means a user would have to manually edit the configuration saved from the node in order for it to be usable in the next deploy (which might not assign the same management IP address to the node).

Rather than your current approach for generating an initial startup configuration, perhaps it would be better to put this logic (rendering a default config template and merging it with the user-provided startup config) into Containerlab? Check out how it's done with cRPD, it's fairly easy to template in runtime variables: https://github.com/srl-labs/containerlab/blob/main/nodes/crpd/crpd.go#L155

Some further notes:

* The default config loaded on the node is a bit lackluster. I would suggest adding the following:
  
  * Hostname should be included for easy identification of nodes in the topology
  * NETCONF and gNMI should be pre-enabled in the default config
  * `system { management-instance; }` helps avoid issues down the line where you might kill your own management connectivity

* I would add "Node can take 5+ minutes to boot" to the Kind documentation, since some users won't look in the container logs to find out if it's actually booting or not.

* Perhaps define a health check command to give feedback to the user/containerlab when the node has finished booting?

Reponse:
Hi Vista, thanks for the review. Have incorporated some of the comments and we will look at the rest for the next commit. Since cJunosEvolved has now been also verified by you to be working, can you please merge the pull request into containerlab so the many others that are expressing interest to use it, can do so, and will get back to you on the rest? Please see below responses to the comments.

• With respect to the longer comment up front, this is the key point "This essentially means a user would have to manually edit the configuration saved from the node in order for it to be usable in the next deploy (which might not assign the same management IP address to the node)."
  3 points on this:
  1- The current FXP0ADDR token scheme our code uses, does correctly configure the management IP according to what containerlab passes in to the container, even when the cevo instance is restarted and a new management port IP is assigned by the containerlab.
  2- As you know, the save command has not been working in general for many containers in containerlab and you are fixing that but it is not yet committed:
  nodes: Add generic implementation for VM-based node startup config saving #2659
  Once that is committed, for vr-net lab based containers, could you also fix it for cjunosevo?
  3- With the combination of the above 2 points, even though cjunosevolved does this differently than some other containers in clab, it will still function correctly.

wrt to these comments:
o Hostname should be included for easy identification of nodes in the topology. Yes, agreed. We will address this in a subsequent commit. This feature works in our docker compose deployements, but has one line missing to make it work in containerlab. Either by adding that line or by pushing the hostname from the go code, we will fix this, but do not want to delay the initial commit, so people can bringup cjunosevo and use it initially.
o NETCONF and gNMI should be pre-enabled in the default config

• netconf already is enabled in the following config file: lab-examples/srlcjunosevo/cjunosevo.cfg. Users can do same for their deployments (will show the test log for this at the end).
• GNMI was not enabled for our vJunosEvolved, vJunos-switch and vJunos-router also. This needs a bit more work and we will enable it in a subsequent commit.
  o system { management-instance; Added this to the above config file to separate the mgmt port into its own routing instance.
  "• I would add "Node can take 5+ minutes to boot" to the Kind documentation,". This was already documented in this kind doc file: docs/manual/kinds/cjunosevolved.md, line 28. If you think it is needed elsewhere too, can you please add it?

"Perhaps define a health check command to give feedback to the user/containerlab when the node has finished booting?" I have added this info the kind documentation file. Besides the docker log command, the " # docker exec -ti clab-srlcjunosevo-cevo cli" indicates bootup progress periodically, so the user is not blind to that.

Thanks for the careful review Vista. I hope above answers the immediate comments so you can commit the code into clab and I will follow up w/ the rest.

Here is a sample netconf log:

ssh admin@clab-srlcjunosevo-cevo -p 830 -s netconf

Warning: Permanently added '[clab-srlcjunosevo-cevo]:830' (ED25519) to the list of known hosts.
(admin@clab-srlcjunosevo-cevo) Password:

urn:ietf:params:netconf:base:1.0 urn:ietf:params:netconf:capability:candidate:1.0 urn:ietf:params:netconf:capability:confirmed-commit:1.0 urn:ietf:params:netconf:capability:validate:1.0 urn:ietf:params:netconf:capability:url:1.0?scheme=http,ftp,file urn:ietf:params:xml:ns:netconf:base:1.0 urn:ietf:params:xml:ns:netconf:capability:candidate:1.0 urn:ietf:params:xml:ns:netconf:capability:confirmed-commit:1.0 urn:ietf:params:xml:ns:netconf:capability:validate:1.0 urn:ietf:params:xml:ns:netconf:capability:url:1.0?scheme=http,ftp,file urn:ietf:params:xml:ns:yang:ietf-yang-metadata?module=ietf-yang-metadata&revision=2016-08-05 urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring http://xml.juniper.net/netconf/junos/1.0 http://xml.juniper.net/dmi/system/1.0 http://yang.juniper.net/junos/jcmd?module=junos-configuration-metadata&revision=2021-09-01 31674 ]]>]]>

[codecov]

Codecov Report

Attention: Patch coverage is 17.64706% with 42 lines in your changes missing coverage. Please review.

Project coverage is 54.83%. Comparing base (02513f6) to head (69291f6).
Report is 25 commits behind head on main.

Files with missing lines	Patch %	Lines
nodes/cjunosevolved/cjunosevolved.go	16.00%	41 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2617      +/-   ##
==========================================
- Coverage   54.90%   54.83%   -0.07%     
==========================================
  Files         184      185       +1     
  Lines       20151    20202      +51     
==========================================
+ Hits        11063    11078      +15     
- Misses       7948     7985      +37     
+ Partials     1140     1139       -1     

Files with missing lines	Coverage Δ
clab/register.go	100.00% <100.00%> (ø)
nodes/cjunosevolved/cjunosevolved.go	16.00% <16.00%> (ø)

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[vista-]

lgtm