Cloud Managed Networks

This guide is intended to educate the reader on the use of templates for AOS-Switches.  Also included are working and usable template and variables files, that are built out to support up to a 5 member stack.  My examples are for the 2930M family. 

 

Be sure to edit the variables file to reflect your Switches Serial number and MACs

Fixed the template file missing %endif%

I've uploaded Dom's templates (as well as some of my own) to a GitHub repository for easier consumption.

 

https://github.com/aruba/central-sample-bulk-configurations

 

 

Hello,

 

Is this only working with the 2930M? Or also with the 2930F?

Ifso are there any special requirements?

 

With kind regards,

 

Rens

The example displays a 2930M, but it would work in a similar fashion with the 2930Fs. The only catch is that the template will look a little bit different, since the 2930F uses front-plane stacking and the 2930M uses backplane stacking.

 

 

Hello,

 

In case of 2930F how would this process look like?

I assume for the first switch, please correct me if I missed something:

1) power on switch and connect to provider

2) switch receives ip address from dhcp

3) switch initiates contact to Aruba Central

4) Central starts pushing config (vsf info)

5) switch reboots

6) switch receives ip address from dhcp

7) switch initiates contact to Aruba Central

8) Central starts pushing rest of config config

 

But how would this work for the second and third switch?

How do you make sure the second switch is able to connect to Aruba Central? Do you connect the VSF ports? Or do you need some other work around?

 

Hope someone can explain.

 

Regards,

 

Rens

I'm afraid you'd need an extra configuration step where you enable VSF on the 2nd and 3rd switch locally.

 

As an alternative, you can also use an ethernet cable for the 2nd switch to have connectivity through a regular port and initiate the ZTP process.

 

HTH

Has anyone got a working template / variables file for VSF switches? :)

Hi Chris,

 

the example template for 2930M hardware/backplane stack in the first post of this thread also can be used for frontplane/VSF stack.

 

All stack configuration is put into one variable: %_sys_stack_command%

Regardless if you use backplane or frontplane stacking.

 

Here is the lengthy content of that variable of a VSF stack in production:

vsf
   enable domain 1
   member 1
      type \"JL558A\" mac-address 123456-654321
      priority 255
      link 1 1/51-1/52
      link 1 name \"I-Link1_1\"
      link 2 name \"I-Link1_2\"
      exit
   member 2
      type \"JL558A\" mac-address 654321-123456
      priority 128
      link 1 name \"I-Link2_1\"
      link 2 2/51-2/52
      link 2 name \"I-Link2_2\"
      exit
   port-speed 10g
   exit

This is all in one line. Line breaks of real configuration are inserted by "
".

Compare this to the likewiese variable in the template above and you'll see the differences to backplane stacking.

 

I created that by first configuring VSF stack locally. Afterwards ZTPed it into Central, assigned it to a template group, loaded the existing config of the VSF stack as template into the group.

 

One uggly thing: If you export this to CSV, the "
" will be broken into real new lines. So only export to json works.

 

Regards, Jö

Thanks Jo,

I managed to get it to work by enabling VSF domain 1 and rebooting the first switch, then pre-provisioning the other stack members.

I found that I didn’t have to enter anything into the variable for _sys_stack_command as it is automatically pulled from the switch.

This means that for new deployments, I only have to unbox and configure the commander for each stack.

What would be really nice if if Central could support true ZTP for VSF switches, which wouldn’t be too hard.

There could be an ‘enable VSF’ variable which if set, Central could push down the command to enable VSF only without overwriting the _sys_stack_command variable. You could then have populated it with the other members to pre-provision.

One thing I also found was that if a switch serial has joined Central as a stack commander previously, it will not pull down a config as a standalone switch anymore (e.g. if it is factory defaulted).

Hi Chris,

 

"there is room left to improve..." ;-)

 

Since stack support is relatively new, I expect Aruba to improve that step by step.

 

maybe it is already possible to ZTP unconfigured switches into Central and enable stacking afterwards...

I didn't check, because I prefere to do some things locally at the beginning, like checking for up to date firmware. And while connected I can configure stacking anyway.

 

But maybe:

1. ZTP Commander switch into central
2. Fill _sys_stack_command, maybe for all planned members
3. Assign Commander to template with stacking enabled
4. Commander should get VSF config from termplate
5. maybe manual reboot is needed. Don't remember, if it happens automatically.
6. After Commander is set and up again, connect members and power them on

As said. Not sure, never tested. I personally think, preconfiguring is much easier ;-)

 

Regards, Jö

Hey Jo,

Didn’t quite work like that when I tested it unfortunately :(

I have logged a request for enhancement on the Aruba Innovation page though :)

Hello Chris and Jö,

 

I've been doing some testing with this the last few weeks in a Proof of Concept for a customer.

 

I've managed to get ZTP working with some minor items to take into account.

First the firmware needs to be at the correct level (VSF and Central is only supported in 16.07 and later I believe)

Second switch needs to be in factory default

Third switch shouldn't be connected to Central before.

 

The steps I take are as follows:

First I add the serial number and mac to Central

second upload the correct variables to central

I unbox the switch

Connect it to the network

switch get's ip address, dns and ntp from network

Switch connects to Central, gets config and automaticly reboots

Unbox the second and third switch

connect the VSF cables

second and third switch reboot and become stack members.

 

In the variables you need to make sure all the mac addresses for all the switches in the stack are defined correctly

    "_sys_lan_mac":"00:fd:45:aa:bb:cc",
    "_sys_serial":"CN74xxxx",
    "_sys_stack_command": "vsf
   enable domain 1
   member 1
      type \"JL261A\" mac-address 00fd45-aabbcc
      priority 254
      link 1 1/1
      link 1 name \"I-Link1_1\"
      link 2 1/2
      link 2 name \"I-Link1_2\"
      exit
   member 2
      type \"JL261A\" mac-address 00fd45-bbccdd
      priority 128
      link 1 2/1
      link 1 name \"I-Link2_1\"
      link 2 2/2
      link 2 name \"I-Link2_2\"
      exit
   member 3
      type \"JL261A\" mac-address f40343-ddeeff
      priority 128
      link 1 3/1
      link 1 name \"I-Link3_1\"
      link 2 3/2
      link 2 name \"I-Link3_2\"
      exit
   port-speed 1g
   exit
",
    "_sys_template_header": "; hpStack_WC Configuration Editor; Created on release #WC.16.07.0003
; Ver #14:01.4f.f8.1d.9b.3f.bf.bb.ef.7c.59.fc.6b.fb.9f.fc.ff.ff.37.ef:02
", 

Second the template header needs to be the one for a stacked setup. single unit is different.

 

One thing I discovered during testing is the way Central handles the conversion from a stacked unit back to single unit. It doesn't.

 

So I you've tested and a stacked unit succesfully connected and you want ot test again. Make sure to disconnect the unit and after a while you can delete the stacked switch from central. Now you can start over again by puting the switch in factory default.

 

I hope this helps,

 

Regards,

 

Rens

I managed to get this working too, but I didn't have to specify each mac address in the vsf command (i.e. didn't need to do strict vsf provisioning).

 

Last issue I'm working through is that when a default switch connects to Central for the first time, Central pulls the variables for the switch and overwrites the variables I've set.

 

I suspect this is because I have missed some variables entries that Central expects.

"I hope my templates and variable files have helped you out - Dom Buonocore :-)"

 

Indeed they have! Thank you very much for this, I was templating a brand new Central deployment today and had a few queries around the Aruba documentation.

 

I have  found the actual doco to be very vague, seeing yours and understanding how to if/else and template properly has been a great help.

 

 

I am trying to import the template, it s giving me an error message:

 

Looks like you’ve got an extra ‘%if % statement in there somewhere or
you’ve forgotten to close it with an %endif%

Yes I just realised this the other day, sorry I zipped up a slightly older version of the tempalte than I thought it did.  I will up date the zip file in the next day or two.

Hi all,

 

Just wonder how to really ZTP an install for a customer...

 

switches are delivered int 16.05. he wants to stack unit witch 8 switches.

i can't find an easy way to do it for now.

well the easiest way is to not use templates and just use the GUI (non-template group).  However keep in mind that this will only allow basic configuration, so depending on just how complicated your configuration is you may need to use templates.  That said we are improviing the GUI configuration options all the time.

 

Note - I would still use the deteministic stacking method, which in this case would be 8 factory default switches.:

1 - racks all switches

2 - insert stacking modules

3 - cable up the stacking

4 - for now leave the uplink Ethernet interface disconneted (so it doesn't begin the ZTP process until you are ready)

 

then determine your stack method,  top/down or bottom/up.  I always use top/down - so switch member number 1 will be at the top and it will be the commander.  proceed as follows:

 

1 - power up the top switch and wait for it to fully boot - it will become member #1 and Commander

2 - power up the next switch down from the top and again let it boot - it will become meber #2 and Standby

3 - power up the next switch down and wait for it to boot - it will become a member

4 - repeat step 3 for all remaining switches in the stack one at a time,

 

Now once the stack is up an running plug in your upling and it will begin the ZTP process which could take up to about 15 mins or so depending on where it is in the ZTP sequence that it will attempted.

 

One other note since this is using 16.05 I would recommend you go to the latest code listed on Central which should be 16.08.  You should set this in the group as the compliance version and it will automatically upgrade the switch when it connects to Central.  Be cafefull here however, I am assuming this is the first switch connecting to the group in Central.  If there are already switches active in the group you need to consider this when set the firmware compliance for the group.  I hope this helps you out.

!!!!! CORRECTION TO MY LAST POST !!!!!!!!!!

 

Sorry folks, but yesterdays post is wrong.  I was thinking templates with standalone switches and talking templates with Stacking.  My bad, stacking is still only supported using templates not the UI as I suggested in my previous post.

 

So to answer your question: "Just wonder how to really ZTP an install for a customer.".  First we must keep in mind that ZTP (Zero Touch PROVISONING) is just that Provisioning. The idea that no one needs to get a console connected to the device in order to get it online and accessable, thus allow for detailed configuration.  It is not  ZTC or Zero Touch Configuration, at least not for the initial "golden configuration" setup.  someone still needs to build the actual runnning configuration in one way or another.

 

To answer the question you posted, I will assume ZTP with no access to the CLI of the stack and a limited skill set installer on site.  In this case have them follow the deterministic stacking method I described in my previous post.  On Central you would need a new Template Group (TG) and you shold have the switches in the stack subscribed in Central and assigned to this TG.  Once the commander of the stack connects to Central you will see all of the system (_sys_...) variables listed under TG > Variables.  you then can go to TG > Templates and create a new template.  As part of the new template creation use the pulldown in the "Select a device to import configuration" section and select the stack (should be listed by hostname).  then click on "Import Template".

 

This will add the template text into the template based on the current running config of the stack.  From here you can use the template to build out the real configuration for the stack by entering configuration text into the template, with a "save" they get pushed.  Remeber they get pushed to every stack that is using this template.

This is pretty much the easiest way to get a new stack into a new TG via a true ZTP at the site.

 

This obviously doesn't scale for large deployments, but is fine for smaller ones.  If you only have one stack your good here, if you have more than one stack then you would have to setup a TG for each stack.  If this doesn't work or scale for you then I suggest you explore the use of variables which my guides should assist you with.

Hi!

I'm still trying to build an intermediate/initial TG 'Stack Forming' for a VSF Stack that just enables VSF Stacking for the Commander and other VSF Stack Members, but until now I could not find a way how to do it. I'm having a rollout of 30 Stacks in the near future and can't believe that this is not possible.

 

Has anybody already a solution for this?

 

With kind regards

Manfred M.