matthew/sonic-buildimage
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
1fce3ebda3
sonic-buildimage/dockers/docker-fpm-frr/frr/bgpd/templates/general/policies.conf.j2

65 lines
1.7 KiB
Plaintext
Raw Normal View History

[bgpcfgd]: Split one bgp mega-template to chunks. (#4143) The one big bgp configuration template was splitted into chunks. Currently we have three types of bgp neighbor peers: general bgp peers. They are represented by CONFIG_DB::BGP_NEIGHBOR table entries dynamic bgp peers. They are represented by CONFIG_DB::BGP_PEER_RANGE table entries monitors bgp peers. They are represented by CONFIG_DB::BGP_MONITORS table entries This PR introduces three templates for each peer type: bgp policies: represent policieas that will be applied to the bgp peer-group (ip prefix-lists, route-maps, etc) bgp peer-group: represent bgp peer group which has common configuration for the bgp peer type and uses bgp routing policy from the previous item bgp peer-group instance: represent bgp configuration, which will be used to instatiate a bgp peer-group for the bgp peer-type. Usually this one is simple, consist of the referral to the bgp peer-group, bgp peer description and bgp peer ip address. This PR redefined constant.yml file. Now this file has a setting for to use or don't use bgp_neighbor metadata. This file has more parameters for now, which are not used. They will be used in the next iteration of bgpcfgd. Currently all tests have been disabled. I'm going to create next PR with the tests right after this PR is merged. I'm going to introduce better bgpcfgd in a short time. It will include support of dynamic changes for the templates. FIX:: #4231
2020-04-23 11:42:22 -05:00
!
! template: bgpd/templates/general/policies.conf.j2
!
!
!
[bgpcfgd]: Support default action for "Allow prefix" feature (#6370) * Use 20 and 30 route-map entries instead of 2 and 3 for TSA * Added support for dynamic "Allow list" default action. Co-authored-by: Pavel Shirshov <pavel.contrib@gmail.com>
2021-01-08 16:03:26 -06:00
{% if constants.bgp.allow_list is defined and constants.bgp.allow_list.enabled is defined and constants.bgp.allow_list.enabled and constants.bgp.allow_list.drop_community is defined %}
!
!
! please don't remove. 65535 entries are default rules
! which works when allow_list is enabled, but new configuration
! is not applied
!
{% if allow_list_default_action == 'deny' %}
!
[bgp] Add 'allow list' manager feature (#5513) implements a new feature: "BGP Allow list." This feature allows us to control which IP prefixes are going to be advertised via ebgp from the routes received from EBGP neighbors.
2020-10-02 12:06:04 -05:00
route-map ALLOW_LIST_DEPLOYMENT_ID_0_V4 permit 65535
set community no-export additive
!
route-map ALLOW_LIST_DEPLOYMENT_ID_0_V6 permit 65535
set community no-export additive
{% else %}
[bgpcfgd]: Support default action for "Allow prefix" feature (#6370) * Use 20 and 30 route-map entries instead of 2 and 3 for TSA * Added support for dynamic "Allow list" default action. Co-authored-by: Pavel Shirshov <pavel.contrib@gmail.com>
2021-01-08 16:03:26 -06:00
!
[bgp] Add 'allow list' manager feature (#5513) implements a new feature: "BGP Allow list." This feature allows us to control which IP prefixes are going to be advertised via ebgp from the routes received from EBGP neighbors.
2020-10-02 12:06:04 -05:00
route-map ALLOW_LIST_DEPLOYMENT_ID_0_V4 permit 65535
set community {{ constants.bgp.allow_list.drop_community }} additive
!
route-map ALLOW_LIST_DEPLOYMENT_ID_0_V6 permit 65535
set community {{ constants.bgp.allow_list.drop_community }} additive
{% endif %}
!
[bgpcfgd]: Support default action for "Allow prefix" feature (#6370) * Use 20 and 30 route-map entries instead of 2 and 3 for TSA * Added support for dynamic "Allow list" default action. Co-authored-by: Pavel Shirshov <pavel.contrib@gmail.com>
2021-01-08 16:03:26 -06:00
bgp community-list standard allow_list_default_community permit no-export
bgp community-list standard allow_list_default_community permit {{ constants.bgp.allow_list.drop_community }}
!
route-map FROM_BGP_PEER_V4 permit 10
[bgp] Add 'allow list' manager feature (#5513) implements a new feature: "BGP Allow list." This feature allows us to control which IP prefixes are going to be advertised via ebgp from the routes received from EBGP neighbors.
2020-10-02 12:06:04 -05:00
call ALLOW_LIST_DEPLOYMENT_ID_0_V4
on-match next
!
[bgpcfgd]: Support default action for "Allow prefix" feature (#6370) * Use 20 and 30 route-map entries instead of 2 and 3 for TSA * Added support for dynamic "Allow list" default action. Co-authored-by: Pavel Shirshov <pavel.contrib@gmail.com>
2021-01-08 16:03:26 -06:00
route-map FROM_BGP_PEER_V4 permit 11
match community allow_list_default_community
!
route-map FROM_BGP_PEER_V6 permit 10
[bgp] Add 'allow list' manager feature (#5513) implements a new feature: "BGP Allow list." This feature allows us to control which IP prefixes are going to be advertised via ebgp from the routes received from EBGP neighbors.
2020-10-02 12:06:04 -05:00
call ALLOW_LIST_DEPLOYMENT_ID_0_V6
on-match next
!
[bgpcfgd]: Support default action for "Allow prefix" feature (#6370) * Use 20 and 30 route-map entries instead of 2 and 3 for TSA * Added support for dynamic "Allow list" default action. Co-authored-by: Pavel Shirshov <pavel.contrib@gmail.com>
2021-01-08 16:03:26 -06:00
route-map FROM_BGP_PEER_V6 permit 11
match community allow_list_default_community
!
[bgp] Add 'allow list' manager feature (#5513) implements a new feature: "BGP Allow list." This feature allows us to control which IP prefixes are going to be advertised via ebgp from the routes received from EBGP neighbors.
2020-10-02 12:06:04 -05:00
{% endif %}
!
!
!
[bgpcfgd]: Split one bgp mega-template to chunks. (#4143) The one big bgp configuration template was splitted into chunks. Currently we have three types of bgp neighbor peers: general bgp peers. They are represented by CONFIG_DB::BGP_NEIGHBOR table entries dynamic bgp peers. They are represented by CONFIG_DB::BGP_PEER_RANGE table entries monitors bgp peers. They are represented by CONFIG_DB::BGP_MONITORS table entries This PR introduces three templates for each peer type: bgp policies: represent policieas that will be applied to the bgp peer-group (ip prefix-lists, route-maps, etc) bgp peer-group: represent bgp peer group which has common configuration for the bgp peer type and uses bgp routing policy from the previous item bgp peer-group instance: represent bgp configuration, which will be used to instatiate a bgp peer-group for the bgp peer-type. Usually this one is simple, consist of the referral to the bgp peer-group, bgp peer description and bgp peer ip address. This PR redefined constant.yml file. Now this file has a setting for to use or don't use bgp_neighbor metadata. This file has more parameters for now, which are not used. They will be used in the next iteration of bgpcfgd. Currently all tests have been disabled. I'm going to create next PR with the tests right after this PR is merged. I'm going to introduce better bgpcfgd in a short time. It will include support of dynamic changes for the templates. FIX:: #4231
2020-04-23 11:42:22 -05:00
route-map FROM_BGP_PEER_V4 permit 100
!
route-map TO_BGP_PEER_V4 permit 100
!
!
route-map FROM_BGP_PEER_V6 permit 1
[bgpcfgd]: Add on-match next rule for set ipv6 next-hop prefer-global (#6011) * Add 'on-match next' after every 'set ipv6 next-hop prefer-global' * Check that 'set ipv6 next-hop prefer-global' rule has 'on-match' next
2020-11-24 10:33:31 -06:00
on-match next
[bgpcfgd]: Split one bgp mega-template to chunks. (#4143) The one big bgp configuration template was splitted into chunks. Currently we have three types of bgp neighbor peers: general bgp peers. They are represented by CONFIG_DB::BGP_NEIGHBOR table entries dynamic bgp peers. They are represented by CONFIG_DB::BGP_PEER_RANGE table entries monitors bgp peers. They are represented by CONFIG_DB::BGP_MONITORS table entries This PR introduces three templates for each peer type: bgp policies: represent policieas that will be applied to the bgp peer-group (ip prefix-lists, route-maps, etc) bgp peer-group: represent bgp peer group which has common configuration for the bgp peer type and uses bgp routing policy from the previous item bgp peer-group instance: represent bgp configuration, which will be used to instatiate a bgp peer-group for the bgp peer-type. Usually this one is simple, consist of the referral to the bgp peer-group, bgp peer description and bgp peer ip address. This PR redefined constant.yml file. Now this file has a setting for to use or don't use bgp_neighbor metadata. This file has more parameters for now, which are not used. They will be used in the next iteration of bgpcfgd. Currently all tests have been disabled. I'm going to create next PR with the tests right after this PR is merged. I'm going to introduce better bgpcfgd in a short time. It will include support of dynamic changes for the templates. FIX:: #4231
2020-04-23 11:42:22 -05:00
set ipv6 next-hop prefer-global
!
route-map FROM_BGP_PEER_V6 permit 100
!
route-map TO_BGP_PEER_V6 permit 100
!
! end of template: bgpd/templates/general/policies.conf.j2
!
Reference in New Issue Copy Permalink