Loop prevention drops

[okatsladz454]

Good afternoon.


We are faced with the following problem - some of the packets going to certain Internet addresses are dropped at the kernel level with an error (find it in zdebug + drop):

resume_inbound_from_vm_reinject: dropping packet of for vsid=0 due to loop prevention (nloops=4, pkt_type VM Reinject, prev state Lookup, next state Lookup, in flags 0x4). 

Gaia version: R82 take 44 Maestro (Any problems with distribution and asymmetric excluded)

There are two connections - intranet and extranet, both transmit routes via BGP.

The problem occurs only on a part of the connections and only to connections at certain white addresses. There are no problems with other connections that use the same access control policy rules and the same logic.


Questions:

1. What does loop prevention even mean? Does this apply to STP? Or to routing and loop protection in BGP? fwaccel stats -d showing huge amount of drops caused by Loop prevention

2. Any clues, how to fix this?

[the_rock]

I cant seem to open image you attached (this seems to be an issue with everyone lately, anything attached shows virus scan in progress...maybe @_Val_ or @PhoneBoy can comment on that part).

Now, as far as your issue...definitely STP can be related...is it enabled or not?

[PhoneBoy]

Will check on the virus scan issue.

[the_rock]

Not a huge issue, but I did notice it for everyone whose attachments I tried opening last few days...

[PhoneBoy]

Seems to be a known issue that is in the process of being addressed.

[okatsladz454]

Thanks for the reply. I don't think STP has any effect - if it did, then loop protection would occur on all traffic, and not just on a very specific one. I need to understand specifically what loop prevention generally refers to.

[the_rock]

Usually, should be enabled.

[Chris_Atkinson]

Are these drops for legitimate traffic flows or just something that you've observed?

How is the routing configured for the subnet in question on the Firewall and downstream device...

[okatsladz454]

Good morning.

This directly affects the third party of VPN tunnels going through the firewall. Not all of them, just not a very large part, but we don't have an answer as to why these particular tunnels are affected and other are not. 

Routing is set up very simply - down (to the LAN of the organization) via BGP, up (to the provider) also via BGP, but using a public ASN.

[the_rock]

Is there any difference with those tunnels? route or domain based?

[okatsladz454]

I see no diffrence. 

They re all transit, check point just making a translation/ 

[the_rock]

Might be worth TAC case then to check further.

[the_rock]

Hey mate,

Were you able to make any progress with this?

[okatsladz454]

Good afternoon. The case in TAC was just started yet. We were waiting for the installation to be updated to the new JHF, but unfortunately it didn't help.

[_Val_]

Please open a TAC request for this via https://help.checkpoint.com

[Gennady]

Good day!

As a guess, I recommend to check output of "fwaccel ranges" command to find out if the problematic white IP-addresses are present in more than one range.

1. use "fwaccel ranges -l" to list all the ranges associated with interfaces.

2. use "fwaccel ranges -p" to see the list of networks as your SGM see it in Topology for an interface. It may be a very long list for your Internet facing interface.

The loop prevention seems to be related more to routing decision function performed in SecureXL before sending a packet out of an interface. The problem may occur in case if the same network/IP is present in more than one "anti-spoofing" range. Another way to check the same would be to analyze your routes carefully but it would not exclude any bug in topology calculation. "fwaccel ranges" from the other hand will show you exactly how routing is seen by SecureXL topology and may help to find the problem.

[Claudio_Bolcato]

Did you manage to fix the issue?
I'm experiencing the same problem and I've a TAC case open and they gave me an hotfix but the kernel debug is keep showing drops due to loop prevention. I'm running R82 take 44