IPFW tables trouble

[Daniel Kalchev]

On 17.05.12 09:49, Alexander V. Chernikov wrote:
>>  From time to time, ipfw spews errors like this:
>>
>> Non-unique normal route, mask not entered
>> Non-unique normal route, mask not entered
>>
>> or
>>
>> rn_delete: couldn't find our annotation
>> rn_delete: couldn't find our annotation
>> rn_delete: couldn't find our annotation
>
>
> It seems that under some conditions mask is passed incorrectly to 
> radix code. Wrong mask can be generated by ipfw module if userland 
> passes value larger that 32. What is funny that kernel still doesn't 
> check mask value in case of IPv4.
>
> Can you update your 9-stable, add something like the following:
[...]

I will most certainly try that. However, it is very unlikely the script 
that generates the list produces such values. Just in case, I added 
explicit check in the script to warn me if this ever happens.

>>
>> Sometimes, after such output, if one does:
>>
>> ipfw table 1 flush
>> ipfw table 1 list
>>
>> the output is non-empty. It should be empty, right?
>
> Can you show an examples for such output ?
>
> How often does this happen ?
>

It gives a list of prefix/mask just like in the source lists

193.68.223.206/31
193.68.223.208/30
193.68.223.213/32
193.68.223.214/31

I will try to capture an exact list when it happens.

How often... it's not trivial to reproduce, unfortunately. All these 
routers run both BGP (full routing table) and OSPF in rather large area. 
But I am confident it is guaranteed to happen at a major routing glitch. 
It looks like there is some concurrency involved and perhaps ipfw is not 
locking resources properly when manipulating tables.

Daniel