Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Other MC-LAG Configurations

 

The following sections describe the configuration of active-active bridging and VRRP over IRB in a multichassis link aggregation (MC-LAG) :

Configuring MC-LAG

An MC-LAG is composed of logical link aggregation groups (LAGs) and is configured under the [edit interfaces aeX] hierarchy, as follows:

Note

The mode active-active statement is valid only if encapsulation is an ethernet-bridge or extended-vlan-bridge.

Use the mode statement to specify if an MC-LAG is active-standby or active-active. If the ICCP connection is UP and ICL comes UP, the router configured as standby brings up the multichassis aggregated Ethernet interfaces shared with the peer.

Using multi-chassis-protection at the physical interface level is a way to reduce the configuration at the logical interface level.

If there are n+1 logical interfaces under ae0, from ae0.0 through ae0.n, there are n+1 logical interfaces under ge-0/0/0 as well, from ge-0/0/0.0 through ge-0/0/0.n, each ge-0/0/0 logical interface is a protection link for the ae0 logical interface.

Note

A bridge domain cannot have multichassis aggregated Ethernet logical interfaces that belong to different redundancy groups.

Configuring the Interchassis Link-Protection Link

The interchassis link-protection link (ICL-PL) provides redundancy when a link failure (for example, an MC-LAG trunk failure) occurs on one of the active links. The ICL-PL is an aggregated Ethernet interface. You can configure only one ICL-PL between the two peers, although you can configure multiple MC-LAGs between them.

The ICL-PL assumes that interface ge-0/0/0.0 is used to protect interface ae0.0 of MC-LAG-1:

The protection interface can be an Ethernet type interface such as ge or xe, or an aggregated Ethernet (ae) interface.

Configuring Multiple Chassis

A top-level hierarchy is used to specify a multichassis-related configuration, as follows:

This example specifies interface ge-0/0/0 as the multichassis protection interface for all the multichassis aggregated Ethernet interfaces which are also part of the peer. This can be overridden by specifying protection at the physical interface level and the logical interface level.

Configuring the Service ID

You must configure the same unique network-wide configuration for a service in the set of PE routers providing the service. You can configure the service IDs under the level of the hierarchies shown in the following examples:

Global Configuration (Default Logical System)

Logical Systems

Note

Using a service name per bridge domain is not supported.

The bridge-level service ID is required to link related bridge domains across peers, and should be configured with the same value. The service-id values share the name space across all bridging and routing instances, and across peers. Thus, duplicate values for service IDs are not permitted across these entities.

The service ID at the bridge domain level is mandatory for type non-single VLAN bridge domains. The service ID is optional for bridge domains with a VLAN identifier (VID) defined. If no service ID is defined in the latter case, it is picked up from the service ID configuration for that routing instance.

Note

When this default routing instance (or any other routing instance) which contains a bridge domain containing a multichassis aggregated Ethernet interface is configured, you must configure a global-level switch-options service-id number, irrespective of whether the contained bridge domains have specific service IDs configured.

In the sample illustration shown in Figure 1, network routing instances N1 and N2, both for the same service ID, are configured with same service ID in both N1 and N2. Use of a name string instead of a number is not supported.

Figure 1: N1 and N2 for the Same Service with Same Service ID
N1 and N2 for the Same Service with Same
Service ID

The following configuration restrictions apply:

  • The service ID must be configured when the multichassis aggregated Ethernet interface is configured and a multichassis aggregated Ethernet logical interface is part of a bridge domain. This requirement is enforced.

  • A single bridge domain cannot correspond to two redundancy group IDs.

    In Figure 2, it is possible to configure a bridge domain consisting of logical interfaces from two multichassis aggregated Ethernet interfaces and map them to a separate redundancy group ID, which is not supported. A service must be mapped one-to-one with the redundancy group providing the service. This requirement is enforced.

    Figure 2: Bridge Domain with Logical Interfaces from Two Multichassis Aggregated Ethernet Interfaces
    Bridge Domain
with Logical Interfaces from Two Multichassis Aggregated Ethernet
Interfaces

To display the multichassis aggregated Ethernet configuration, use the show interfaces mc-ae command. For more information, see the CLI Explorer.

Configuring IGMP Snooping for Active-Active MC-LAG

For the multicast solution to work, the following must be configured:

Note

Snooping with active-active MC-LAG is only supported in non-proxy mode.

Configuring IGMP Snooping in MC-LAG Active-Active Mode

You can use the bridge-domain statement's service-id option to specify the multichassis aggregated Ethernet configuration on MX240 routers, MX480 routers, MX960 routers and QFX Series switches.

  • The service-id statement is mandatory for non-single VLAN type bridge domains (none, all, or vlan-id-tags:dual).

  • The statement is optional for bridge domains with a VID defined.

  • The bridge-level service-id is required to link related bridge domains across peers, and should be configured with the same value.

  • The service-id values share the name space across all bridging and routing instances, and across peers. Thus, duplicate service-id values are not permitted across these entities.

  • A change of bridge service-id is considered catastrophic, and the bridge domain is changed.

This procedure allows you to enable or disable the replication feature.

To configure IGMP snooping in MC-LAG active-active mode :

  1. Use the multichassis-lag-replicate-state statement at the [edit multicast-snooping-options] hierarchy level in the master instance.
  2. Use the interface icl-intf-name statement at the [edit protocols igmp-snooping] hierarchy level, as shown in the following example:
    Note

    For QFX use the following configuration:

    The interchassis link, interface icl-intf-name, of the learning domain should be a router-facing interface.

In a multichassis link aggregation (MC-LAG) topology with active-standby mode, a link switchover happens only if the active node goes down. You can override this default behavior by configuring an MC-LAG interface in active-standby mode to automatically revert to a preferred node. With this configuration, you can trigger a link switchover to a preferred node even when the active node is available. For example, consider two nodes, PE1 and PE2. PE1 is configured in active mode making it a preferred node, and PE2 is configured in active-standby mode. In case of any failure at PE1, PE2 becomes the active node. However, as soon as PE1 is available again, an automatic link switchover is triggered and the control is switched back to PE1 even though PE2 is active.

You can configure the link switchover in two modes: revertive and nonrevertive. In revertive mode, the link switchover is triggered automatically by using the request interface mc-ae switchover operational mode command. In nonrevertive mode, the link switchover must be triggered manually by the user. You can also configure a revert time that triggers an automatic or manual switchover when the specified timer expires.

Note
  • If two MC-LAG devices configured in an active-standby setup using Inter-Chassis Control Protocol (ICCP) and nonrevertive switchcover mode is configured on the aggregated Ethernet interfaces of both the MC-LAGs and when both mc-ae interfaces are linked together with a Layer 2 circuit local-switching configuration, we recommend that you perform switchover by entering the request interface mc-ae switchover (immediate mcae-id mcae-id | mcae-id mcae-id) operational mode command on only one of the aggregated Ethernet interfaces of an MC-LAG device. This command can be issued only on MC-LAG devices that are configured as active nodes (by using the status-control active statement at the [edit interfaces aeX aggregated-ether-options mc-ae] hierarchy level).

  • In nonrevertive switchover mode, when an MC-LAG interface transitions to the standby state because of an MC-LAG member link failure and another MC-LAG interface moves to the active state, the MC-LAG in standby state remains in that state until the MC-LAG in active state encounters a failure and returns to the active state.

  • If you perform a switchover on both the aggregated Ethernet interfaces in the MC-LAG, because of Layer 2 circuit local-switching configuration, a switchover on one aggregated Ethernet interface triggers a switchover on the other aggregated Ethernet interface. In such a scenario, both the aggregated Ethernet interfaces move to the standby state and then transition back to the active state. Therefore, you must not perform switchover on both the aggregated Ethernet interfaces in an MC-LAG at the same time.

  • Layer 2 circuit configuration and VPLS functionalities are not supported if you configure an MC-LAG interface to be in revertive switchover mode. You can configure the revertive or nonrevertive switchover capability only if two MC-LAG devices are configured in an active-standby setup (one device set as an active node by using the status-control standby statement and the other device set as a standby node by using the status-control active statement at the [edit interfaces aeX aggregated-ether-options mc-ae] hierarchy level. You can perform a switchover by entering the request interface mc-ae switchover (immediate mcae-id mcae-id | mcae-id mcae-id) operational mode command only on MC-LAG devices configured as active nodes.

To configure the link switchover mechanism on an MC-LAG interface:

  1. Configure the link switchover in revertive mode.
  2. (Optional) Configure the link switchover in nonrevertive mode.
  3. Configure the revert time.
  4. Trigger manual switchover.

You can use the show interfaces mc-ae revertive-info command to view the switchover configuration information.

In an MC-LAG network, an MC-LAG client link without Link Access Control Protocol (LACP) configuration remains down and cannot be accessed by the MC-LAG switches.

To ensure that the client device with limited LACP capability is up and accessible on the MC-LAG network, configure one of the aggregated Ethernet links or interfaces on a MC-LAG switch to be up by using the force-up statement at the appropriate hierarchy level on your device:

  • [edit interfaces interface-name aggregated-ether-options lacp]

  • [edit interfaces interface-name ether-options 802.3ad lacp]

You can configure the force-up feature on the MC-LAG switches in either active mode or standby mode. However, in order to prevent duplicate traffic and packet drops, you configure the force-up feature only on one aggregated Ethernet link of the MC-LAG switches . If multiple aggregated Ethernet links are up on the MC-LAG switches with force-up feature configured, then the device selects the link based on the LACP port ID and port priority. The port with the lowest priority is given preference. In case of two ports with the same priority, the one with the lowest port ID is given preference.

Note

The force-up option is not supported on QFX10002 switches.

Note

On the QFX5100 switch, you can configure the force-up feature in Link Aggregation Control Protocol (LACP) on the MC-LAG switches starting with Junos OS Release 14.1X53-D10.

Note
  • If LACP comes up partially in the MC-LAG network—that is, it comes up on one of the MC-LAG switches and does not comes up on other MC-LAG switches—the force-up feature is disabled.

Increasing ARP and Network Discovery Protocol Entries for Enhanced MC-LAG and Layer 3 VXLAN Topologies

Understanding the Need for an Increase in ARP and Network Discovery Protocol (NDP) Entries

The number of ARP and NDP entries has increased to 256,000 to improve enhanced MC-LAG and Layer 3 VXLAN scenarios.

Here are some enhanced MC-LAG and Layer 3 VXLAN scenarios in which an increase in ARP and NDP entries is needed:

  • Enhanced MC-LAG topology with a large number of MC-AE interfaces that contain a large number of members per chassis.

  • Non-collapsed spine-leaf topology, in which the leaf devices operate as Layer 2 gateways and handle traffic within the VXLAN, and the spine devices operate as Layer 3 gateways and handle traffic between the VXLANs using IRB interfaces.

    In this scenario, the increase in ARP and NDP entries is needed at the spine level.

  • Leaf devices that operate as both Layer 2 and Layer 3 gateways.

    In this scenario, the transit spine devices provide Layer 3 routing functioning only, and the increased number of ARP and NDP entries in needed only at the leaf level.

Increasing ARP and Network Discovery Protocol Entries for Enhanced MC-LAG Using IPv4 Transport

To increase the number of ARP and NDP entries using IPv4 transport, follow these steps. We recommend that you use the values provided in this procedure for optimal performance:

  1. Enable the arp-enhanced-scale statement:
    [edit system]

    user@switch# set arp-enhanced-scale

  2. Configure the maximum number of routes to be stored in the ARP cache.
    [edit system]

    user@switch# set arp-system-cache-limit number

    For example:

    [edit system]

    user@switch# set arp-system-cache-limit 2000000

  3. Configure the amount of time between ARP updates.
    [edit system]

    user@switch# set arp aging-timer minutes

    For example:

    [edit system]

    user@switch# set arp aging-timer 20

  4. Enable enhanced convergence on the MC-AE interface:
    [edit interfaces]

    user@switch# set interface-name aggregated-ether-options mc-ae enhanced-convergence

  5. Enable enhanced convergence on the IRB interface that you have configured as part of an MC-AE.
    [edit interfaces]

    user@switch# set irb unit number enhanced-convergence

  6. Specify the amount of time that elapses before the MAC table entries are timed out and entries are deleted from the table.
    [edit protocols l2-learning]

    user@switch# set global-mac-table-aging-time seconds

    For example:

    [edit protocols l2-learning]

    user@switch# set global-mac-table-aging-time 3600

  7. Specify the amount time that elapses before the entries in the MAC-IP bindings database are timed out and deleted.
    [edit protocols l2-learning]

    user@switch# set global-mac-ip-table-aging-timeseconds

    For example:

    [edit protocols l2-learning]

    user@switch# set global-mac-ip-table-aging-time 1200

  8. Reboot the device in order for these changes to take effect.
    user@switch# request system reboot

Increasing ARP and Network Discovery Protocol Entries for Enhanced MC-LAG Using IPv6 Transport

To increase the number of ARP and Network Discovery Protocol entries using IPv6 transport. We recommend that you use the values provided in this procedure for optimal performance:

  1. Enable the arp-enhanced-scale statement:
    [edit system]

    user@switch# set arp-enhanced-scale

  2. Specify the maximum system cache size for IPv6 next-hop addresses.
    [edit system]

    user@switch# set nd-system-cache-limitnumber

    For example:

    [edit system]

    user@switch# set nd-system-cache-limit 2000000

  3. Set the stale timer for IPv6 neighbor reachability confirmation.
    [edit interfaces]

    user@switch# set irb unit 1 family inet6 nd6-stale-timeseconds

    For example:

    [edit interfaces]

    user@switch# set irb unit 1 family inet6 nd6-stale-time 1200

  4. Enable enhanced convergence on the MC-AE interface:
    [edit interfaces]

    user@switch# set interface-name aggregated-ether-options mc-ae enhanced-convergence

  5. Enable enhanced convergence on the IRB interface that you have configured as part of an MC-AE.
    [edit interfaces]

    user@switch# set irb unit number enhanced-convergence

  6. Specify the amount of time that elapses before the MAC table entries are timed out and entries are deleted from the table.
    [edit protocols l2-learning]

    user@switch# set global-mac-table-aging-time seconds

    For example:

    [edit protocols l2-learning]

    user@switch# set global-mac-table-aging-time 3600

  7. Specify the amount time that elapses before the entries in the MAC-IP bindings database are timed out and deleted.
    [edit protocols l2-learning]

    user@switch# set global-mac-ip-table-aging-timeseconds

    For example:

    [edit protocols l2-learning]

    user@switch# set global-mac-ip-table-aging-time 1200

  8. Reboot the device in order for these changes to take effect.
    user@switch# request system reboot

Increasing ARP for EVPN-VXLAN Gateway for Border-Leaf in Edge Routed Bridge (ERB) or Spine in Centrally Routed Bridge (CRB) for IPv4 Tenant Traffic

To increase the number of ARP entries using IPv4 tenant traffic, follow these steps. We recommend that you use the values provided in this procedure for optimal performance:

  1. Enable the arp-enhanced-scale statement:
    [edit system]

    user@switch# set arp-enhanced-scale

  2. Configure the maximum number of routes to be stored in the ARP cache.
    [edit system]

    user@switch# set arp-system-cache-limit number

    For example:

    [edit system]

    user@switch# set arp-system-cache-limit 2000000

  3. Configure the amount of time between ARP updates.
    [edit system]

    user@switch# set arp aging-timer minutes

    For example:

    [edit system]

    user@switch# set arp aging-timer 20

  4. On QFX10002-60C devices, configure the amount of time between ARP updates.
    [edit system]

    user@switch# set arp aging-timer minutes

    For example:

    [edit system]

    user@switch# set arp aging-timer 900

  5. Specify the amount of time that elapses before the MAC table entries are timed out and entries are deleted from the table.
    [edit protocols l2-learning]

    user@switch# set global-mac-table-aging-time seconds

    For example:

    [edit protocols l2-learning]

    user@switch# set global-mac-table-aging-time 3600

  6. Specify the amount time that elapses before the entries in the MAC-IP bindings database are timed out and deleted.
    [edit protocols l2-learning]

    user@switch# set global-mac-ip-table-aging-timeseconds

    For example:

    [edit protocols l2-learning]

    user@switch# set global-mac-ip-table-aging-time 1200

  7. On QFX10002-60C devices, specify the amount time that elapses before the entries in the MAC-IP bindings database are timed out and deleted.
    [edit protocols l2-learning]

    user@switch# set global-mac-ip-table-aging-timeseconds

    For example:

    [edit protocols l2-learning]

    user@switch# set global-mac-ip-table-aging-time 900

  8. For each leaf device, specify the amount of time that elapses before the MAC table entries are timed out and entries are deleted from the table.
    [edit protocols l2-learning]

    user@switch# set global-mac-table-aging-time seconds

    For example:

    [edit protocols l2-learning]

    user@switch# set global-mac-table-aging-time 3600

  9. On QFX10002-60C devices, for each leaf device, specify the amount of time that elapses before the MAC table entries are timed out and entries are deleted from the table.
    [edit protocols l2-learning]

    user@switch# set global-mac-table-aging-time seconds

    For example:

    [edit protocols l2-learning]

    user@switch# set global-mac-table-aging-time 1200

  10. Reboot the device in order for these changes to take effect.
    user@switch# request system reboot

Increasing ARP and Network Discovery Protocol Entries for EVPN-VXLAN gateway for Border-Leaf in Edge Routed Bridge (ERB) or Spine in Centrally Routed Bridge (CRB) for IPv6 Tenant Traffic

To increase the number of ARP and Network Discovery Protocol entries using IPv4 and IPv6 tenant traffic, follow these steps. We recommend that you use the values provided in this procedure for optimal performance:

  1. Enable the arp-enhanced-scale statement:
    [edit system]

    user@switch# set arp-enhanced-scale

  2. Specify the maximum system cache size for IPv6 next-hop addresses.
    [edit system]

    user@switch# set nd-system-cache-limitnumber

    For example:

    [edit system]

    user@switch# set nd-system-cache-limit 2000000

  3. Set the stale timer for IPv6 neighbor reachability confirmation.
    [edit interfaces]

    user@switch# set irb unit 1 family inet6 nd6-stale-timeseconds

    For example:

    [edit interfaces]

    user@switch# set irb unit 1 family inet6 nd6-stale-time 1200

  4. Specify the amount of time that elapses before the MAC table entries are timed out and entries are deleted from the table.
    [edit protocols l2-learning]

    user@switch# set global-mac-table-aging-time seconds

    For example:

    [edit protocols l2-learning]

    user@switch# set global-mac-table-aging-time 3600

  5. Specify the amount time that elapses before the entries in the MAC-IP bindings database are timed out and deleted.
    [edit protocols l2-learning]

    user@switch# set global-mac-ip-table-aging-timeseconds

    For example:

    [edit protocols l2-learning]

    user@switch# set global-mac-ip-table-aging-time 1200

  6. For each leaf device, specify the amount of time that elapses before the MAC table entries are timed out and entries are deleted from the table.
    [edit protocols l2-learning]

    user@switch# set global-mac-table-aging-time seconds

    For example:

    [edit protocols l2-learning]

    user@switch# set global-mac-table-aging-time 3600

  7. For each leaf device, specify the amount of time that elapses before the MAC table entries are timed out and entries are deleted from the table.
    [edit protocols l2-learning]

    user@switch# set global-mac-table-aging-time seconds

    For example:

    [edit protocols l2-learning]

    user@switch# set global-mac-table-aging-time 1200

  8. Reboot the device in order for these changes to take effect.
    user@switch# request system reboot

Synchronizing and Committing Configurations

To propagate, synchronize, and commit configuration changes from one device (Junos Fusion Provider Edge, Junos Fusion Enterprise, EX Series switches, and MX Series routers) to another, perform following tasks:

Configure Devices for Configuration Synchronization

Configure the hostnames or IP addresses for the devices that will be synchronizing their configurations as well as the usernames and authentication details for the users administering configuration synchronization. Additionally, enable a NETCONF connection so that the devices can synchronize their configurations. Secure Copy Protocol (SCP) copies the configurations securely between the devices.

For example, if you have a local device named Switch A and want to synchronize a configuration with remote devices named Switch B, Switch C, and Switch D, you need to configure the details for Switch B, Switch C, and Switch D on Switch A.

To specify the configuration details:

  1. On the local device, specify the configuration details for the remote device.
    [edit system commit]
    user@switch# set peers hostname user username authentication password string

    For example, if the local device is Switch A, and the remote devices are Switch B, Switch C, and Switch D:

    [edit system commit]
    user@Switch A# set peers Switch B user admin-SwitchB authentication "$ABC123"
    user@Switch A# set peers Switch C user admin-SwitchC authentication "$ABC123"
    user@Switch A# set peers Switch D user admin-SwitchD authentication "$ABC123"

    The password string is stored as an authenticated password string.

    The output for Switch A is as follows:

  2. Statically map Switch A to Switch B, Switch C, and Switch D.

    For example:

    [edit system ]
    user@Switch A# set static-host-mapping Switch A inet 10.92.76.2
    user@Switch A# set static-host-mapping Switch B inet 10.92.76.4
    user@Switch A# set static-host-mapping Switch C inet 10.92.76.6
    user@Switch A# set static-host-mapping Switch D inet 10.92.76.8

    The output is as follows:

  3. Enable a NETCONF connection using SSH between all devices (Switch A, Switch B, Switch C, and Switch D).

    For example:

    [edit]
    user@Switch A# set system services netconf ssh
    [edit]
    user@Switch B# set system services netconf ssh
    [edit]
    user@Switch C# set system services netconf ssh
    [edit]
    user@Switch D# set system services netconf ssh

Create a Global Configuration Group

Create a global configuration group the local and remote devices.

To create a global configuration group:

  1. Specify the devices that will receive the configuration:
    [edit]
    user@switch# set groups <name of group> when peers [<name of local peer> <name of remote peer>]

    For example:

    [edit]
    user@switch# set groups global when peers [Switch A Switch B Switch C Switch D]
  2. Create the global configuration that will be shared between the devices.

    For example:

The output for the configuration is as follows:

Create a Local Configuration Group

Create a local configuration group for the local device.

To create a local configuration group:

  1. Specify the local configuration group name.
    [edit]
    user@switch# set groups name of group when peers [name of local peer]

    For example:

    [edit]
    user@switch# set groups local when peers [Switch A]
  2. Include the local configuration that will be used by the local device.

    For example:

The output for the configuration is as follows:

Create a Remote Configuration Group

Create a remote configuration group for remote devices.

To create a remote configuration group:

  1. Specify the remote configuration group name.
    [edit]
    user@switch# set groups name of group when peers [names of remote peers]

    For example:

    [edit]
    user@switch# set groups remote when peers [Switch B Switch C Switch D]
  2. Include the remote configuration that will be used by the remote devices.

    For example:

The output for the configuration is as follows:

Create Apply Groups for the Local, Remote, and Global Configurations

Create apply groups so changes in the configuration are inherited by local, remote, and global configuration groups. List the configuration groups in order of inheritance, where the configuration data in the first configuration group takes priority over the data in subsequent configuration groups.

When you apply the configuration groups and issue the commit peers-synchronize command, changes are committed on both the local and remote devices. If there is an error on any of the devices, an error message is issued, and the commit is terminated.

To apply the configuration groups:

  1. Specify the names of the configuration groups.
    [edit]
    user@switch# set apply-groups [<name of global configuration group> <name of local configuration group> <name of remote configuration group>]

    For example:

    [edit]
    user@switch# set apply-groups [ global local remote ]

    The output for the configuration is as follows:

    apply-groups [ global local remote ];

Synchronizing and Committing Configurations

Note

The commit at <"string"> command is not supported when performing configuration synchronization.

You can enable the peers-synchronize statement on the local (or requesting) device to copy and load its configuration to the remote (or responding) device by default. You can alternatively issue the commit peers-synchronize command.

  • Configure the commit command on the local (or requesting) to automatically perform a peers-synchronize action between devices.

    [edit]
    user@switch# set system commit peers-synchronize

    The output for the configuration is as follows:

  • Issue the commit peers-synchronize command on the local (or requesting) device.

    [edit]
    user@switch# commit peers-synchronize

Troubleshooting Remote Device Connections

Problem

Description:

When you issue the commit command, the system issues the following error message:

root@Switch A# commit
error: netconf: could not read hello error: did not receive hello packet from server error: Setting up sessions for peer: 'Switch B' failed warning: Cannot connect to remote peers, ignoring it

The error message shows that there is a NETCONF connection issue between the local device and remote device.

Resolution

  1. Verify that the SSH connection to the remote device (Switch B) is working.
    root@Switch A# ssh root@Switch B
    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is 21:e8:5a:58:bb:29:8b:96:a4:eb:cc:8a:32:95:53:c0. Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /root/.ssh/known_hosts:1 ECDSA host key for Switch A has changed and you have requested strict checking. Host key verification failed.

    The error message shows that the SSH connection is not working.

  2. Delete the key entry in the /root/.ssh/known_hosts:1 directory and try to connect to Switch B again.
    root@Switch A# ssh root@Switch B
    The authenticity of host 'Switch B (10.92.76.235)' can't be established. ECDSA key fingerprint is 21:e8:5a:58:bb:29:8b:96:a4:eb:cc:8a:32:95:53:c0. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'Switch A,10.92.76.235' (ECDSA) to the list of known hosts. Password: Last login: Wed Apr 13 15:29:58 2016 from 192.168.61.129 - JUNOS 15.1I20160412_0929_dc-builder Kernel 64-bit FLEX JNPR-10.1-20160217.114153_fbsd-builder_stable_10 At least one package installed on this device has limited support. Run 'file show /etc/notices/unsupported.txt' for details.

    Connection to Switch B was successful.

  3. Log out of Switch B.
    root@Switch B# exit
    logout Connection to Switch B closed.
  4. Verify that NETCONF over SSH is working.
    root@Switch A# ssh root@Switch B -s netconf
    logout Connection to st-72q-01 closed.
    Password:
    <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <capabilities>
    <capability>urn:ietf:params:netconf:base:1.0</capability>
    <capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>

    The log message shows that the NETCONF over SSH was successful.

    If the error message showed that NETCONF over SSH was not successful, enable NETCONF over SSH by issuing the set system services netconf ssh command.

  5. Create configuration groups to synchronize if you have not done so already.

    You can issue the show | compare command to see if any configuration groups have been created.

    root@Switch A# show | compare
  6. Issue the commit command.
    root@Switch A# commit
    [edit chassis]



    configuration check succeeds

    commit complete

    {master:0}[edit]

    The log message shows that the commit was successful.