You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, there is no way to safely remove a BGP group or Peering session from an EOS (possibly IOS too) style config. This is because objects are hard deleted. There is no information passed to the template that can tell it to remove a group or session that had previously been configured. By soft deleting these objects, the deleted objects can be passed down to the template, and appropriately handled.
The package django-safedelete handles this pretty well. It even handles some of the edge cases (e.g re-add a session that was previously deleted, and cascading soft deletes).
Use Case
Deploy a bgp group with a session
local ip = 1.1.1.1
peer ip = 1.1.1.2
local as = 32590
peer as = 1234
bgp_group = AS1234-DUMMY
which leaves the neighbor 1.1.1.2 still configured. With the deleted added to the soft deletable objects, you can detect these and add in the appropriate config like so:
router bgp 32590
no bgp default ipv4-unicast
!
neighbor as1234-dummy-v4 peer group
neighbor as1234-dummy-v4 next-hop-self
!
address-family ipv4
neighbor as1234-dummy-v4 activate
!
no neighbor 1.1.1.2
!
Proposed Functionality
Currently, there is no way to safely remove a BGP group or Peering session from an EOS (possibly IOS too) style config. This is because objects are hard deleted. There is no information passed to the template that can tell it to remove a group or session that had previously been configured. By soft deleting these objects, the deleted objects can be passed down to the template, and appropriately handled.
The package django-safedelete handles this pretty well. It even handles some of the edge cases (e.g re-add a session that was previously deleted, and cascading soft deletes).
Use Case
Deploy a bgp group with a session
Which generates something like this:
But if I delete the BGP session, the generated config looks like this
which leaves the neighbor 1.1.1.2 still configured. With the
deleted
added to the soft deletable objects, you can detect these and add in the appropriate config like so:Example template code
External Dependencies
django-safedelete
The text was updated successfully, but these errors were encountered: