cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3603
Views
10
Helpful
9
Replies

OSPFv3 Authentication IPSEC SPI/Logging issues

pbgrasso81
Level 1
Level 1

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. 

1 Accepted Solution

Accepted Solutions

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,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

View solution in original post

9 Replies 9

Harold Ritter
Cisco Employee
Cisco Employee

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,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

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.  

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,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Oh wow, thanks for recreating that Harold. Much appreciated. I will indeed ask that it be filed as a bug. 

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,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

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

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. 

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...

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: