[j-nsp] SRX650 Clustering Issue
Walaa Abdel razzak
walaaez at bmc.com.sa
Sun Mar 6 01:39:04 EST 2011
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-bounces at puck.nether.net [mailto:juniper-nsp-bounces at 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 at 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-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] En nombre de ext juniper-nsp-request at puck.nether.net
Enviado el: sábado, 05 de marzo de 2011 08:29 a.m.
Para: juniper-nsp at puck.nether.net
Asunto: juniper-nsp Digest, Vol 100, Issue 9
Send juniper-nsp mailing list submissions to
juniper-nsp at 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-request at puck.nether.net
You can reach the person managing the list at
juniper-nsp-owner at 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.zugnoni at onlive.com>
To: Giovanni Bellac <giovannib1979 at ymail.com>
Cc: "juniper-nsp at puck.nether.net" <juniper-nsp at puck.nether.net>
Subject: Re: [j-nsp] 2x EX4200 Virtual Chassis Layer2/3 - Which JunOS
Version ?
Message-ID: <E2F2B5B1-00A4-4919-A5D7-35026CDBFA3D at 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 at 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 <bblackford at gmail.com>
To: Paul Zugnoni <paul.zugnoni at onlive.com>
Cc: "juniper-nsp at puck.nether.net" <juniper-nsp at puck.nether.net>
Subject: Re: [j-nsp] 2x EX4200 Virtual Chassis Layer2/3 - Which JunOS
Version ?
Message-ID:
<AANLkTin9T++7L=RrkfkHyLfog2303NEQjQ7w7FZPPM-X at 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.zugnoni at 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 at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at 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 <wojciech at owczarek.co.uk>
To: Bill Blackford <bblackford at gmail.com>
Cc: "juniper-nsp at puck.nether.net" <juniper-nsp at puck.nether.net>
Subject: Re: [j-nsp] 2x EX4200 Virtual Chassis Layer2/3 - Which JunOS
Version ?
Message-ID: <8EC9AD77-7329-4947-8A9C-0AC6F0DF888F at 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 <bblackford at 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.zugnoni at 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 at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at 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 at 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 <mtinka at globaltransit.net>
To: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] BFD timers for OSPF - MX80 - 10.3R2.11
Message-ID: <201103051009.48150.mtinka at 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" <walaaez at bmc.com.sa>
To: <juniper-nsp at puck.nether.net>
Subject: [j-nsp] Juniper SRX
Message-ID:
<E2C120A806ED3349A9F9E9913E0C8C1F9F1919 at 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" <routehero at gmail.com>
To: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Juniper SRX
Message-ID:
<AANLkTi=z-XUpX6j9GWyoJPNwfhGnL7RXe5Yi1iKwxbJ8 at 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 <walaaez at 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 at 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" <walaaez at bmc.com.sa>
To: <juniper-nsp at puck.nether.net>
Subject: [j-nsp] SRX650 Clustering Issue
Message-ID:
<E2C120A806ED3349A9F9E9913E0C8C1F9F1935 at 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" <routehero at gmail.com>
To: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] SRX650 Clustering Issue
Message-ID:
<AANLkTi=Lxtytw7rusKZ_uV9EsAkWru1XyLAeN0dMGdPh at 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 <walaaez at 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 at 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" <walaaez at bmc.com.sa>
To: "Scott T. Cameron" <routehero at gmail.com>,
<juniper-nsp at puck.nether.net>
Subject: Re: [j-nsp] SRX650 Clustering Issue
Message-ID:
<E2C120A806ED3349A9F9E9913E0C8C1F9F194C at 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 at -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 at -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-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Scott T.
Cameron
Sent: Saturday, March 05, 2011 4:46 PM
To: juniper-nsp at 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 <walaaez at bmc.com.sa <mailto:walaaez at 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 at puck.nether.net
<mailto:juniper-nsp at 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 at puck.nether.net <mailto:juniper-nsp at 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 at 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 at puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
More information about the juniper-nsp
mailing list