Mailing List Archive

MX480 ospf3 ipsec jammed?
Hey guys,

Getting something interesting after a reboot;

Jun 16 01:58:45  MX480.1 kernel: ipsec_find_sa_in_so_gen(1999): Couldn't
dereference the sa name = XXXXXXXXXX

When trying to bring up the IPSec tunnel for ospf3 peering ( which never
establishes ), any ideas what this means? Do I need to restart the ipsec
key daemon?

--
Scott H.

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: MX480 ospf3 ipsec jammed? [ In reply to ]
Silly question, does the sa name match between "ospf3...ipsec-sa FOO"
and "security ipsec security-association FOO..."?

What does "show ipsec security-associations" show?

What Junos version? There was a memory leak or file descriptor leak
in older Junos that killed the ipsec daemon after a long uptime, but I
don't recall anything that would cause it to fail right after reboot.
But you can try "restart ipsec-key-management" anyway.

On Sat, Jun 15, 2019 at 09:02:30PM -0500, Scott Harvanek wrote:
> Hey guys,
>
> Getting something interesting after a reboot;
>
> Jun 16 01:58:45? MX480.1 kernel: ipsec_find_sa_in_so_gen(1999): Couldn't
> dereference the sa name = XXXXXXXXXX
>
> When trying to bring up the IPSec tunnel for ospf3 peering ( which never
> establishes ), any ideas what this means? Do I need to restart the ipsec
> key daemon?
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: MX480 ospf3 ipsec jammed? [ In reply to ]
I’ll get those outputs when at a terminal but the configuration did not change and this was working pre reboot :/

The only other change was a failed MPC that was replaced.

Downstream devices are sending HELLOs but this 480 is not indicating it’s receiving them via ospf3 stats output which is weird but connectivity is good.

-Scott H

> On Jun 16, 2019, at 2:08 AM, Anderson, Charles R <cra@wpi.edu> wrote:
>
> Silly question, does the sa name match between "ospf3...ipsec-sa FOO"
> and "security ipsec security-association FOO..."?
>
> What does "show ipsec security-associations" show?
>
> What Junos version? There was a memory leak or file descriptor leak
> in older Junos that killed the ipsec daemon after a long uptime, but I
> don't recall anything that would cause it to fail right after reboot.
> But you can try "restart ipsec-key-management" anyway.
>
>> On Sat, Jun 15, 2019 at 09:02:30PM -0500, Scott Harvanek wrote:
>> Hey guys,
>>
>> Getting something interesting after a reboot;
>>
>> Jun 16 01:58:45 MX480.1 kernel: ipsec_find_sa_in_so_gen(1999): Couldn't
>> dereference the sa name = XXXXXXXXXX
>>
>> When trying to bring up the IPSec tunnel for ospf3 peering ( which never
>> establishes ), any ideas what this means? Do I need to restart the ipsec
>> key daemon?

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: MX480 ospf3 ipsec jammed? [ In reply to ]
show ipsec security-associations
Security association: tusldc2-distribution
    Direction SPI         AUX-SPI     Mode       Type     Protocol
    inbound   256         0           transport  manual AH
    outbound  256         0           transport  manual   AH

Junos: 16.1R4-S2.2

Scott H.
Login, LLC

On 6/16/19 11:20 AM, Scott Harvanek wrote:
> I’ll get those outputs when at a terminal but the configuration did not change and this was working pre reboot :/
>
> The only other change was a failed MPC that was replaced.
>
> Downstream devices are sending HELLOs but this 480 is not indicating it’s receiving them via ospf3 stats output which is weird but connectivity is good.
>
> -Scott H
>
>> On Jun 16, 2019, at 2:08 AM, Anderson, Charles R <cra@wpi.edu> wrote:
>>
>> Silly question, does the sa name match between "ospf3...ipsec-sa FOO"
>> and "security ipsec security-association FOO..."?
>>
>> What does "show ipsec security-associations" show?
>>
>> What Junos version? There was a memory leak or file descriptor leak
>> in older Junos that killed the ipsec daemon after a long uptime, but I
>> don't recall anything that would cause it to fail right after reboot.
>> But you can try "restart ipsec-key-management" anyway.
>>
>>> On Sat, Jun 15, 2019 at 09:02:30PM -0500, Scott Harvanek wrote:
>>> Hey guys,
>>>
>>> Getting something interesting after a reboot;
>>>
>>> Jun 16 01:58:45 MX480.1 kernel: ipsec_find_sa_in_so_gen(1999): Couldn't
>>> dereference the sa name = XXXXXXXXXX
>>>
>>> When trying to bring up the IPSec tunnel for ospf3 peering ( which never
>>> establishes ), any ideas what this means? Do I need to restart the ipsec
>>> key daemon?
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp