Leaf config generation

[Piotr P.]

Hi,

Could someone clarify situation with  config generation. I'm having current code of the OpenClos from the branch master.

I'm seeing behaviour when only config is generated for spine devices and additionaly available for the rest devices is generic configuration for a specific hardware model.

Also leaf switches are not present in the dhcp.conf  

This behaviour is visible with the "anotherPod" setup (yaml +  inventory)

Here is an example 

# ls *.conf

157dd705-87f8-4561-91c6-2480e3c31798__clos-spine-01.conf  dhcpd.conf       qfx5100-96s-8q.conf

aae1679f-4021-4ea6-8615-7e1b50e18869__clos-spine-02.conf  ex4300-48p.conf

In previous version OpenClos was generating configuration for all devices. Is this some planned change ? 

Regards

Piotr P

 

[Moloy c]

Hi Piotr,

Thanks for playing with OpenClos.

If you look at master/jnpr/openclos/conf/openclos.yaml, it has following setting .. With this setting, the leaf config is not generated initially, after device is plugged in and ZTP (zero touch provision) process is done, then based on the connected topology it gets right configuration. If you want to pre-generate leaf configs, the set ztpStaged to false. In that case all leaf configs are generated initially based on the pre-decided cabling plan.

deploymentMode :
	ztpStaged : true

Please let me know if you have other questions.

Regards,

Moloy

[Piotr P.]

Hi,

thanks for clarification. Indeed this setting was the case. 

Can you explain or show some document how to complete ztp configuration with default settings (ztpStaged : True) ?

What I got on test device after is only generic config for a specific model.  In my case configuration on the device is the same as in  qfx5100-96s-8q.conf. Probably I need to run some additional  process to complete configuration.

Thanks for great project

Regards

Peter

[Moloy c]

Hi Peter,

Let me ask how did the devices get the configuration? Through ZTP or manual config upload?

If you had run jnpr/openclos/tests/sampleApplication.py, it does 4 things, creates configuration, set up the dhcp server (for ZTP), starts the REST server (for ZTP), starts trap listener. The other option is run these manually on separate terminal.

After the device gets default configuration, qfx5100-96s-8q.conf for your case, the device would generate trap. The trap listener would receive it and perform re-configuration of the device based on connected topology.

There would be log files on the directory you ran the commands like openclos-xx.log, please check those to see if trap listener is working properly. You can also increase logging level at jnpr/openclos/conf/logging.yaml

Thanks,

Moloy

[Darien Hirotsu]

Hi Moloy-

We're running into a similar issue running sampleApplication.py using the two-stage deployment method. We increased the logging level for trapd to DEBUG. We do see the trap being received from the leaf on the OpenClos server as shown below. However, the leaf doesn't get an updated configuration and nothing seems to happen after the trap is received.

Any ideas? Thanks!

2016-06-02 00:58:12,426 [trapd       ] [INFO    ] [7f0f9f7bb700] Notification message from 10.0.33.13:57001 

2016-06-02 00:58:12,427 [trapd       ] [DEBUG   ] [7f0f9f7bb700] Var-binds:

2016-06-02 00:58:12,427 [trapd       ] [DEBUG   ] [7f0f9f7bb700] 1.3.6.1.2.1.1.3.0 = _BindValue:

 value=ObjectSyntax:

  application-wide=ApplicationSyntax:

   timeticks-value=206711

2016-06-02 00:58:12,427 [trapd       ] [DEBUG   ] [7f0f9f7bb700] 1.3.6.1.6.3.1.1.4.1.0 = _BindValue:

 value=ObjectSyntax:

  simple=SimpleSyntax:

   objectID-value=1.3.6.1.4.1.2636.4.12.0.1

.

.

.

Darien

[Darien Hirotsu]

Hi Moloy-

Just following up on this, we followed your advice, and we were able to make progress by running trapd.py separately from sampleApplication.py.

However, we're still running into a problem that we aren't sure how to address. We want to connect the spine/leaf switches differently than how OpenClos determines via its cabling plan. We thought we could use the two-stage deployment process, but it looks like the findMatchedDevice() method validates that the cabled network matches OpenClos's expected cabling plan.

Is this correct? If so, is there a way users can choose which spine ports connect to specific leaf ports? Thanks again for all the help!

Darien