You're position sounds like "I can't think of any reason to use distribute-lists, therefore everybody should avoid them as there are newer methods" which doesn't answer the question, is there X, Y, and Z data that explains why distribute-lists should not be used?
Lacking evidence of value is not the same thing as evidence of lacking value. Implementing a protocol-wide change with a single entry sounds like a decent reason to use a distribute-list, possibly on an ad-hoc basis. This would be administratively much easier (ie better) than adjusting a bunch of prefix-lists and/or route-maps. Nick Hilliard did comment that distribute-lists are processed linearly vs a hash/tree lookup method like prefix-lists which sounds like useful information to me, though how that compares to a distribute-list fed by a prefix-list is not clear. Myself having right around zero experience implementing distribute-lists, I find this discussion informative. Thanks for the input everyone! ________________________________ From: Mark Tinka [[email protected]] Sent: Friday, October 28, 2016 2:17 AM To: Justin Krejci; Nick Cutting; Jared Mauch Cc: [email protected] Subject: Re: Cisco distribute-list configs On 28/Oct/16 01:30, Justin Krejci wrote: (Starting new thread based on the already deviated branch) What about a distribute-list using a prefix-list instead of an ACL? Why create another unnecessary layer? In lieu of using a distribute list that in-turn, references a prefix list, just use the prefix list natively. Always go for the as much solid state as you can, i.e., fewer moving parts. Mark. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
