RE: RANCID filter_audit

Quoting Yuval Ben-Ari <[email protected]>:

>=20
> > No, I'm thinking of something that (gasp) I had with the IBM=20
> > 360 assembler and
> > other compilers and assemblers.
> >=20
> > At the end of a configuration (to start), it would list an=20
> > address (or a
> > subnet), and tell you all the statements that referenced it.=20
> > For example,
> >         ip address
> >         access-list (and probably indirect references in maps)
> >         ospf network statements
> >         server references
> >         static routes
> > as a starting point.  In other words, it tells you EVERYWHERE=20
> > you need to make
> > changes when you change an address or something affecting it.
> >=20
> > The next step would be to extend the scope beyond a single=20
> > router, grabbing the
> > hostname to prefix the cross-reference. Again, the idea is=20
> > that if an address
> > changes, you have a positive confirmation of every=20
> > configuration that may need
> > to be changed.  It's also a debugging tool, because you know=20
> > which routers
> > affect that address.
> >
>=20
> I don't think it's something I can have use for very often. (IP address
> changes).

Unfortunately, I suppose, it's something I do fairly often, as, for examp=
le,
when a small ISP gets its first PI allocation. Alternatively, we can come=
 into
an existing ISP that really hasn't been documenting, and we have to both =
create
current documentation and rationalize the addressing and performance.  I =
agree
it would be needed much less often in a running ISP, unless you have the
misfortune to have to deal with networks redefined by merger, acquisition=
, or
divestiture.

> this also sounds it could be tricky to program

Agreed. At a minimum, you have to recognize:
    1. The /32 address itself
    2. The address if contained in a /length or under a subnet mask
    3. The address if contained in an inverse mask (access list or ospf
       network statment)

> I use primitive checks like: "sh run | inc x\.y\.z\." to catch config
> that might refer to the subnet.
> also on clean config I think you should refere to ip address as least a=
s
> possible. (f.e. static route point to interface will not require any
> changes)
>=20


True about the specifying an interface on a static route, but that does h=
ave
different behavior than using a next-hop address. In particular, using th=
e
interface reference can't force recursion, so if that next-hop address is=
 not
adjacent and dynamic routing fails to get it into a routing table, you th=
en have
a recognizable error condition. Of course, you can potentially get out of=
 such
an error by having additional static routes with=20