Discussion:
[j-nsp] Apply-group brain fart
Tom Storey
2018-08-24 10:05:21 UTC
Permalink
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]
***@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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Balasankar Rajaguru
2018-08-27 07:27:56 UTC
Permalink
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-----
Storey
Sent: Friday, August 24, 2018 3:35 PM
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
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
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
groups {
EXAMPLE-VPN {
interfaces {
st0 {
unit 1 {
description "DCN VPN to srx110:st0.0";
family inet {
address 100.64.255.1/30;
}
}
}
}
}
}
{primary:node0}[edit]
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?
_______________________________________________
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=
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Tom Storey
2018-08-28 09:35:49 UTC
Permalink
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
Post by Balasankar Rajaguru
Hi Tom,
Post by Tom Storey
Ive tried defining the st0 interface and unit 1 within the interfaces
stanza, but
Post by Tom Storey
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
Post by Tom Storey
-----Original Message-----
Storey
Sent: Friday, August 24, 2018 3:35 PM
Subject: [j-nsp] Apply-group brain fart
Hi everyone. I am trying to build some configuration groups with the
intention of
Post by Tom Storey
keeping related configuration for some IPSEC VPNs etc nicely contained
in one
Post by Tom Storey
spot - define all relevant configuration in a group and apply it in one
go, and also
Post by Tom Storey
remove it *all* when you delete and remove the configuration group. This
way,
Post by Tom Storey
hopefully, little bits and pieces dont get left behind as VPNs are set
up and torn
Post by Tom Storey
down, ideally maintaining a cleaner configuration.
But I have an odd situation. I am working with a cluster of SRX345, and
it seems
Post by Tom Storey
that when ever I apply a config group with an st interface defined, my
default
Post by Tom Storey
route disappears and some connected routes seem to disappear or change
from
Post by Tom Storey
local to reject, and I lose the ability to manage the cluster via SSH
and have to
Post by Tom Storey
use the console. The same does not happen on a standalone SRX110.
For example, prior to applying the configuration, my routing table looks
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
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
Post by Tom Storey
groups {
EXAMPLE-VPN {
interfaces {
st0 {
unit 1 {
description "DCN VPN to srx110:st0.0";
family inet {
address 100.64.255.1/30;
}
}
}
}
}
}
{primary:node0}[edit]
Pretty straight forward I thought...
In the configuration, after the commit has completed (no complaints) I
do see
Post by Tom Storey
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
Post by Tom Storey
addresses.
# show interfaces | display inheritance
...
reth2 {
description UNTRUST;
##
## 'redundant-ether-options' was inherited from group
'SRX34X-CLUSTER'
Post by Tom Storey
##
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'
Post by Tom Storey
##
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'
Post by Tom Storey
##
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
Post by Tom Storey
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
Post by Tom Storey
that didnt help. What am I missing? What can I look at? Am I trying to do
something that simply cant be done?
_______________________________________________
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=
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Loading...