The boxes were factory defaults, the hardware is identical in everything. The sequence is as follows:
1. Adding some config to each box individually like hostname, aggregate interface. 2. from user mode, we have configured the clustering and reboot for node0, node1. BR, -----Original Message----- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Serrano Samaca, Edinson (EXT-Other - MX/Mexico City) Sent: Saturday, March 05, 2011 11:02 PM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX650 Clustering Issue Hello, can you give us a full configuration about boxes, or these was factory default? Also the step by step lines while you configured the cluster. Remember that for clustering the both SRX must to be the same hardware position and configuration. Best Regards, Edinson M. Serrano Samacá Mobile: 5544483952 -----Mensaje original----- De: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] En nombre de ext juniper-nsp-requ...@puck.nether.net Enviado el: sábado, 05 de marzo de 2011 08:29 a.m. Para: juniper-nsp@puck.nether.net Asunto: juniper-nsp Digest, Vol 100, Issue 9 Send juniper-nsp mailing list submissions to juniper-nsp@puck.nether.net To subscribe or unsubscribe via the World Wide Web, visit https://puck.nether.net/mailman/listinfo/juniper-nsp or, via email, send a message with subject or body 'help' to juniper-nsp-requ...@puck.nether.net You can reach the person managing the list at juniper-nsp-ow...@puck.nether.net When replying, please edit your Subject line so it is more specific than "Re: Contents of juniper-nsp digest..." Today's Topics: 1. Re: 2x EX4200 Virtual Chassis Layer2/3 - Which JunOS Version ? (Paul Zugnoni) 2. Re: 2x EX4200 Virtual Chassis Layer2/3 - Which JunOS Version ? (Bill Blackford) 3. Re: 2x EX4200 Virtual Chassis Layer2/3 - Which JunOS Version ? (Wojciech Owczarek) 4. Re: BFD timers for OSPF - MX80 - 10.3R2.11 (Mark Tinka) 5. Juniper SRX (Walaa Abdel razzak) 6. Re: Juniper SRX (Scott T. Cameron) 7. SRX650 Clustering Issue (Walaa Abdel razzak) 8. Re: SRX650 Clustering Issue (Scott T. Cameron) 9. Re: SRX650 Clustering Issue (Walaa Abdel razzak) ---------------------------------------------------------------------- Message: 1 Date: Fri, 4 Mar 2011 08:37:09 -0800 From: Paul Zugnoni <paul.zugn...@onlive.com> To: Giovanni Bellac <giovannib1...@ymail.com> Cc: "juniper-nsp@puck.nether.net" <juniper-nsp@puck.nether.net> Subject: Re: [j-nsp] 2x EX4200 Virtual Chassis Layer2/3 - Which JunOS Version ? Message-ID: <e2f2b5b1-00a4-4919-a5d7-35026cdbf...@onlive.com> Content-Type: text/plain; charset="us-ascii" Hope a 2-week later reply is still relevant for you: I've had good experience with 10.0S1.1 and 10.1R3.7 in setups that include your 3 requirements below. As noted earlier in the thread, upgrades on a EX VC are not hitless, so keep that in mind. The VC will not provide HA for a code upgrade. Also important to note: You might not plan to carry the full table, but if you plan to accomplish that by rejecting any route from your ISP other than the default, you'll have a performance problem when the EX has to reject thousands (full table now at ~350k routes) of routes. Be sure to have your ISP send you JUST the default. ;) Don't forget to get the right license to run BGP on the EX. Paul Z On Feb 19, 2011, at 08:13 , Giovanni Bellac wrote: > Hello all > > I have now spend a lot of time to find out the optimal version of > JunOS for our newly ordered 2x EX4200s. > > 1) We will run a 2x EX4200 Virtual Chassis. > 2) We will run BGP default routes (NO full table) and announce our /21. > 3) We will connect our rack-switches to the Virtual Chassis. > > So, we will do Layer2 and some (basic) Layer3. > > Should we use the latest service release of 10.0 (= 10.0s11 / 10.0s12) > or use directly 10.4R2.6 ? > > My eyes are on 10.0 and 10.4 because these are longer supported releases. > > Thank you in advance. > > Regards > Giovanni > > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp ------------------------------ Message: 2 Date: Fri, 4 Mar 2011 09:28:40 -0800 From: Bill Blackford <bblackf...@gmail.com> To: Paul Zugnoni <paul.zugn...@onlive.com> Cc: "juniper-nsp@puck.nether.net" <juniper-nsp@puck.nether.net> Subject: Re: [j-nsp] 2x EX4200 Virtual Chassis Layer2/3 - Which JunOS Version ? Message-ID: <AANLkTin9T++7L=rrkfkhylfog2303neqjq7w7fzpp...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 > Also important to note: You might not plan to carry the full table, > but if you plan to accomplish that by rejecting any route from your > ISP other than the default, you'll have a performance problem when the > EX has to reject thousands (full table now at ~350k routes) of routes. > Be sure to have your ISP send you JUST the default. ;) +1 I use EX4200's in some aggregation roles. I found that I had to filter routes on my borders sitting above these. For what ever it's worth, I had to do the same for Cisco LAN switches (3750G) in agg roles too. -b On Fri, Mar 4, 2011 at 8:37 AM, Paul Zugnoni <paul.zugn...@onlive.com> wrote: > Hope a 2-week later reply is still relevant for you: > > I've had good experience with 10.0S1.1 and 10.1R3.7 in setups that include > your 3 requirements below. As noted earlier in the thread, upgrades on a EX > VC are not hitless, so keep that in mind. The VC will not provide HA for a > code upgrade. > > Also important to note: You might not plan to carry the full table, > but if you plan to accomplish that by rejecting any route from your > ISP other than the default, you'll have a performance problem when the > EX has to reject thousands (full table now at ~350k routes) of routes. > Be sure to have your ISP send you JUST the default. ;) > > Don't forget to get the right license to run BGP on the EX. > > Paul Z > > On Feb 19, 2011, at 08:13 , Giovanni Bellac wrote: > >> Hello all >> >> I have now spend a lot of time to find out the optimal version of >> JunOS for our newly ordered 2x EX4200s. >> >> 1) We will run a 2x EX4200 Virtual Chassis. >> 2) We will run BGP default routes (NO full table) and announce our /21. >> 3) We will connect our rack-switches to the Virtual Chassis. >> >> So, we will do Layer2 and some (basic) Layer3. >> >> Should we use the latest service release of 10.0 (= 10.0s11 / >> 10.0s12) or use directly 10.4R2.6 ? >> >> My eyes are on 10.0 and 10.4 because these are longer supported releases. >> >> Thank you in advance. >> >> Regards >> Giovanni >> >> _______________________________________________ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp > > > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges..... ------------------------------ Message: 3 Date: Fri, 4 Mar 2011 17:57:36 +0000 From: Wojciech Owczarek <wojci...@owczarek.co.uk> To: Bill Blackford <bblackf...@gmail.com> Cc: "juniper-nsp@puck.nether.net" <juniper-nsp@puck.nether.net> Subject: Re: [j-nsp] 2x EX4200 Virtual Chassis Layer2/3 - Which JunOS Version ? Message-ID: <8ec9ad77-7329-4947-8a9c-0ac6f0df8...@owczarek.co.uk> Content-Type: text/plain; charset=us-ascii Thought you might find this useful as well: I know that there is a memory leak issue on JunOS 10.0 for EX4200 affecting VC stacks in particular where the stack members fall over from memory exhaustion when the uptime reaches around 360 days. Can't remember which release fixes it though. Regards, Wojciech - Wojciech Owczarek On 4 Mar 2011, at 17:28, Bill Blackford <bblackf...@gmail.com> wrote: >> Also important to note: You might not plan to carry the full table, >> but if you plan to accomplish that by rejecting any route from your >> ISP other than the default, you'll have a performance problem when >> the EX has to reject thousands (full table now at ~350k routes) of >> routes. Be sure to have your ISP send you JUST the default. ;) > > +1 > > I use EX4200's in some aggregation roles. I found that I had to filter > routes on my borders sitting above these. For what ever it's worth, I > had to do the same for Cisco LAN switches (3750G) in agg roles too. > > -b > > > > > > On Fri, Mar 4, 2011 at 8:37 AM, Paul Zugnoni <paul.zugn...@onlive.com> wrote: >> Hope a 2-week later reply is still relevant for you: >> >> I've had good experience with 10.0S1.1 and 10.1R3.7 in setups that include >> your 3 requirements below. As noted earlier in the thread, upgrades on a EX >> VC are not hitless, so keep that in mind. The VC will not provide HA for a >> code upgrade. >> >> Also important to note: You might not plan to carry the full table, >> but if you plan to accomplish that by rejecting any route from your >> ISP other than the default, you'll have a performance problem when >> the EX has to reject thousands (full table now at ~350k routes) of >> routes. Be sure to have your ISP send you JUST the default. ;) >> >> Don't forget to get the right license to run BGP on the EX. >> >> Paul Z >> >> On Feb 19, 2011, at 08:13 , Giovanni Bellac wrote: >> >>> Hello all >>> >>> I have now spend a lot of time to find out the optimal version of >>> JunOS for our newly ordered 2x EX4200s. >>> >>> 1) We will run a 2x EX4200 Virtual Chassis. >>> 2) We will run BGP default routes (NO full table) and announce our /21. >>> 3) We will connect our rack-switches to the Virtual Chassis. >>> >>> So, we will do Layer2 and some (basic) Layer3. >>> >>> Should we use the latest service release of 10.0 (= 10.0s11 / >>> 10.0s12) or use directly 10.4R2.6 ? >>> >>> My eyes are on 10.0 and 10.4 because these are longer supported releases. >>> >>> Thank you in advance. >>> >>> Regards >>> Giovanni >>> >>> _______________________________________________ >>> juniper-nsp mailing list juniper-nsp@puck.nether.net >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >> >> >> _______________________________________________ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > > > > -- > Bill Blackford > Network Engineer > > Logged into reality and abusing my sudo privileges..... > > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp ------------------------------ Message: 4 Date: Sat, 5 Mar 2011 10:09:42 +0800 From: Mark Tinka <mti...@globaltransit.net> To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] BFD timers for OSPF - MX80 - 10.3R2.11 Message-ID: <201103051009.48150.mti...@globaltransit.net> Content-Type: text/plain; charset="us-ascii" On Friday, March 04, 2011 06:27:27 am Doug Hanks wrote: > We generally recommend 150ms to most customers. The added benefit of > going from 150ms to 50ms is generally not enough to warrant the move. We've been using 250ms with multipliers of 3 on short runs and 5 on longer ones. Has been stable, except for cases when CPU suddenly becomes busy, dropping BFD packets, e.g., when inserting a compact flash card into a (software-based) router. We have both Cisco and Juniper, ranging from software- to hardware-based platforms, with centralized and distributed forwarding designs. The numbers above help us harmonize things. We're now settling on fairly modern kit (Juniper MX, Juniper M120, Cisco ASR1000, Cisco ASR9000, Cisco CRS, e.t.c.), so it may well be time to review these values if we can find a common understanding across these boxes in how better they implement BFD. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20110305/c010b4b8/attachment-0001.pgp> ------------------------------ Message: 5 Date: Sat, 5 Mar 2011 15:06:46 +0300 From: "Walaa Abdel razzak" <wala...@bmc.com.sa> To: <juniper-nsp@puck.nether.net> Subject: [j-nsp] Juniper SRX Message-ID: <e2c120a806ed3349a9f9e9913e0c8c1f9f1...@bmcserver.bmc.com.sa> Content-Type: text/plain; charset="us-ascii" Hi Experts Is there any mailing list like this related to SRX topics or we can post on this as well? ------------------------------ Message: 6 Date: Sat, 5 Mar 2011 07:25:51 -0500 From: "Scott T. Cameron" <routeh...@gmail.com> To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Juniper SRX Message-ID: <AANLkTi=z-xupx6j9gwyojpnwfhgnl7rxe5yi1ikwx...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Free for all on all Juniper related topics. RAS may overwhelm you with intimate knowledge of the devices, don't be frightened :) On Sat, Mar 5, 2011 at 7:06 AM, Walaa Abdel razzak <wala...@bmc.com.sa>wrote: > Hi Experts > > > > Is there any mailing list like this related to SRX topics or we can > post on this as well? > > > > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ------------------------------ Message: 7 Date: Sat, 5 Mar 2011 16:24:48 +0300 From: "Walaa Abdel razzak" <wala...@bmc.com.sa> To: <juniper-nsp@puck.nether.net> Subject: [j-nsp] SRX650 Clustering Issue Message-ID: <e2c120a806ed3349a9f9e9913e0c8c1f9f1...@bmcserver.bmc.com.sa> Content-Type: text/plain; charset="us-ascii" Hi All We were connecting two SRX650 to work in Active/passive mode. Before they were having old configuration and once we enabled clustering and rebooted the boxes, they became in hold mode and we get a message of shared violations even after reboot again and no user logged in, any suggestions? BR, ------------------------------ Message: 8 Date: Sat, 5 Mar 2011 08:45:59 -0500 From: "Scott T. Cameron" <routeh...@gmail.com> To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX650 Clustering Issue Message-ID: <AANLkTi=lxtytw7ruskz_uv9esakwru1xylaen0dmg...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 I don't think this is enough information to really help you. What does chassisd log say? Can you provide a sanitized config? Scott On Sat, Mar 5, 2011 at 8:24 AM, Walaa Abdel razzak <wala...@bmc.com.sa>wrote: > Hi All > > > > We were connecting two SRX650 to work in Active/passive mode. Before > they were having old configuration and once we enabled clustering and > rebooted the boxes, they became in hold mode and we get a message of > shared violations even after reboot again and no user logged in, any > suggestions? > > > > BR, > > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ------------------------------ Message: 9 Date: Sat, 5 Mar 2011 17:17:18 +0300 From: "Walaa Abdel razzak" <wala...@bmc.com.sa> To: "Scott T. Cameron" <routeh...@gmail.com>, <juniper-nsp@puck.nether.net> Subject: Re: [j-nsp] SRX650 Clustering Issue Message-ID: <e2c120a806ed3349a9f9e9913e0c8c1f9f1...@bmcserver.bmc.com.sa> Content-Type: text/plain; charset="us-ascii" Hi Scott The old configuration was test config (very simple) like hostname, aggregate ethernet,.....as its fresh FW. After enabling clusterign using the standard command set chassis clustering......and reboot, we got the following: {hold:node0} root@-FW1> edit warning: Clustering enabled; using private edit error: shared configuration database modified Please temporarily use 'configure shared' to commit outstanding changes in the shared database, exit, and return to configuration mode using 'configure' when I issue most commands I got the following: {hold:node0} root@-FW1> show version error: Could not connect to node0 : No route to host The JUNOS version is 10.3. Also here is a sample of Chassisd log: Mar 5 19:32:49 completed chassis state from ddl Mar 5 19:32:49 ch_set_non_stop_forwarding_cfg:Setting non-stop-forwarding to Disabled, source DDL Mar 5 19:32:49 ch_do_multichassis_overrides:Setting multichassis replication to Disabled Mar 5 19:32:49 config_do_overrides: Keepalives not set. Setting it to 300 secs Mar 5 19:32:49 if_init Mar 5 19:32:49 Skip cleaning pic state on LCC Mar 5 19:32:49 chassis_alarm_module_init Mar 5 19:32:49 timer_init Mar 5 19:32:49 main_snmp_init Mar 5 19:32:49 snmp_init: snmp_chassis_id = 0, chas_type = 1 Mar 5 19:32:49 chas_do_registration: or_obj = 0xdfe400, or_rows = 23 Mar 5 19:32:49 chas_do_registration: or_obj = 0xdfe800, or_rows = 23 Mar 5 19:32:49 chas_do_registration: or_obj = 0xe04000, or_rows = 23 Mar 5 19:32:49 chas_do_registration: or_obj = 0xd58940, or_rows = 2 Mar 5 19:32:49 chas_do_registration: or_obj = 0xdfec00, or_rows = 23 Mar 5 19:32:49 CHASSISD_SYSCTL_ERROR: ch_srxsme_mgmt_port_mac_init: hw.re.jseries_fxp_macaddr error from sysctlbyname: File exists (errno 17) Mar 5 19:32:49 CHASSISD_SYSCTL_ERROR: ch_srxsme_mgmt_port_mac_init: hw.re.jseries_fxp_macaddr error from sysctlbyname: File exists (errno 17) Mar 5 19:33:08 Mar 5 19:33:08 trace flags 7f00 trace file /var/log/chassisd size 3000000 cnt 5 no-remote-trace 0 Mar 5 19:33:08 rtsock_init synchronous socket Mar 5 19:33:08 disabling rtsock public state on sync socket (LCC) Mar 5 19:33:08 rtsock_init asynchronous socket Mar 5 19:33:08 disabling rtsock public state on async socket (LCC) Mar 5 19:33:08 rtsock_init non ifstate async socket Mar 5 19:33:08 disabling rtsock public state on non ifstate async socket (LCC) Mar 5 19:33:08 BCM5910X (bcm5910x_driver_init): Driver initialization succeeded Mar 5 19:33:08 POE (ch_poe_srxsme_check_pem_status): POE power good signal for power supply 1 not asserted Mar 5 19:33:08 ch_srxsme_poe_blob_delete: fpc 2 Mar 5 19:33:08 ch_srxsme_poe_blob_delete: fpc 4 Mar 5 19:33:08 ch_srxsme_poe_blob_delete: fpc 6 Mar 5 19:33:08 ch_srxsme_poe_blob_delete: fpc 8 Mar 5 19:33:08 POE (ch_srxsme_poe_init): poe init done Mar 5 19:33:08 parse_configuration ddl Mar 5 19:33:08 cfg_ddl_chasd_handle_config_option: Found {chassis, aggregated-devices}: Object Config action: DAX_ITEM_CHANGED Mar 5 19:33:08 Walking Object {aggregated-devices, } Mar 5 19:33:08 cfg_ddl_chasd_handle_config_option: Found {aggregated-devices, ethernet}: Object Config action: DAX_ITEM_CHANGED Mar 5 19:33:08 Walking Object {ethernet, device-count} Mar 5 19:33:08 configured aggregated ethernet device count 3 Mar 5 19:33:08 aggregated-device ethernet Mar 5 19:33:08 configured aggregated ethernet state Mar 5 19:33:08 cfg_ddl_chasd_handle_config_option: Did not find {chassis, cluster}: Object Config action: DAX_ITEM_CHANGED Mar 5 19:33:08 No routing-options source_routing configuration options set Mar 5 19:33:08 protocol-id queue-depth delete-flag Mar 5 19:33:08 Total Queue Allocation: 0/1024 Mar 5 19:33:08 POE (poe_handle_maxpower_on_fpc): FPC 2, max-power 0 Mar 5 19:33:08 POE (poe_handle_maxpower_on_fpc): FPC 4, max-power 0 Mar 5 19:33:08 POE (poe_handle_maxpower_on_fpc): FPC 6, max-power 0 Mar 5 19:33:08 POE (poe_handle_maxpower_on_fpc): FPC 8, max-power 0 Mar 5 19:33:08 POE (poe_handle_maxpower_on_fpc): FPC 2, max-power 0 Mar 5 19:33:08 POE (poe_handle_maxpower_on_fpc): FPC 4, max-power 0 Mar 5 19:33:08 POE (poe_handle_maxpower_on_fpc): FPC 6, max-power 0 Mar 5 19:33:08 POE (poe_handle_maxpower_on_fpc): FPC 8, max-power 0 Mar 5 19:33:08 completed chassis state from ddl Mar 5 19:33:08 ch_set_non_stop_forwarding_cfg:Setting non-stop-forwarding to Disabled, source DDL Mar 5 19:33:08 ch_do_multichassis_overrides:Setting multichassis replication to Disabled Mar 5 19:33:08 config_do_overrides: Keepalives not set. Setting it to 300 secs Mar 5 19:33:08 if_init Mar 5 19:33:08 Skip cleaning pic state on LCC Mar 5 19:33:08 chassis_alarm_module_init Mar 5 19:33:08 timer_init Mar 5 19:33:08 main_snmp_init Mar 5 19:33:08 snmp_init: snmp_chassis_id = 0, chas_type = 1 Mar 5 19:33:08 chas_do_registration: or_obj = 0xdfe400, or_rows = 23 Mar 5 19:33:08 chas_do_registration: or_obj = 0xdfe800, or_rows = 23 Mar 5 19:33:08 chas_do_registration: or_obj = 0xe04000, or_rows = 23 Mar 5 19:33:08 chas_do_registration: or_obj = 0xd58940, or_rows = 2 Mar 5 19:33:08 chas_do_registration: or_obj = 0xdfec00, or_rows = 23 Mar 5 19:33:09 hup_init:Hupping init! Mar 5 19:33:09 JACT_INFO: Created re (h=9) Anti-Counterfeit FSM object Mar 5 19:33:09 ---cb_reset----re (h=9): reason=SUCCESS (0) Mar 5 19:33:09 mbus_srxmr_reset_sre_dev: Resetting SRE DEV 5 Mar 5 19:33:09 Resetting anti-counterfeit chip Mar 5 19:33:09 smb_open, gpiofd 29 Mar 5 19:33:09 initial startup complete Mar 5 19:33:09 main initialization done.... Mar 5 19:33:09 alarmd connection completed Mar 5 19:33:09 send: clear all chassis class alarms Mar 5 19:33:09 craftd connection completed Mar 5 19:33:13 JACT_INFO: re (h=9): enter state: HOLD Mar 5 19:34:13 JACT_INFO: re: Read public key info... Mar 5 19:34:13 JACT_INFO: re: Prepare and send encrypted random messsage Mar 5 19:34:13 JACT_INFO: re (h=9): enter state: DOING Mar 5 19:36:09 Attempting md comp chunkbuf pool shrink Mar 5 19:37:18 JACT_INFO: re: Read and check decrypted messsage Mar 5 19:37:18 ---cb_done----re (h=9): auth=passed Mar 5 19:37:18 re (h=9): AC authentication passed Mar 5 19:37:18 JACT_INFO: re (h=9): enter state: PASSED -----Original Message----- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Scott T. Cameron Sent: Saturday, March 05, 2011 4:46 PM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX650 Clustering Issue I don't think this is enough information to really help you. What does chassisd log say? Can you provide a sanitized config? Scott On Sat, Mar 5, 2011 at 8:24 AM, Walaa Abdel razzak <wala...@bmc.com.sa <mailto:wala...@bmc.com.sa> >wrote: > Hi All > > > > We were connecting two SRX650 to work in Active/passive mode. Before > they were having old configuration and once we enabled clustering and > rebooted the boxes, they became in hold mode and we get a message of > shared violations even after reboot again and no user logged in, any > suggestions? > > > > BR, > > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net <mailto:juniper-nsp@puck.nether.net> > https://puck.nether.net/mailman/listinfo/juniper-nsp <https://puck.nether.net/mailman/listinfo/juniper-nsp> > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net <mailto:juniper-nsp@puck.nether.net> https://puck.nether.net/mailman/listinfo/juniper-nsp <https://puck.nether.net/mailman/listinfo/juniper-nsp> ------------------------------ _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp End of juniper-nsp Digest, Vol 100, Issue 9 ******************************************* _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
