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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[email protected]"
