Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Soft delete BGP Groups, IX's and BGP Sessions to allow for idempotent configs #301

Open
mngan opened this issue Oct 10, 2020 · 1 comment · May be fixed by #306
Open

Soft delete BGP Groups, IX's and BGP Sessions to allow for idempotent configs #301

mngan opened this issue Oct 10, 2020 · 1 comment · May be fixed by #306
Labels
status: accepted type: enhancement Issue is considered as an enhancement to the code, so it is not a regression nor a blocking issue
Milestone

Comments

@mngan
Copy link
Contributor

mngan commented Oct 10, 2020

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

local ip = 1.1.1.1
peer ip = 1.1.1.2
local as = 32590
peer as = 1234
bgp_group = AS1234-DUMMY

Which generates something like this:

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
  !
  neighbor 1.1.1.2 peer group as1234-dummy-v4
  neighbor 1.1.1.2 remote-as 1234
  neighbor 1.1.1.2 description "Dummy Corp"
  no neighbor 1.1.1.2 shutdown
!

But if I delete the BGP session, the generated config looks like this

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
  !
!

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
!

Example template code

{% if session.deleted %}
  no neighbor {{ session.ip_address }}
{% else %}
  neighbor {{ session.ip_address }} peer group {{ bgp_group.slug }}
  neighbor {{ session.ip_address }} remote-as {{ session.autonomous_system.asn }}
  neighbor {{ session.ip_address }} description "{{ session.autonomous_system.name }}"
  {% if session.enabled %}
  no neighbor {{ session.ip_address }} shutdown
  {% else %}
  neighbor {{ session.ip_address }} shutdown
  {% endif %} 
{% endif %}

External Dependencies

django-safedelete

@gmazoyer gmazoyer added the type: enhancement Issue is considered as an enhancement to the code, so it is not a regression nor a blocking issue label Oct 11, 2020
@gmazoyer gmazoyer added this to the v2.0 milestone Oct 11, 2020
@gmazoyer
Copy link
Member

Same FR as #86 (mentioned for tracking)

@mngan mngan linked a pull request Oct 18, 2020 that will close this issue
@stale stale bot added the status: wontfix Not an issue, no fix to be done, no code to be changed label Jul 12, 2021
@peering-manager peering-manager deleted a comment from stale bot Jul 12, 2021
@stale stale bot removed the status: wontfix Not an issue, no fix to be done, no code to be changed label Jul 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: accepted type: enhancement Issue is considered as an enhancement to the code, so it is not a regression nor a blocking issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants