[j-nsp] SRX650 Failover Test Issue

[Chen Jiang]

It's a by design behavior. When control link or fabric link disconnected,
the current  RG0 master node will remain in master status but the current
RG0 backup node will disable itself to avoid split-brain issue, "Disable"
means the node will offline all SPC/NPC and Line Card. And only reboot the
whole chassis could recovery the node.

On Wed, Mar 23, 2011 at 4:18 PM, Walaa Abdel razzak <walaaez at bmc.com.sa>wrote:

> Hi Michael
>
> It already configured in a group. Also I was trying to telnet from directly
> connected ip.
>
> groups {
>    node0 {
>        system {
>            host-name FW1;
>        }
>        interfaces {
>            fxp0 {
>                unit 0 {
>                    family inet {
>                        address 11.11.11.2/24;
>                    }
>                }
>            }
>        }
>    }
>    node1 {
>        system {
>            host-name FW2;
>        }
>        interfaces {
>            fxp0 {
>                unit 0 {
>                    family inet {
>                        address 11.11.11.3/24;
>                    }
>                }
>            }
>        }
>    }
> }
> apply-groups "${node}";
>
> BR,
>
>
> -----Original Message-----
> From: Michael Lee [mailto:fwissue at gmail.com]
> Sent: Wednesday, March 23, 2011 3:45 AM
> To: Pavel Lunin
> Cc: Walaa Abdel razzak; juniper-nsp
> Subject: Re: [j-nsp] SRX650 Failover Test Issue
>
> Sounds like the interface did not put into group, and should use fxp0 ip
> instead
>
> Regards
>
> -mike
>
> On Mar 22, 2011, at 12:05, Pavel Lunin <plunin at senetsy.ru> wrote:
>
> >>
> >> While testing the failover in SRX650 cluster. I have removed the
> >> control link between the primary and secondary. The secondary node
> >> went to ineligible mode. The secondry FW is still accessible through
> >> OoB interface. When I returned back the control link I couldn't reach
> >> the FW through OoB interface "ge-0/0/0". The only way to access the
> >> box is through console and found the secondary firewall is in disable
> mode.
> >> Then when I rebooted the whole firewall, it worked normally. Is it
> >> normal? And how to reach the secondary firewall remotely in case of
> >> control link flap? I have faced the same issue when removing the fab
> >> link.
> >>
> >>
> >>
> > Looks like a routing issue. Try to check it out with "show route a.b.c.d"
> > command, when you access the disabled box through the console port,
> > where a.b.c.d is IP address of the machine, you are trying to get
> > remote access form. Most probably it will show you something different
> > from a route pointing through fxp0. If this is the case, you need to
> > configure a backup router, which would make the disabled node (which
> > does not run rpd) to route packets to the management station through
> fxp0.
> >
> > http://www.juniper.net/techpubs/en_US/junos10.0/information-products/t
> > opic-collections/config-guide-system-basics/backup-router-configuring.
> > html
> >
> > BTW, next time you want the public to guess the solution for your
> > issue, try to be a bit more informative in providing basic
> troubleshooting details. E.
> > g. instead of just saying "I couldn't reach the FW through OoB
> > interface "ge-0/0/0"", it would've been better to say something like
> > "I checked the whole path from my machine a.b.c.d/24 to the fxp0
> > interface of the node1, which has address w.x.y.z/24 and… I see the
> > packets coming to the penultimate hop router, but the FW's fxp0
> > interface, which is the next and last hop, does [not] respond to ARP
> > requests… Than I tried to ping my machine back from the FW with "ping
> > a.b.c.d interface fxp0", and got the following output… than I
> > performed a traceroute… I checked what comes to the
> > fxp0 interface with "monitor traffic interface fxp0" and saw…", etc.
> >
> > Otherwise, I'm afraid, this sort of gambling-style troubleshooting, in
> > which you ask us to help you, will not be much effective anyway.
> > Monte-Carlo is a good method but it's too slow in convergence.
> >
> > --
> > Pavel
> > _______________________________________________
> > 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
>



-- 
BR!



           James Chen