SRX Services Gateway
SRX Services Gateway

Struggling with removing management interface ALARM

[ Edited ]
a month ago

Hi guys, 

I´m setting up a new SRX340 cluster, have set up the chassis cluster, but I´m stucked triying to remove a persistent alarm on fxp0. In the SRX340 there is a dedicated management interface that I don´t want to use. 

 

I have run the comands 

set chassis alarm management-ethernet link-down ignore

And 

root@srx1# set groups node0 interfaces fxp0 disable
root@srx1# set groups node1 interfaces fxp0 disable

But the alarm persists:

 

 

root@SPCFW-BRAVO# run show system alarms
node0:
--------------------------------------------------------------------------
1 alarms currently active
Alarm time Class Description
2019-08-23 19:23:16 UTC Major Host 0 fxp0 : Ethernet Link Down

node1:
--------------------------------------------------------------------------
1 alarms currently active
Alarm time Class Description
2019-08-23 19:23:06 UTC Major Host 0 fxp0 : Ethernet Link Down

 

Any clue how can I solve this??

 

Thanks in advance. Below the coonfiguration:

 

 

root@SPCFW-BRAVO# run show configuration 
## Last commit: 2019-08-23 19:23:20 UTC by root
version 15.1X49-D150.2;
groups {
    node0 {
        system {
            host-name SPCFW-ALPHA;
        }
        interfaces {
            fxp0 {
                unit 0 {
                    family inet {
                        address 10.101.44.1/24;
                    }
                }
            }
        }
    }
    node1 {
        system {
            host-name SPCFW-BRAVO;
        }
        interfaces {
            fxp0 {
                unit 0 {                
                    family inet {
                        address 10.101.44.2/24;
                    }
                }
            }
        }
    }
}
apply-groups "${node}";
system {
    root-authentication {
        encrypted-password " ## SECRET-DATA
    }
    name-server {
        8.8.8.8;
        8.8.4.4;
    }
    services {
        ssh;
        netconf {
            ssh;
        }                               
        dhcp-local-server {
            group jdhcp-group {
                interface fxp0.0;
                interface irb.0;
            }
        }
        web-management {
            https {
                system-generated-certificate;
            }
        }
    }
    syslog {
        archive size 100k files 3;
        user * {
            any emergency;
        }
        file messages {
            any notice;
            authorization info;
        }
        file interactive-commands {
            interactive-commands any;   
        }
    }
    max-configurations-on-flash 5;
    max-configuration-rollbacks 5;
    license {
        autoupdate {
            url https://ae1.juniper.net/junos/key_retrieval;
        }
    }
    phone-home {
        server https://redirect.juniper.net;
        rfc-complaint;
    }
}
security {
    log {
        mode stream;
        report;
    }
    screen {
        ids-option untrust-screen {
            icmp {
                ping-death;             
            }
            ip {
                source-route-option;
                tear-drop;
            }
            tcp {
                syn-flood {
                    alarm-threshold 1024;
                    attack-threshold 200;
                    source-threshold 1024;
                    destination-threshold 2048;
                    timeout 20;
                }
                land;
            }
        }
    }
}
interfaces {
    fab0 {
        fabric-options {
            member-interfaces {
                ge-0/0/2;               
            }
        }
    }
    fab1 {
        fabric-options {
            member-interfaces {
                ge-5/0/2;
            }
        }
    }
}
protocols {
    l2-learning {
        global-mode switching;
    }
    rstp {
        interface all;
    }
}
access {
    address-assignment {
        pool junosDHCPPool1 {
            family inet {               
                network 192.168.1.0/24;
                range junosRange {
                    low 192.168.1.2;
                    high 192.168.1.254;
                }
                dhcp-attributes {
                    router {
                        192.168.1.1;
                    }
                    propagate-settings ge-0/0/0.0;
                }
            }
        }
        pool junosDHCPPool2 {
            family inet {
                network 192.168.2.0/24;
                range junosRange {
                    low 192.168.2.2;
                    high 192.168.2.254;
                }
                dhcp-attributes {
                    router {
                        192.168.2.1;    
                    }
                    propagate-settings ge-0/0/0.0;
                }
            }
        }
    }
}
vlans {
    vlan-trust {
        vlan-id 3;
        l3-interface irb.0;
    }
}

 

 

 

13 REPLIES 13
SRX Services Gateway

Re: Struggling with removing management interface ALARM

[ Edited ]
a month ago

According to documentation KB19523 that should work - but its different model.

Have you tried deleting all the config from the fxp0 interface i.e. removing the ip address and leave it without any configuration, just applying the disable command.

I also wonder if you apply the disable commands for the interface without the groups i.e.

set interfaces fxp0 disable, maybe it behaves differently?

Other than that might be worth asking j-tac support if you have access.

 

JNCIE-SEC #252 | CCIE RS #45032
SRX Services Gateway

Re: Struggling with removing management interface ALARM

a month ago

Hi nolotil

 

The steps that you have tried are the correct ones and are listed on Juniper oficial documentation,so it is weird that you are still seeing the alarm: https://kb.juniper.net/KB19523

Even though the document doesnt scpecifies SRX340, I confirmed the commands work on that platform as well.

 

-When the port is brought up the alarm disappears?

-When you applied the configuration, did you commit it? Maybe you could try it again but with a "commit full" command. (hidden command)

-Have you tryied rebooting the SRX?

-Whats the Junos version? The recommended one is 15.1X49-D170: https://kb.juniper.net/KB21476

-As a workaround, can you connect that port to a dummy device in order to bring the interface up?

 

Please mark my answer as the Solution if it applies.
SRX Services Gateway
Solution
Accepted by topic author nolotil
3 weeks ago

Re: Struggling with removing management interface ALARM

4 weeks ago

Hi Nolotil,

 

There is a known issue in SRX340 where we cant clear the fxp0 alarm with "set chassis alarm management-ethernet link-down ignore".

 

If you're running a Junos version below 15.1X49-D60, then you're most likely affected with a bug. So, I would suggest you upgrade the device to 15.1X49-D60 and above or to the recommended Junos version which Junos 15.1X49-D170.

 

 

Please let me know if you need anything.



Thanks,
π00bm@$t€®.
Please, Mark My Solution Accepted if it Helped, Kudos are Appreciated too!!!
SRX Services Gateway

Re: Struggling with removing management interface ALARM

4 weeks ago

Thanks Noobmaster. Actually I´m running 15.1X49-D150.2, do you think that might be the cause of the issue? would it worth to upgrade to D170?

 

BTW, having in mind that versions 15.1x49 will be end of support in less than a year, woudn´t make sense to upgrade to a newer version, even 19.2? is it too risky?

 

Thanks

SRX Services Gateway

Re: Struggling with removing management interface ALARM

4 weeks ago

 I´m glado to say that I´ve upgraded to 15.1X49-D170.4, then "set chassis alarm management-ethernet link-down ignore " and commit, and then the alarm just vanished!

Thanks a lot for the help!!!

 

Even though I´d like you Experts to recommend if you woould upgrade to a newer Junos version (considering end of life of version 15.1X49 is close) to version 18 or 19, or you would keep this version for now

 

Thanks a lot!

SRX Services Gateway

Re: Struggling with removing management interface ALARM

4 weeks ago

Personally, I will only move to a different Junos if there is a good reason to do so, like:

 

  •  looking for a new feature included in a different version
  •  you are facing a software problem
  • there is a security-vulnerebility fixed on the new version
  • JTAC support, if the version is EoL then they might deny support or ask you to upgrade before

 

The fact that 15.1X49 has been more time available also means that this software has more fixes for known bugs and that, in theory, it should be more stable than the new ones. If everything is working just fine with my networking device then why mess with it? =P

 

 

Please mark my answer as the Solution if it applies.
SRX Services Gateway

Re: Struggling with removing management interface ALARM

4 weeks ago

Hi Trasgu,

 

I believe its a regression bug in Junos version 15.1X49-D150 which was later fixed in D170.

 

I would suggest you stay in the recommended Junos version because these versions are selected using input from Juniper Engineering, customers, and analysis of field usage data. However, if you don't face any issues with the current Junos version then I don't think there is a reason to change the code. 

 

Its totally depends on your requirement.



Thanks,
π00bm@$t€®.
Please, Mark My Solution Accepted if it Helped, Kudos are Appreciated too!!!
SRX Services Gateway

Re: Struggling with removing management interface ALARM

3 weeks ago

HI guys, 

I don't have any special requirement or feature needed. The thing is that I'm setting up  new FW cluster now (August 2019) and the only recommended, officially stable  version for these gateways is 15.1x49. But that version (attending to this https://support.juniper.net/support/eol/software/junos/) will be end of support in less than a year (May 2020, in 8 months). 

 

For me at this moment it would be really easy and painless to perform a Junos upgrade, as I'm in an initial stage, this cluster is not in production yet. But once it's in production, the situation and the risk of performing an upgrade is totally different. 

 

My rethoric questions are: 

 

- Is not pointless to go ahead with a Junos release which end of life is around the corner, and that will be mandatory to be upgraded in less than one year? 

- What's the point of the fact that there are 13 (!!!!) Junos releases above 15.1x49 but none of them (not even one!!) have been accepted by Juniper as stable and trustable enough? 

- Even more: if along these 13 relases they haven't been able to find a stable and recommended one, do you guys feel comfortable thinking they find any from now until May 2020, when the 15.1x49 reaches its end of support? 

 

Thanks!

SRX Services Gateway

Re: Struggling with removing management interface ALARM

3 weeks ago

Hello,

 

Thanks a lot for the fedback and I understand your dilemma here. I will check internally on how this can be improved.

 

My advice to you would be to stick to the JTAC recommended release, while not worrying too much about the software support EOL.

 

There are many fators that go into determining the JTAC recommeded release. Bugs reported, Stability, Customer acceptance/deployability, feature parity etc. So the fact that a version above 15.1 is not in the JTAC recommended release would not necessarily be due to stability issues.

 

I hope this helps. Regards,

 

Vikas

SRX Services Gateway

Re: Struggling with removing management interface ALARM

3 weeks ago

Hi Noobmaster, 

 

Thanks a lot for your help. unfortunatelly I don't see the option to mark your reply as the solution to this topic

 

Thanks anyway!

SRX Services Gateway

Re: Struggling with removing management interface ALARM

3 weeks ago

HI Vikas, thank you for your reply. 

I totally understand your point, but saying that factors to not recomend any newer realease are several as "Bugs reported, Stability, Customer acceptance/deployability, feature parity etc" also means that during the following 13 (!!!!) releases, Juniper engineers haven't been able to guarrantee anything better in term of "Bugs reported, Stability, Customer acceptance/deployability, feature parity etc"....

And that's quite worriying. 

 

More than that, if they are not able to find a better software, why don't they:

 

A) Stop releasing new versions, totally pointless as no one deserves to install them, as they are not realiable according to the experts and Juniper itself

B) Increase de end of support date of the latest stable and recommended version, 15.1?

 

I can't understand Juniper at this point. The thing is that I have these nodes on my desk (e.g. not in production yet) and now it would be really easy and smooth to upgrade them to any other Junos version, while in less than a year it will be much more painful and risky to upgrade that cluster.

 

This is not showing up good sensations from the reliability of Junos, and the logic between the releases and the end of life - end of support of those releases, and gives us, the network admins, a really narrow capacity to plan and set up the things reliable for the mid-long term. 

 

ThankS!

SRX Services Gateway

Re: Struggling with removing management interface ALARM

3 weeks ago
Hello,

Thanks again for the feedback and I totally understand.

I am already in discussion on this and I gather that there is already work ongoing on the same. Unfortunately, this is all I can offer at the moment.

Again, I would suggest you to stick to the JRR (JTAC recommend release) since you are not looking for a specific feature in 18.X +.

Best Regards,

Vikas



Juniper Business Use Only
SRX Services Gateway

Re: Struggling with removing management interface ALARM

3 weeks ago

l will do!!

 

Thanks again