matthew/sonic-buildimage
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
f844992369
sonic-buildimage/dockers/docker-fpm-frr/frr/bgpd/templates/voq_chassis/peer-group.conf.j2

33 lines
1.3 KiB
Plaintext
Raw Normal View History

[chassis] Add templates and code to support VoQ chassis iBGP peers (#5622) This commit has following changes: * Add templates and code to support VoQ chassis iBGP peers * Add support to convert a new VoQChassisInternal element in the BGPSession element of the minigraph to a new BGP_VOQ_CHASSIS_NEIGHBOR table in CONFIG_DB. * Add a new set of "voq_chassis" templates to docker-fpm-frr * Add a new BGP peer manager to bgpcfgd to add neighbors from the BGP_VOQ_CHASSIS_NEIGHBOR table using the voq_chassis templates. * Add a test case for minigraph.py, making sure the VoQChassisInternal element creates a BGP_VOQ_CHASSIS_NEIGHBOR entry, but not if its value is "false". * Add a set of test cases for the new voq_chassis templates in sonic-bgpcfgd tests. Note that the templates expect the new "bgp bestpath peer-type multipath-relax" bgpd configuration to be available. Signed-off-by: Joanne Mikkelson <jmmikkel@arista.com>
2021-04-16 13:11:32 -05:00
!
! template: bgpd/templates/voq_chassis/peer-group.conf.j2
!
[chassis][bgp] create v4 and v6 peer group for VoQ internal neighbors (#9693) Why I did it In the recent minigraph changes we add separate BGP session configuration for V4 and V6 internal VoQ neighbors. This PR is adding different Peer groups for V4 and V6 neighbors How I did it Add VOQ_CHASSIS_V4_PEER and VOQ_CHASSIS_V6_PEER groups Add extra Unit tests How to verify it Signed-off-by: Arvindsrinivasan Lakshmi Narasimhan <arlakshm@microsoft.com>
2022-02-24 13:21:26 -06:00
neighbor VOQ_CHASSIS_V4_PEER peer-group
neighbor VOQ_CHASSIS_V6_PEER peer-group
[chassis] Add templates and code to support VoQ chassis iBGP peers (#5622) This commit has following changes: * Add templates and code to support VoQ chassis iBGP peers * Add support to convert a new VoQChassisInternal element in the BGPSession element of the minigraph to a new BGP_VOQ_CHASSIS_NEIGHBOR table in CONFIG_DB. * Add a new set of "voq_chassis" templates to docker-fpm-frr * Add a new BGP peer manager to bgpcfgd to add neighbors from the BGP_VOQ_CHASSIS_NEIGHBOR table using the voq_chassis templates. * Add a test case for minigraph.py, making sure the VoQChassisInternal element creates a BGP_VOQ_CHASSIS_NEIGHBOR entry, but not if its value is "false". * Add a set of test cases for the new voq_chassis templates in sonic-bgpcfgd tests. Note that the templates expect the new "bgp bestpath peer-type multipath-relax" bgpd configuration to be available. Signed-off-by: Joanne Mikkelson <jmmikkel@arista.com>
2021-04-16 13:11:32 -05:00
address-family ipv4
{% if CONFIG_DB__DEVICE_METADATA['localhost']['type'] == 'ToRRouter' %}
[chassis][bgp] create v4 and v6 peer group for VoQ internal neighbors (#9693) Why I did it In the recent minigraph changes we add separate BGP session configuration for V4 and V6 internal VoQ neighbors. This PR is adding different Peer groups for V4 and V6 neighbors How I did it Add VOQ_CHASSIS_V4_PEER and VOQ_CHASSIS_V6_PEER groups Add extra Unit tests How to verify it Signed-off-by: Arvindsrinivasan Lakshmi Narasimhan <arlakshm@microsoft.com>
2022-02-24 13:21:26 -06:00
neighbor VOQ_CHASSIS_V4_PEER allowas-in 1
[chassis] Add templates and code to support VoQ chassis iBGP peers (#5622) This commit has following changes: * Add templates and code to support VoQ chassis iBGP peers * Add support to convert a new VoQChassisInternal element in the BGPSession element of the minigraph to a new BGP_VOQ_CHASSIS_NEIGHBOR table in CONFIG_DB. * Add a new set of "voq_chassis" templates to docker-fpm-frr * Add a new BGP peer manager to bgpcfgd to add neighbors from the BGP_VOQ_CHASSIS_NEIGHBOR table using the voq_chassis templates. * Add a test case for minigraph.py, making sure the VoQChassisInternal element creates a BGP_VOQ_CHASSIS_NEIGHBOR entry, but not if its value is "false". * Add a set of test cases for the new voq_chassis templates in sonic-bgpcfgd tests. Note that the templates expect the new "bgp bestpath peer-type multipath-relax" bgpd configuration to be available. Signed-off-by: Joanne Mikkelson <jmmikkel@arista.com>
2021-04-16 13:11:32 -05:00
{% endif %}
[chassis][bgp] create v4 and v6 peer group for VoQ internal neighbors (#9693) Why I did it In the recent minigraph changes we add separate BGP session configuration for V4 and V6 internal VoQ neighbors. This PR is adding different Peer groups for V4 and V6 neighbors How I did it Add VOQ_CHASSIS_V4_PEER and VOQ_CHASSIS_V6_PEER groups Add extra Unit tests How to verify it Signed-off-by: Arvindsrinivasan Lakshmi Narasimhan <arlakshm@microsoft.com>
2022-02-24 13:21:26 -06:00
neighbor VOQ_CHASSIS_V4_PEER activate
neighbor VOQ_CHASSIS_V4_PEER addpath-tx-all-paths
neighbor VOQ_CHASSIS_V4_PEER soft-reconfiguration inbound
neighbor VOQ_CHASSIS_V4_PEER route-map FROM_VOQ_CHASSIS_V4_PEER in
neighbor VOQ_CHASSIS_V4_PEER route-map TO_VOQ_CHASSIS_V4_PEER out
[chassis/multi-asic] Enable Sending BGP Community over internal neighbors over iBGP Session (#16705) What I did: Enable Sending BGP Community over internal neighbors over iBGP Session Microsoft ADO: 25268695 Why I did: Without this change BGP community send by e-BGP Peers are not carry-forward to other e-BGP peers. str2-xxxx-lc1-2# show bgp ipv6 20c0:a801::/64 BGP routing table entry for 20c0:a801::/64, version 52141 Paths: (1 available, best #1, table default) Not advertised to any peer 65000 65500 2603:10e2:400::6 from 2603:10e2:400::6 (3.3.3.6) Origin IGP, localpref 100, valid, internal, best (First path received) Last update: Tue Sep 26 16:08:26 2023 str2-xxxx-lc1-2# show ip bgp 192.168.35.128/25 BGP routing table entry for 192.168.35.128/25, version 52688 Paths: (1 available, best #1, table default) Not advertised to any peer 65000 65502 3.3.3.6 from 3.3.3.6 (3.3.3.6) Origin IGP, localpref 100, valid, internal, best (First path received) Last update: Tue Sep 26 15:45:51 2023 After the change str2-xxxx-lc2-2(config)# router bgp 65100 str2-xxxx-lc2-2(config-router)# address-family ipv4 str2-xxxx-lc2-2(config-router-af)# neighbor INTERNAL_PEER_V4 send-community str2-xxxx-lc2-2(config-router-af)# exit str2-xxxx-lc2-2(config-router)# address-family ipv6 str2-xxxx-lc2-2(config-router-af)# neighbor INTERNAL_PEER_V6 send-community str2-xxxx-lc1-2# show bgp ipv6 20c0:a801::/64 BGP routing table entry for 20c0:a801::/64, version 52400 Paths: (1 available, best #1, table default) Not advertised to any peer 65000 65500 2603:10e2:400::6 from 2603:10e2:400::6 (3.3.3.6) Origin IGP, localpref 100, valid, internal, best (First path received) **Community: 1111:1111** Last update: Tue Sep 26 16:10:19 2023 str2-xxxx-lc1-2# show ip bgp 192.168.35.128/25 BGP routing table entry for 192.168.35.128/25, version 52947 Paths: (1 available, best #1, table default) Not advertised to any peer 65000 65502 3.3.3.6 from 3.3.3.6 (3.3.3.6) Origin IGP, localpref 100, valid, internal, best (First path received) **Community: 1111:1111** Last update: Tue Sep 26 16:10:09 2023 Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
2023-09-26 15:34:38 -05:00
neighbor VOQ_CHASSIS_V4_PEER send-community
[chassis/multi-asic] Make sure iBGP session established as directly connected (#16777) What I did: Make Sure for internal iBGP we are one-hop away (directly connected) by using Generic TTL security mechanism. Why I did: Without this change it's possible on packet chassis i-BGP can be established even if there no direct connection. Below is the example - Let's say we have 3 LC's LC1/LC2/LC3 each having i-BGP session session with each other over Loopback4096 - Each LC's have static route towards other LC's Loopback4096 to establish i-BGP session - LC1 learn default route 0.0.0.0/0 from it's e-BGP peers and send it over to LC2 and LC3 over i-BGP - Now for some reason on LC2 static route towards LC3 is removed/not-present/some-issue we expect i-BGP session should go down between LC2 and LC3 - However i-BGP between LC2 and LC3 does not go down because of feature ip nht-resolve-via-default where LC2 will use default route to reach Loopback4096 of LC3. As it's using default route BGP packets from LC2 towards LC3 will first route to LC1 and then go to LC3 from there. Above scenario can result in packet mis-forwarding on data plane How I fixed it:- To make sure BGP packets between i-BGP peers are not going with extra routing hop enable using GTSM feature neighbor PEER ttl-security hops NUMBER This command enforces Generalized TTL Security Mechanism (GTSM), as specified in RFC 5082. With this command, only neighbors that are the specified number of hops away will be allowed to become neighbors. This command is mutually exclusive with ebgp-multihop. We set hop count as 1 which makes FRR to reject BGP connection if we receive BGP packets if it's TTL < 255. Also setting this attribute make sure i-BGP frames are originated with IP TTL of 255. How I verify: Manual Verification of above scenario. See blow BGP packets receive with IP TTL 254 (additional routing hop) we are seeing FIN TCP flags as BGP is rejecting the connection Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
2023-10-10 13:51:40 -05:00
neighbor VOQ_CHASSIS_V4_PEER ttl-security hops 1
[chassis] Add templates and code to support VoQ chassis iBGP peers (#5622) This commit has following changes: * Add templates and code to support VoQ chassis iBGP peers * Add support to convert a new VoQChassisInternal element in the BGPSession element of the minigraph to a new BGP_VOQ_CHASSIS_NEIGHBOR table in CONFIG_DB. * Add a new set of "voq_chassis" templates to docker-fpm-frr * Add a new BGP peer manager to bgpcfgd to add neighbors from the BGP_VOQ_CHASSIS_NEIGHBOR table using the voq_chassis templates. * Add a test case for minigraph.py, making sure the VoQChassisInternal element creates a BGP_VOQ_CHASSIS_NEIGHBOR entry, but not if its value is "false". * Add a set of test cases for the new voq_chassis templates in sonic-bgpcfgd tests. Note that the templates expect the new "bgp bestpath peer-type multipath-relax" bgpd configuration to be available. Signed-off-by: Joanne Mikkelson <jmmikkel@arista.com>
2021-04-16 13:11:32 -05:00
exit-address-family
address-family ipv6
{% if CONFIG_DB__DEVICE_METADATA['localhost']['type'] == 'ToRRouter' %}
[chassis][bgp] create v4 and v6 peer group for VoQ internal neighbors (#9693) Why I did it In the recent minigraph changes we add separate BGP session configuration for V4 and V6 internal VoQ neighbors. This PR is adding different Peer groups for V4 and V6 neighbors How I did it Add VOQ_CHASSIS_V4_PEER and VOQ_CHASSIS_V6_PEER groups Add extra Unit tests How to verify it Signed-off-by: Arvindsrinivasan Lakshmi Narasimhan <arlakshm@microsoft.com>
2022-02-24 13:21:26 -06:00
neighbor VOQ_CHASSIS_V6_PEER allowas-in 1
[chassis] Add templates and code to support VoQ chassis iBGP peers (#5622) This commit has following changes: * Add templates and code to support VoQ chassis iBGP peers * Add support to convert a new VoQChassisInternal element in the BGPSession element of the minigraph to a new BGP_VOQ_CHASSIS_NEIGHBOR table in CONFIG_DB. * Add a new set of "voq_chassis" templates to docker-fpm-frr * Add a new BGP peer manager to bgpcfgd to add neighbors from the BGP_VOQ_CHASSIS_NEIGHBOR table using the voq_chassis templates. * Add a test case for minigraph.py, making sure the VoQChassisInternal element creates a BGP_VOQ_CHASSIS_NEIGHBOR entry, but not if its value is "false". * Add a set of test cases for the new voq_chassis templates in sonic-bgpcfgd tests. Note that the templates expect the new "bgp bestpath peer-type multipath-relax" bgpd configuration to be available. Signed-off-by: Joanne Mikkelson <jmmikkel@arista.com>
2021-04-16 13:11:32 -05:00
{% endif %}
[chassis][bgp] create v4 and v6 peer group for VoQ internal neighbors (#9693) Why I did it In the recent minigraph changes we add separate BGP session configuration for V4 and V6 internal VoQ neighbors. This PR is adding different Peer groups for V4 and V6 neighbors How I did it Add VOQ_CHASSIS_V4_PEER and VOQ_CHASSIS_V6_PEER groups Add extra Unit tests How to verify it Signed-off-by: Arvindsrinivasan Lakshmi Narasimhan <arlakshm@microsoft.com>
2022-02-24 13:21:26 -06:00
neighbor VOQ_CHASSIS_V6_PEER activate
neighbor VOQ_CHASSIS_V6_PEER addpath-tx-all-paths
neighbor VOQ_CHASSIS_V6_PEER soft-reconfiguration inbound
Fix VOQ_CHASSIS_V6_PEER route-map config (#14055) * Fix typo in VOQ_CHASSIS_V6_PEER route-map config * Updated UT files with the changed config
2023-03-03 11:28:57 -06:00
neighbor VOQ_CHASSIS_V6_PEER route-map FROM_VOQ_CHASSIS_V6_PEER in
neighbor VOQ_CHASSIS_V6_PEER route-map TO_VOQ_CHASSIS_V6_PEER out
[chassis/multi-asic] Enable Sending BGP Community over internal neighbors over iBGP Session (#16705) What I did: Enable Sending BGP Community over internal neighbors over iBGP Session Microsoft ADO: 25268695 Why I did: Without this change BGP community send by e-BGP Peers are not carry-forward to other e-BGP peers. str2-xxxx-lc1-2# show bgp ipv6 20c0:a801::/64 BGP routing table entry for 20c0:a801::/64, version 52141 Paths: (1 available, best #1, table default) Not advertised to any peer 65000 65500 2603:10e2:400::6 from 2603:10e2:400::6 (3.3.3.6) Origin IGP, localpref 100, valid, internal, best (First path received) Last update: Tue Sep 26 16:08:26 2023 str2-xxxx-lc1-2# show ip bgp 192.168.35.128/25 BGP routing table entry for 192.168.35.128/25, version 52688 Paths: (1 available, best #1, table default) Not advertised to any peer 65000 65502 3.3.3.6 from 3.3.3.6 (3.3.3.6) Origin IGP, localpref 100, valid, internal, best (First path received) Last update: Tue Sep 26 15:45:51 2023 After the change str2-xxxx-lc2-2(config)# router bgp 65100 str2-xxxx-lc2-2(config-router)# address-family ipv4 str2-xxxx-lc2-2(config-router-af)# neighbor INTERNAL_PEER_V4 send-community str2-xxxx-lc2-2(config-router-af)# exit str2-xxxx-lc2-2(config-router)# address-family ipv6 str2-xxxx-lc2-2(config-router-af)# neighbor INTERNAL_PEER_V6 send-community str2-xxxx-lc1-2# show bgp ipv6 20c0:a801::/64 BGP routing table entry for 20c0:a801::/64, version 52400 Paths: (1 available, best #1, table default) Not advertised to any peer 65000 65500 2603:10e2:400::6 from 2603:10e2:400::6 (3.3.3.6) Origin IGP, localpref 100, valid, internal, best (First path received) **Community: 1111:1111** Last update: Tue Sep 26 16:10:19 2023 str2-xxxx-lc1-2# show ip bgp 192.168.35.128/25 BGP routing table entry for 192.168.35.128/25, version 52947 Paths: (1 available, best #1, table default) Not advertised to any peer 65000 65502 3.3.3.6 from 3.3.3.6 (3.3.3.6) Origin IGP, localpref 100, valid, internal, best (First path received) **Community: 1111:1111** Last update: Tue Sep 26 16:10:09 2023 Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
2023-09-26 15:34:38 -05:00
neighbor VOQ_CHASSIS_V6_PEER send-community
[chassis/multi-asic] Make sure iBGP session established as directly connected (#16777) What I did: Make Sure for internal iBGP we are one-hop away (directly connected) by using Generic TTL security mechanism. Why I did: Without this change it's possible on packet chassis i-BGP can be established even if there no direct connection. Below is the example - Let's say we have 3 LC's LC1/LC2/LC3 each having i-BGP session session with each other over Loopback4096 - Each LC's have static route towards other LC's Loopback4096 to establish i-BGP session - LC1 learn default route 0.0.0.0/0 from it's e-BGP peers and send it over to LC2 and LC3 over i-BGP - Now for some reason on LC2 static route towards LC3 is removed/not-present/some-issue we expect i-BGP session should go down between LC2 and LC3 - However i-BGP between LC2 and LC3 does not go down because of feature ip nht-resolve-via-default where LC2 will use default route to reach Loopback4096 of LC3. As it's using default route BGP packets from LC2 towards LC3 will first route to LC1 and then go to LC3 from there. Above scenario can result in packet mis-forwarding on data plane How I fixed it:- To make sure BGP packets between i-BGP peers are not going with extra routing hop enable using GTSM feature neighbor PEER ttl-security hops NUMBER This command enforces Generalized TTL Security Mechanism (GTSM), as specified in RFC 5082. With this command, only neighbors that are the specified number of hops away will be allowed to become neighbors. This command is mutually exclusive with ebgp-multihop. We set hop count as 1 which makes FRR to reject BGP connection if we receive BGP packets if it's TTL < 255. Also setting this attribute make sure i-BGP frames are originated with IP TTL of 255. How I verify: Manual Verification of above scenario. See blow BGP packets receive with IP TTL 254 (additional routing hop) we are seeing FIN TCP flags as BGP is rejecting the connection Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
2023-10-10 13:51:40 -05:00
neighbor VOQ_CHASSIS_V6_PEER ttl-security hops 1
[chassis] Add templates and code to support VoQ chassis iBGP peers (#5622) This commit has following changes: * Add templates and code to support VoQ chassis iBGP peers * Add support to convert a new VoQChassisInternal element in the BGPSession element of the minigraph to a new BGP_VOQ_CHASSIS_NEIGHBOR table in CONFIG_DB. * Add a new set of "voq_chassis" templates to docker-fpm-frr * Add a new BGP peer manager to bgpcfgd to add neighbors from the BGP_VOQ_CHASSIS_NEIGHBOR table using the voq_chassis templates. * Add a test case for minigraph.py, making sure the VoQChassisInternal element creates a BGP_VOQ_CHASSIS_NEIGHBOR entry, but not if its value is "false". * Add a set of test cases for the new voq_chassis templates in sonic-bgpcfgd tests. Note that the templates expect the new "bgp bestpath peer-type multipath-relax" bgpd configuration to be available. Signed-off-by: Joanne Mikkelson <jmmikkel@arista.com>
2021-04-16 13:11:32 -05:00
exit-address-family
!
! end of template: bgpd/templates/voq_chassis/peer-group.conf.j2
!
Reference in New Issue Copy Permalink