11-09-2021 03:29 PM
Hello,
I'm running into a problem with our Cisco ASR-1002HX and ASR-1006X. I have a mix of Juniper and Cisco routers all configured exclusively with IPv6. All of our routers are in the same ospfv3 area 0. We are required to configure OSPF authentication. With ospfv3 and IPv6, we have to do that using ipsec encryption and authentication. Due to the different ways each vendor does this, we decided with our Cisco routers to apply the ipsec configurations at the area level. This is causing an obnoxious problem though. As you can see in the basic drawing I attached, we have several encryption devices throughout our network. The problem that we are seeing is that the encryption devices are sending ipsec packets to each other for their tunnels and the routers are logging that it is receiving ipsec packets with an invalid SPI. There is no issues with our tunnels. The routers continue to forward the packets without issue. The only real problem is that our logs are absolutely flooded with invalid SPI logs. If anyone has any recommendations, I'm all ears. I've opened a TAC case, but haven't received much help. They are pointing the blame to my encryption devices.
Solved! Go to Solution.
11-10-2021 01:59 PM - edited 11-10-2021 02:05 PM
Hi @pbgrasso81 ,
You are correct. The workarounds I proposed are not effective. I got the issue reproduced and thought I had it fixed with the proposed workarounds, but the log messages started appearing again as soon as I reactivated the transit IPsec traffic. It looks like the transit IPsec traffic is causing the messages to be logged, even though it doesn't have any effect on traffic as such. It is a cosmetic bug. You should definitely ask the TAC to file a bug for it.
Regards,
11-10-2021 09:51 AM
Hi @pbgrasso81 ,
A workaround for this issue would be to exclude the interface towards the encryption devices from area 0 and to use "redistribute connected" to propagate this subnet in OSPFv3.
The other workaround would be to enable the authentication at the interface level and not to enable it on the interface facing the encryption devices.
Regards,
11-10-2021 10:09 AM
Hi Harold,
Thank you for the suggestion, but I do not think that either solution will work. The problem is that the router is logging the messages in both directions. If you reference the topology I attached, Router A would be logging invalid SPI messages received on the interface connected to Switch A sourced from encryption device A. Additionally, it is logging invalid SPI messages on the port facing Router B sourced from Encryption device B. In our production network, we have dozens of these encryption devices so I don't believe that to be a feasible option either.
As for your second workaround, the logs (I assume) would still be present on the router to router links. Additionally, the reason we went with the area level was due to the two different ways that the vendors apply the configurations. With Juniper, you build out the security association and then simply apply it to the interfaces you want to authenticate ospf. The problem with interconnecting to Cisco, is that Cisco requires each SPI to be different when you configure it at the interface level. Changing at this point, would be quite a chore. Plus, as I mentioned previously, I think it would only partially work for the ipsec packets coming in on the passive interfaces down to our switches.
11-10-2021 01:59 PM - edited 11-10-2021 02:05 PM
Hi @pbgrasso81 ,
You are correct. The workarounds I proposed are not effective. I got the issue reproduced and thought I had it fixed with the proposed workarounds, but the log messages started appearing again as soon as I reactivated the transit IPsec traffic. It looks like the transit IPsec traffic is causing the messages to be logged, even though it doesn't have any effect on traffic as such. It is a cosmetic bug. You should definitely ask the TAC to file a bug for it.
Regards,
11-10-2021 02:03 PM
Oh wow, thanks for recreating that Harold. Much appreciated. I will indeed ask that it be filed as a bug.
11-10-2021 02:07 PM
You are very welcome. Please send me your TAC case number via email (harold@cisco.com) and I will work with TAC to get the bug filed.
Regards,
11-10-2021 11:25 PM
Hello,
on a side note, in order to keep the logs from getting flooded, you could configure logging discriminators. That at least will prevent the messages from showing up at all.
For the Cisco routers, it would look something like below (depending on the exact syslog message):
--> %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi
logging discriminator SPI severity drops 4 facility drops CRYPTO mnemonics drops RECVD_PKT_INV_SPI
logging buffered discriminator SPI 100000
logging console discriminator SPI
logging monitor discriminator SPI
logging host x.x.x.x discriminator SPI
For JunOS, have a look at the link below:
https://kb.juniper.net/InfoCenter/index?page=content&id=KB9382
11-12-2021 09:07 AM - edited 11-12-2021 09:08 AM
Thanks Georg, do you know if you can use more than one discriminator? We're already using a discriminator currently for some other messages. I couldn't find anything googling and won't be able to test until next week. Just curious if you knew off the top of your head. Thanks again.
11-12-2021 09:19 AM
Hello,
only one logging discriminator is allowed at a time...but you can use the /mnemonics drops/ in combination with a logical 'OR' to combine two discriminators.
If you post the logging discriminator you currently have, I'll try and figure out the syntax you need to combine both...
11-12-2021 09:33 AM
Thanks Georg, I'll see if I can figure it out. I'm familiar with the discriminators. I'll let you know if I need help.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide