Closed ssasso closed 1 month ago
Agreed. I was thinking about something along these lines for quite a while (generic route-map functionality). Starting with "you can have a predictable route-map name" is a good idea.
I would simplify the attribute to bgp.policy, and use the presence of that attribute to indicate we want to have an inbound and outbound route map (in most implementations, a missing route-map is a no-op). That attribute could have a boolean value (True) to say "I want a route map, but choose any name you want"
However, there's a "slight" problem if we want to combine the other BGP policy attributes with a route map. Do we check whether all neighbors using the same bgp.policy value have the same set of attributes, or do we trust the user(s) not to do anything stupid (given how creative some people can get, that makes me a bit nervous).
Any thoughts?
However, there's a "slight" problem if we want to combine the other BGP policy attributes with a route map. Do we check whether all neighbors using the same bgp.policy value have the same set of attributes, or do we trust the user(s) not to do anything stupid (given how creative some people can get, that makes me a bit nervous).
To avoid people creativity I would create a check to not allow to use the same policy name in multiple places.
What about:
-in
and -out
route maps). Even better, we could have the bgp.policy.in and bgp.policy.out attributes (I'd actually prefer this option, as it would tie nicely with the other ideas I'm mulling about)I would hate to ask for unique policy name per neighbor, as I'd like to have a system where I can apply the same route-map to multiple neighbors (for example, all customers)
That's ok for me, but I'd like to add another point to the list, that could be useful.
You can define (or - you need to define) the "custom policy" name also at node level, and there you can add the "standard" attributes (standard = the ones we are already able to manage with the current templates).
In that way we can reuse the existing jinja templates for the attributes we already support.
I would define the "custom policy" on the global level, so it can be reused across nodes. In the first iteration it might not check the node support for attributes (unless it's reasonably easy to do).
But yeah, I agree that it should be semantic icing that gets translated into existing Jinja2 templates.
After mulling this over for a bit, here's the plan:
Would that work for you? How soon do you need this?
that looks perfect for me.
no rush, I am managing this with custom templates/plugins for now :)
but having this for end of summer would be great :)
Implemented in #1238 and #1239
It would be great if the
bgp.policy
plugin will allow to create/append an empty policy to a neighbor. Allowing to define also the policy name would be a nice bonus.In this way we can "attach" a route-map to a neighbor, which can easily be used (populated) by external/custom configuration scripts without the need to worry about the neighbor IP address (and eventually the policy name).
Example:
bgp.create_empty_policy
will be considered only if no other attribute is present (as a sort of fallback),https://github.com/ipspace/netlab/blob/63c3bc7427cacdce3a055d344ac1b892c1803336/netsim/extra/bgp.policy/plugin.py#L204
and could create a route map with
permit 99
or sth similar, with no match/set clauses.Then the route map needs to be linked to a neighbor (but the plugin is already capable of that).
policy_name_prefix
could be used to create the two policy names,<prefix>-in
and<prefix>-out
.