[j-nsp] SRX650 Clustering Issue

[Pavel Lunin]

>
> This is a pretty common error when you are bringing pre-configured devices
> together in a chassis cluster.
>

+1

set interfaces fab0 fabric-options member-interfaces ge-0/0/2
> set interfaces fab1 fabric-options member-interfaces ge-5/0/2
>
>
In case of SRX650 this should be ge-0/0/2 and ge-9/0/2 :)

However there is another possible reason. Upgrade to 10.3 from 10.1 and
earlier sometimes gives you different control link modes on different
devices. In 10.2, which was initially slipped and now its 3rd release is the
recommended one, a non-tagged control-link mode was introduced and made
default.

See
http://www.juniper.net/techpubs/en_US/junos10.2/information-products/topic-collections/release-notes/10.2/topic-45729.html#rn-junos-srx-j-CIDBS‘Chassis
Cluster’ section.

We ran into this a couple of times, when upgrading two boxes from 10.0/10.1
to 10.3 kept one box's fxp1 tagged and the second one became untagged. This
can be changed manually. See the link below for details.

This hypothesis can be easily checked with ‘show chassis cluster
information’ (hidden) and ‘monitor traffic interface fxp1’ — should you have
different modes for control links, you would see normally parced TNP packets
coming from tagged node and hexadecimal values on the other side, not parced
due to the non-standard ethertype.

Though AFAIR it would make the cluster peer seen as 'disabled' not 'hold'.