[rancid] Repetitive RANCID Checks

Alan McKinnon alan.mckinnon at gmail.com
Sat May 17 07:08:41 UTC 2014

On 16/05/2014 20:25, heasley wrote:
> Thu, May 15, 2014 at 04:44:46PM +0200, Alan McKinnon:
>> I see what the bug is here, the solution probably needs list discussion
>> first.
>> With rancid-2.3.8 and perl-5.18, ipv6 prefix-lists are always output in
>> random order if ACLSORT=yes
>> The cause is twofold:
>> 1. "sub ipaddrval" is ipv4-specific and cannot deal with ipv6 addresses
>> properly, so sortbyipaddr() doesn't work as intended. I believe that
>> %history in ProcessHistory() is not being sorted at all
>> 2. A recent perl version re-implemented hashes to guarantee that keys
>> are randomly ordered internally and different between runs of the same
>> script. The previous implementation would order the same data
>> consistently between invocations.
> bugger.  thanks for that.  another user was asking about this problem and
> i was having trouble recreating it.

To recreate it reliably, have a sort function (the ones with automagic
$a and $b) return a 0.

This never happens with sortbyipaddr and ipv4 addresses as they are
always different and you always get a reliable sort

>> So ipv6 prefix-list ordering just happened to work with <perl-5.18
>> because %history just happened to be consistently ordered.
>> Solutions:
>> 1. Implement ipv6 sorting in sortbyipaddr(). I really want to find an
>> excuse not to do this (being essentially a lazy bum at heart)
>> 2. Why are we sorting these lists by ip address? Surely sorting 1) by
>> prefix name then 2) by seq makes more sense? This is what my NetOps
>> colleagues would like to see happen.
> the sequences just tend to create noise, esp. when the whole list is
> reloaded (therefore renumbered), and hides the actual change or makes it
> less obvious.

I think we should document more explicitly what ACLSORT achieves. I was
under the impression for years that it ensures lists are sorted in
evaluation order if show run were to display them mixed them up a bit.
Then I read the code in detail :-)

When does a list reload occur? My NetOps colleagues maintain it only
happens when the router itself is rebooted, and they don't care about
that (the diff after a reboot is already quite large)

Alan McKinnon
alan.mckinnon at gmail.com

More information about the Rancid-discuss mailing list