Skip to content
This repository has been archived by the owner on Jun 10, 2024. It is now read-only.

BGP global and AF context resource model discussion for Ansible Networking supported platforms #582

Closed
justjais opened this issue Dec 29, 2020 · 10 comments

Comments

@justjais
Copy link
Contributor

BGP global and AF context resource model

  1. *_bgp_global:
  • As the device supports only 1 BGP instance/device it’ll support config of dict and coz of that it doesn't require overridden operation, so the module would support Merge, Replace, Delete, and Purged operations and not the Overridden operation.
  • *_bgp_global module would be expected to config BGP only at global context level and nothing WRT config related to address family context
  • Replace operation: Only the global context-related config would be replaced with the global BGP existing config and the address family context config will be left untouched.
  • Delete operation: *_bgp_global is supposed to delete only the global BGP level configurations, so delete functionality would be limited here and it won’t be able to delete the configured router BGP itself.
  • Purged operation: This state will be added for the resource module which follows the parent-child relationship and as BGP resource module supports the respective relationship with *_bgp_global and *_bgp_af resource module, *_bgp_global would support the purged state operation and thus would be able to delete at parent config level which in case of BGP is negating the router BGP configurations.
  • Module facts would show only Global context-related config
  1. *_bgp_af:
  • As global BGP can have multiple AF with different config it would accept the list of dict, so the module would support all Merge, Replace, Overridden, and Delete operations.
  • AF resource module will be expected to do configuration only related to AF context and touch nothing WRT to the global context
  • Delete operation: It would deal only with AF context-related delete
  • Purged operation: Not available for the respective module as purged operations are supported and available only with the parent resource module.
  • Module facts would show only AF related config

BGP Global:

Existing Device Config:

Replace Operation:
Before State:

Nexus9000v# sh running-config | section '^router bgp'
router bgp 65000
  graceful-restart-helper
  address-family ipv4 multicast
  address-family ipv4 unicast
    default-information originate

Commands fired:

- router bgp 65000
-  no graceful-restart-helper

After State:

Nexus9000v# sh running-config | section '^router bgp'
router bgp 65000
  address-family ipv4 multicast
  address-family ipv4 unicast
    default-information originate

Delete Operation: It would delete only the global resource module configured params and if AF family configurations are present it won’t be affected which in turn means that delete operation will not fire the following command: no router bgp 65000 which leads to deletion of the complete BGP configuration.
Before State:

Nexus9000v# sh running-config | section '^router bgp'
router bgp 65000
  graceful-restart-helper
  address-family ipv4 unicast
    default-information originate

Commands fired:

- router bgp 65000
- no graceful-restart-helper

After State:

Nexus9000v# sh running-config | section '^router bgp'
router bgp 65000
  address-family ipv4 unicast
    default-information originate

Purge Operation: This operation would delete at parent level i.e. this operation would fire the command: no router bgp 65000 and even if the BGP config has both global and AF context configuration set with Purge operation user gets the ability to delete at Parent level i.e. negating at the router BGP level:

Before State:

Nexus9000v# sh running-config | section '^router bgp'
router bgp 65000
  graceful-restart-helper
  address-family ipv4 unicast
    default-information originate

Commands fired:

- no router bgp 65000

After State:

Nexus9000v# sh running-config | section '^router bgp'
Nexus9000v#

This repository is for the management of all Ansible community related initiatives, such as meetings.
Ansible Support

@bmillemathias
Copy link

as written in the template of the bug report, this project is not for issue in code but for community management.

@justjais
Copy link
Contributor Author

@bmillemathias respective issue is not a code issue, I've opened this issue to take the networking BGP resource model up for discussion and getting feedback from the community.

@GomathiselviS
Copy link

GomathiselviS commented Jan 5, 2021

BGP Address Family:

*_bgp_af module will have config as a dict , because the address family needs to be associated with an as number ( which will be one instance per device). Config will have address_family as a key whose value will be a list of dict. All the operations will be done at the address_family level. The bgp global configurations will remain untouched.

Following are few examples for Arista EOS platform:

Existing Device Config:

Before State:

router bgp 10
   timers bgp 2 5
   maximum-paths 10
   neighbor peer1 peer-group
   neighbor peer1 maximum-routes 12000 
   redistribute ospf match nssa-external
   !
   address-family ipv4
      bgp next-hop address-family ipv6
      neighbor peer1 default-originate
      neighbor peer1 next-hop-unchanged
   !
   address-family ipv6 labeled-unicast
      bgp additional-paths receive

Replace Operation:

Commands fired:

router bgp 10
  address-family ipv4
    no bgp next-hop address-family ipv6
    no neighbor peer1 default-originate
    no neighbor peer1 next-hop-unchanged
    graceful-restart

After State:

router bgp 10
   timers bgp 2 5
   graceful-restart restart-time 300
   maximum-paths 10
   neighbor peer1 peer-group
   neighbor peer1 maximum-routes 12000 
   redistribute ospf match nssa-external
   !
   address-family ipv4
       graceful-restart
   !
   address-family ipv6 labeled-unicast
      bgp additional-paths receive

Overridden:

Commands fired:

router bgp 10
no address-family ipv4
address-family ipv6 labeled-unicast
no bgp additional-paths receive
bgp next-hop-unchanged 

After State:

router bgp 10
   timers bgp 2 5
   graceful-restart restart-time 300
   maximum-paths 10
   neighbor peer1 peer-group
   neighbor peer1 maximum-routes 12000 
   redistribute ospf match nssa-external
   !
   address-family ipv6 labeled-unicast
      bgp next-hop-unchanged 

Deleted:

Commands fired:

router bgp 10
no address-family ipv6 labeled-unicast

After State:

router bgp 10
   timers bgp 2 5
   graceful-restart restart-time 300
   maximum-paths 10
   neighbor peer1 peer-group
   neighbor peer1 maximum-routes 12000 
   redistribute ospf match nssa-external
   !
   address-family ipv4
      bgp next-hop address-family ipv6
      neighbor peer1 default-originate
      neighbor peer1 next-hop-unchanged
   !

@justjais
Copy link
Contributor Author

justjais commented Jan 6, 2021

Detailed resource model for Cisco IOS, plz refer:

@mikewiebe
Copy link
Contributor

Are there plans to create resource modules for BGP neighbor config and BGP neighbor address-family configs?

@mikewiebe
Copy link
Contributor

Do you have a list of global and address-family options that will be supported?

@mikewiebe
Copy link
Contributor

During a discussion with @NilashishC today I want to make sure the following scenario would be handled correctly.

Consider the following BGP configuration

router bgp 55
  router-id 10.2.0.5
  neighbor 10.2.0.1
    bfd
    remote-as 55
    update-source loopback0
    address-family l2vpn evpn
      send-community
      send-community extended
      route-reflector-client
  neighbor 10.2.0.2
    bfd
    remote-as 55
    update-source loopback0
    address-family l2vpn evpn
      send-community
      send-community extended
      route-reflector-client
  neighbor 10.2.0.3
    bfd
    remote-as 55
    update-source loopback0
    address-family l2vpn evpn
      send-community
      send-community extended
      route-reflector-client

In this example, there are 3 parent neighbors and each of them have child address-family configuration underneath. If the user wants to remove the address-family configuration under each neighbor I understand that the _bgp_af module would be used but we also need to be able to remove individual neighbors once that address-family config is gone.

For example, let's say I want to remove neighbor 10.2.0.3 using the *_bgp_global module with state replaced. As long as there is no address-family configuration I should be able to create a playbook that does not define this neighbor and the result of the replaced operation would be to remove that neighbor.

From what I understand this is not the current behavior of the modules.

@NilashishC
Copy link
Contributor

@mikewiebe Thank you for bringing this up. We have decided to update the behaviour of the bgp_global module for every platform where the use case you mentioned is valid. The module now inspects the running-config to determine if there are address-family configurations in the following contexts:

  • address-family under a VRF
  • address-family under a top-level neighbor
  • address-family under a VRF neighbor

The module throws an error if:

state: replaced and we're trying to remove an element that falls in the above three cases.
state: deleted and one or more of the above cases holds true.

For NX-OS, the error messages are currently in the following format:

Neighbor 203.0.113.2 has address-family configurations. Please use the nxos_bgp_neighbor_af module to remove those first.

VRF site-1 has address-family configurations. Please use the nxos_bgp_af module to remove those first.

These will be updated when the nxos_bgp_address_family Resource Module is released (February'21).

The integration test case in ansible-collections/cisco.nxos@615f4e0#diff-04f5e691d372b7935f3d01ec200eb2ebf8845660c35a2aef746e10883083067aR2 demonstrates this behaviour change.

Thanks!

@mikewiebe
Copy link
Contributor

Excellent! Thanks for the update @NilashishC

@trishnaguha
Copy link
Member

Closing the issue as the modules were merged and released.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants