> > 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'. _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
