[j-nsp] SRX650 Clustering Issue

Serrano Samaca, Edinson (EXT-Other - MX/Mexico City) edinson.serrano_samaca.ext at nsn.com
Sat Mar 5 15:01:52 EST 2011


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
*******************************************



More information about the juniper-nsp mailing list