[j-nsp] Apply-group brain fart
Tom Storey
tom at snnap.net
Tue Aug 28 05:35:49 EDT 2018
Hi Balasankar,
I dont have the same issue when I configure in the foreground.
I am running software version 15.1X49-D120.3 if that helps.
Ive been informed that we have support on this gear, so I will raise a case
via JTAC too.
Thanks!
Tom
On Mon, 27 Aug 2018 at 08:28, Balasankar Rajaguru <balasank at juniper.net>
wrote:
> Hi Tom,
>
> > Ive tried defining the st0 interface and unit 1 within the interfaces
> stanza, but
> > that didnt help. What am I missing? What can I look at? Am I trying to do
> > something that simply cant be done?
>
> Does the issue happens when the same config is configured in foreground
> under
> Interface stanza without the apply-groups config.
>
> Regards,
> Balasankar
>
> > -----Original Message-----
> > From: juniper-nsp <juniper-nsp-bounces at puck.nether.net> On Behalf Of Tom
> > Storey
> > Sent: Friday, August 24, 2018 3:35 PM
> > To: juniper-nsp at puck.nether.net
> > Subject: [j-nsp] Apply-group brain fart
> >
> > Hi everyone. I am trying to build some configuration groups with the
> intention of
> > keeping related configuration for some IPSEC VPNs etc nicely contained
> in one
> > spot - define all relevant configuration in a group and apply it in one
> go, and also
> > remove it *all* when you delete and remove the configuration group. This
> way,
> > hopefully, little bits and pieces dont get left behind as VPNs are set
> up and torn
> > down, ideally maintaining a cleaner configuration.
> >
> > But I have an odd situation. I am working with a cluster of SRX345, and
> it seems
> > that when ever I apply a config group with an st interface defined, my
> default
> > route disappears and some connected routes seem to disappear or change
> from
> > local to reject, and I lose the ability to manage the cluster via SSH
> and have to
> > use the console. The same does not happen on a standalone SRX110.
> >
> > For example, prior to applying the configuration, my routing table looks
> > like:
> >
> > 0.0.0.0/0 *[Static/5] 16:51:49
> > > to 10.32.31.1 via reth2.0
> > 10.32.31.0/24 *[Direct/0] 16:51:49
> > > via reth2.0
> > 10.32.31.230/32 *[Local/0] 16w6d 23:56:30
> > Local via reth2.0
> > 10.32.31.231/32 *[Static/1] 6d 22:02:40
> > Receive
> > 100.64.0.0/24 *[Direct/0] 16:51:49
> > > via reth3.0
> > 100.64.0.1/32 *[Local/0] 1w0d 19:43:19
> > Local via reth3.0
> >
> > And after applying the apply group:
> >
> > 10.32.31.230/32 *[Local/0] 16w6d 23:58:13
> > Reject
> > 10.32.31.231/32 *[Static/1] 6d 22:04:23
> > Receive
> > 100.64.0.1/32 *[Local/0] 1w0d 19:45:02
> > Reject
> > 100.64.255.0/30 *[Direct/0] 00:00:04
> > > via st0.1
> > 100.64.255.1/32 *[Local/0] 00:00:04
> > Local via st0.1
> >
> > The very simple configuration group that I have defined is (I removed a
> lot of it
> > during debugging, and this is all that is left):
> >
> > groups {
> > EXAMPLE-VPN {
> > interfaces {
> > st0 {
> > unit 1 {
> > description "DCN VPN to srx110:st0.0";
> > family inet {
> > address 100.64.255.1/30;
> > }
> > }
> > }
> > }
> > }
> > }
> >
> > I set this with:
> >
> > {primary:node0}[edit]
> > root at node0-srx345# set apply-groups EXAMPLE-VPN
> >
> > Pretty straight forward I thought...
> >
> > In the configuration, after the commit has completed (no complaints) I
> do see
> > my st0 configuration inherited, and all of the configuration for my reth
> > interfaces is also inherited, and show int terse shows them all there
> with their IP
> > addresses.
> >
> > # show interfaces | display inheritance
> > ...
> > reth2 {
> > description UNTRUST;
> > ##
> > ## 'redundant-ether-options' was inherited from group
> 'SRX34X-CLUSTER'
> > ##
> > redundant-ether-options {
> > ##
> > ## '1' was inherited from group 'SRX34X-CLUSTER'
> > ##
> > redundancy-group 1;
> > }
> > unit 0 {
> > family inet {
> > address 10.32.31.230/24;
> > }
> > }
> > }
> > reth3 {
> > description "AVAILABLE - Parent for ge-[05]/0/3";
> > ##
> > ## 'redundant-ether-options' was inherited from group
> 'SRX34X-CLUSTER'
> > ##
> > redundant-ether-options {
> > ##
> > ## '1' was inherited from group 'SRX34X-CLUSTER'
> > ##
> > redundancy-group 1;
> > }
> > unit 0 {
> > family inet {
> > address 100.64.0.1/24;
> > }
> > }
> > }
> > ...
> > ##
> > ## 'st0' was inherited from group 'EXAMPLE-VPN'
> > ##
> > st0 {
> > ##
> > ## '1' was inherited from group 'EXAMPLE-VPN'
> > ##
> > unit 1 {
> > ##
> > ## 'DCN VPN to srx110:st0.0' was inherited from group
> 'EXAMPLE-VPN'
> > ##
> > description "DCN VPN to srx110:st0.0";
> > ##
> > ## 'inet' was inherited from group 'EXAMPLE-VPN'
> > ##
> > family inet {
> > ##
> > ## '100.64.255.1/30' was inherited from group 'EXAMPLE-VPN'
> > ##
> > address 100.64.255.1/30;
> > }
> > }
> > }
> >
> > So Im a bit struck as to what is going wrong here. The only smoking gun
> I see is
> > that my reth subinterfaces appear to be "hardware down" with the parents
> > claiming "physical link down" when the config group is applied.
> > Remove it and everything returns to normal.
> >
> > Ive tried defining the st0 interface and unit 1 within the interfaces
> stanza, but
> > that didnt help. What am I missing? What can I look at? Am I trying to do
> > something that simply cant be done?
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__puck.nether.net_mailman_listinfo_juniper-
> > 2Dnsp&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=d9gDdGNcoyIZFOkxOo1dADabVVg_rE5cKQZu_QMI8Hk&
> > m=pbvoXfrsWWG2AejgZuYLRNCGz2KG0wDUO6hZEv3dwig&s=No81uUiLk860z8
> > abg7QbrfxmkE862tvj2hO7m6VfdTc&e=
>
More information about the juniper-nsp
mailing list