Junos Fusion – Part II – Configuration, Administration and Operation

This is the second part of the Junos Fusion Series.

In the first part, I explained the concepts behind Junos Fusion.

Junos Fusion Enterprise means that the AD is EX9200 and the SDs can be EX2300, EX3400, EX4300 and QFX5100.

In the second part we will see how a Dual AD Junos Fusion Enterprise is configured, how the satellites can be added to Fusion and how to check if Fusion is working properly:

Diagram and initial state

Standalone and cluster satellite configuration

Software upgrade groups

Dual AD configuration

Standalone Junos to satellite conversion

Satellite to standalone Junos conversion

Operational verification

Diagram and initial state

These are the devices that will become components of the Junos Fusion, ADs and SDs:

There are two satellite clusters with EX3400 where each satellite has only one uplink port to one of the AD.

The EX4300 is dual-homed.

Because this is a Dual AD topology, there are few links between the two ADs for ICL and ICCP links.

The configuration related to standalone and cluster satellite is identical on the two AD, the difference being just the cascade ports reference as I did not use the same port numbering.

Standalone and cluster satellite configuration

All the configuration related to FPC ID and satellite(standalone and cluster) is done under “chassis satellite-management” stanza.

This is the configuration of LEFT cluster on EX9200-1:

[edit] 
root@EX9200-1#
cluster LEFT {
    cluster-id 1;
    cascade-ports xe-0/0/3;
    fpc 65 {
        member-id 1;
        system-id 7c:25:86:2d:74:85;
    }
    fpc 66 {
        member-id 2;
        system-id 7c:25:86:28:52:96;
    }
}

Observe that I used the system-id as identifier for the satellites.

As a comparison, the configuration is identical on the other AD, just the cascade port is different:

[edit]
root@EX9200-2#
cluster LEFT {
    cluster-id 1;
    cascade-ports xe-1/0/3;
    fpc 65 {
        member-id 1;
        system-id 7c:25:86:2d:74:85;
    }
    fpc 66 {
        member-id 2;
        system-id 7c:25:86:28:52:96;
    }
}

The other cluster is configured in an identical way making sure that the right cascade ports are used.

For the EX4300 satellite, the S/N is used to identify the satellite and assign the FPC number:

[edit]
root@EX9200-1#
fpc 70 {
    serial-number PG3715180043;
    cascade-ports xe-0/0/6;
}

The cascade ports on the ADs are configured like this:

[edit]
root@EX9200-1# show interfaces
xe-0/0/3 {
    cascade-port;
}
xe-0/0/6 {
    cascade-port;
}
xe-0/2/3 {
    cascade-port;
}

Again, the same configuration has to be applied on the second AD making sure that the right cascade ports are used.

Software upgrade groups

The software upgrade group is a group of devices meant to run the same SNOS. The software upgrade groups are managed from the AD.

For the standalone satellites, you can add one or more satellites in an upgrade group.

In case of the satellite cluster, an upgrade group is automatically created and it has the name of the satellite cluster(in our cases, it can be LEFT or RIGHT).

There are two steps related to the upgrade groups: defining the upgrade group members(just in standalone satellite case) and associating the upgrade group with the SNOS.

This is required to defined the upgrade group for FPC70(EX4300):

[edit]
root@EX9200-1#
upgrade-groups {
    SAT-70 {
        satellite 70;
    }
}

The second step is to associated the SNOS to the upgrade group.

This is to associate the SNOS with the standalone device for which I defined the upgrade group:

[edit]
root@EX9200-1# run request system software add upgrade-group SAT-70 /var/tmp/satellite-3.1R1-S2.0-signed.tgz
Validating image /var/tmp/satellite-3.1R1-S2.0-signed.tgz
Metatags extracted
Satellite package version is '3.1R1-S2.0'
Using existing package
Provisioning group <SAT-70> with satellite package version '3.1R1-S2.0'
Request processed successfully

[edit]
root@EX9200-1#

This is for the satellite cluster(the name of the upgrade group is the satellite cluster name):

[edit]
root@EX9200-1# run request system software add upgrade-group RIGHT /var/tmp/satellite-3.1R1-S2.0-signed.tgz
Validating image /var/tmp/satellite-3.1R1-S2.0-signed.tgz
Metatags extracted
Satellite package version is '3.1R1-S2.0'
Unpacking package
Provisioning group <RIGHT> with satellite package version '3.1R1-S2.0'
Request processed successfully

[edit]
root@EX9200-1#

Remember that these above two steps have to be repeated on the other AD.

A section later in the article will show how the satellites are actually converted to run SNOS.

Dual AD configuration

In case of a Dual AD topology, there is an MC-LAG group that uses ICCP to communicate between the two ADs.

The ICCP is enabled by a redundancy-group that contains the two ADs along with the satellites or the satellite clusters.

This is the complete configuration of the redundancy group on EX9200-1:

[edit]
root@EX9200-1#
redundancy-groups {
    chassis-id 1;
    jfe {
        redundancy-group-id 1;
        peer-chassis-id 2 {
            inter-chassis-link ae0;
            no-auto-iccp-provisioning;
        }
        satellite 70;
        cluster LEFT;
        cluster RIGHT;
    }
}
[edit]
root@EX9200-1#

And on the second AD:

[edit]
root@EX9200-2#
redundancy-groups {
    chassis-id 2;
    jfe {
        redundancy-group-id 1;
        peer-chassis-id 1 {
            inter-chassis-link ae0;
            no-auto-iccp-provisioning;
        }
        satellite 70;
        cluster LEFT;
        cluster RIGHT;
    }
}
[edit]
root@EX9200-2#

Standalone Junos to satellite conversion

Before trying to convert a device running Junos to run SNOS, you should zeroize the device and after has come back up, make sure that the uplink ports on the device are not configured as VC ports(this is applicable only to EX3400 and EX4300).

There are three ways to convert a standalone device to a satellite.

The first one is autoconversion, it is the recommended one and the software is installed automatically when the SD is connected to the AD.

This is how you can enable autoconversion for one or more satellites:

[edit]
root@EX9200-1# show chassis
    auto-satellite-conversion {
        satellite 67-68;
    }


[edit]
root@EX9200-1#

Once the device is connected and is part of the satellites list enabled for auto-conversion , the following message from the logs of SD is indicating that the auto-conversion started:

Jun 29 08:42:04   l2cpd[7230]: lldp_chassis_mode_change_processing: executing </usr/libexec/ui/satellite-mode-change-check -i xe-0/2/0 -d 10.16.32.13 -s 10.16.32.14/30 -f satellite-groups/LEFT/arm563xx/host.tgz -b 124502656 -u ftp -m dec2da2ebfa6060c0e5d9e3b9a7c3c34  >

The second option is to manually install the SNOS on the satellite and this is how is done when the AD has a direct link to the SD. Let’s suppose that I want EX3400-2 from the topology to become FPC66.

In this case, only AD2 has a direct link(through xe-1/0/3) and this is the command:

[edit]

root@EX9200-2# run request chassis satellite interface xe-1/0/3 device-mode satellite
Mode change request initiated on interface xe-1/0/3
Installing satellite-groups/LEFT/arm563xx/host.tgz image on this device

[edit]
root@EX9200-2#

In case of a cluster that has only one link to AD that specific SD that needs to be converted is not directly connected to the AD, then the above command can be changed to reflect an inter-SD interface.

Let’s suppose that FPC66 does not have a link towards AD2 and that EX3400-1(FPC65) is already converted. Then FPC66 can be converted from AD1 and reference the interface between FPC65 and FPC66(xe-0/2/2) which on FPC65 becomes xe-65/2/2:

[edit]
root@EX9200-1# run request chassis satellite interface xe-65/2/2 device-mode satellite
Mode change request initiated on interface xe-65/2/2
Installing satellite-groups/RIGHT/arm563xx/host.tgz image on this device

[edit]
root@EX9200-1#

And the last method is to preinstall SNOS on the device and this is done like this:

{master:0}

root@EX3400-1> request chassis device-mode satellite /var/tmp/satellite-ex-3400-3.1R1-S2.0-signed.tgz
Extracting image /var/tmp/satellite-ex-3400-3.1R1-S2.0-signed.tgz
Metatags extracted
Satellite package version is '3.1R1-S2.0'
Using host.tgz for arm563xx from the package
all conditions passed
Proceeding with conversion to satellite device

 

Satellite to standalone Junos conversion

You can convert back a device running SNOS to run again Junos.

For EX4300 and QFX5100, this command can be used to remove a satellite from Junos Fusion.

[edit]
root@EX9200-1# run request chassis satellite install /var/tmp/jinstall-ex-4300-14.1X53-D45.3-domestic-signed.tgz fpc-slot 70
Convert satellite device to Junos standalone device? [yes,no] (no) yes

Verified jinstall-ex-4300-14.1X53-D45.3-domestic.tgz signed by PackageProductionEc_2017 method ECDSA256+SHA256
Initiating Junos standalone conversion on device 70...
Response from device:
  Conversion started


[edit]
root@EX9200-1#

For EX3400 and EX2300, there is specific procedure to format the filesystem of the SD and then reinstallation from loader.

This procedure can be found here.

Operational verification

At this moment, all five satellites should be added to the Junos Fusion setup.

Let’s check the status of the SD to AD links. As you can see from the diagram, AD1 is directly connected only to FPC65, 68 and 70:

[edit]
root@EX9200-1# run show chassis satellite neighbor
Interface   State      Port Info   System Name  Model           SW Version
xe-0/0/6    Two-Way    xe-0/2/2    sd70         EX4300-24T      3.1R1-S2.0
xe-0/2/3    Two-Way    xe-0/2/0    sd68         EX3400-24P      3.1R1-S2.0
xe-0/0/3    Two-Way    xe-0/2/0    sd65         EX3400-48P      3.1R1-S2.0

[edit]
root@EX9200-1#

AD2 will show similar output, except for the interface names which should reflect how it is connected to the SDs:

[edit]

root@EX9200-2# run show chassis satellite neighbor
Interface   State      Port Info   System Name  Model           SW Version
xe-1/0/6    Two-Way    xe-0/2/3    sd70         EX4300-24T      3.1R1-S2.0
xe-1/2/3    Two-Way    xe-0/2/0    sd67         EX3400-48P      3.1R1-S2.0
xe-1/0/3    Two-Way    xe-0/2/0    sd66         EX3400-24P      3.1R1-S2.0

[edit]
root@EX9200-2#

You can check the status of the cascade port and the internal Fusion interfaces(note the 65, 66, and so on interfaces):

[edit]
root@EX9200-1# run show chassis satellite interface

Interface         State        Type
ae0               Dn           ICL

et-4/0/0          Up           Child-ICL

et-4/0/1          Up           Child-ICL

lo0               Up           Loopback

sd-65/0/0         Up           Satellite

sd-66/0/0         Up           Satellite

sd-67/0/0         Up           Satellite

sd-68/0/0         Up           Satellite

sd-70/0/0         Up           Satellite

xe-0/0/3          Up           Cascade

xe-0/0/6          Up           Cascade

xe-0/2/3          Up           Cascade


[edit]
root@EX9200-1#

You can check the software upgrade groups. This is for one of the satellite clusters:

[edit]
root@EX9200-1# run show chassis satellite upgrade-group RIGHT
                                             Group               Device
Group         Sw-Version                     State          Slot State

RIGHT         3.1R1-S2.0                     in-sync         67  version-in-sync
                                                             68  version-in-sync

[edit]
root@EX9200-1#

You can also check the satellite clusters status:

[edit]
root@EX9200-1# run show chassis satellite-cluster

Cluster Name: LEFT
    Number of devices provisioned: 2
    Number of devices present: 2
    Number of devices unprovisioned: 0
    Number of devices misconfig/miwired: 0
    Number of devices online: 2
    Number of devices offline: 0

         Device                      Local        Remote       Interface

  Slot   State         Distance      Interface    Interface    State
  66     Online        1   [via 65 ] xe-66/2/2    xe-65/2/2    present
  65     Online        0             xe-65/2/0    xe-0/0/3     online
                                     xe-65/2/2    xe-66/2/2    present


Cluster Name: RIGHT
    Number of devices provisioned: 2
    Number of devices present: 2
    Number of devices unprovisioned: 0
    Number of devices misconfig/miwired: 0
    Number of devices online: 2
    Number of devices offline: 0

         Device                      Local        Remote       Interface
  Slot   State         Distance      Interface    Interface    State
  68     Online        0             xe-68/2/0    xe-0/2/3     online
                                     xe-68/2/2    xe-67/2/2    present
  67     Online        1   [via 68 ] xe-67/2/2    xe-68/2/2    present

[edit]
root@EX9200-1#


[edit]
root@EX9200-2# run show chassis satellite-cluster

Cluster Name: LEFT
    Number of devices provisioned: 2
    Number of devices present: 2
    Number of devices unprovisioned: 0
    Number of devices misconfig/miwired: 0
    Number of devices online: 2

    Number of devices offline: 0

         Device                      Local        Remote       Interface
  Slot   State         Distance      Interface    Interface    State
  66     Online        0             xe-66/2/0    xe-1/0/3     present
                                     xe-66/2/2    xe-65/2/2    present
  65     Online        1   [via 66 ] xe-65/2/2    xe-66/2/2    present

Cluster Name: RIGHT
    Number of devices provisioned: 2
    Number of devices present: 2
    Number of devices unprovisioned: 0
    Number of devices misconfig/miwired: 0
    Number of devices online: 2
    Number of devices offline: 0

         Device                      Local        Remote       Interface
  Slot   State         Distance      Interface    Interface    State
  68     Online        1   [via 67 ] xe-68/2/2    xe-67/2/2    present
  67     Online        0             xe-67/2/0    xe-1/2/3     present
                                     xe-67/2/2    xe-68/2/2    present

[edit]
root@EX9200-2#

Based on this above output, everything is in order with the Junos Fusion and you can start connecting hosts on the setup.

This would be all about what is need to bring up a Junos Fusion setup.

In the next part of the series, various devices will be connected on this Junos Fusion to get some traffic running through the setup and check several things.

I hope you found this post interesting.

The following two tabs change content below.

Paris ARAU

Paris ARAU is a networking professional with strong background on routing and switching technologies. He is a holder of CCIE R&S and dual JNCIE(SP and ENT). The day to day work allows him to dive deeply in networking technologies. Part of the continuously training, he is focusing on Software Defined Network and cloud computing.

Comments

This post currently has one response

Leave a Reply to Junos Fusion – Part III – Satellite commands and traffic forwarding | Cancel reply

Your email address will not be published. Required fields are marked *

Sidebar



%d bloggers like this: