Best practice for modelling Prefixes under an Aggregate #20039
-
|
Hi all, I've inherited a setup with a mix of ways of modelling things and I'm trying to tidy up to a consistent set of best-practices. One thing I'm curious about is what should come under an Aggregate:
I think the former, but i'm not sure if I'm missing something. Thanks. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
|
I do option 2 - create a container prefix that is the same size as the aggregate. I like to separate their functions because they have different attributes for different purposes (e.g. you can assign a role, vrf, etc to a prefix but not an aggregate). I think of the Aggregate as an "administrative" object and a top-level Prefix container as the actual IPAM object. That is to say I wouldn't configure a device by using the Aggregate, but I would refer to the Aggregate when looking up what IP space we own, for example. I also have custom fields on our aggregates with registration and allocation information that I don't need on the prefixes. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, I'll keep the ones that are modelled that way and fix the others to match. |
Beta Was this translation helpful? Give feedback.
I do option 2 - create a container prefix that is the same size as the aggregate. I like to separate their functions because they have different attributes for different purposes (e.g. you can assign a role, vrf, etc to a prefix but not an aggregate).
I think of the Aggregate as an "administrative" object and a top-level Prefix container as the actual IPAM object. That is to say I wouldn't configure a device by using the Aggregate, but I would refer to the Aggregate when looking up what IP space we own, for example. I also have custom fields on our aggregates with registration and allocation information that I don't need on the prefixes.