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

36 lines
1.2 KiB
Plaintext
Raw Normal View History

[multi-ASIC] BGP internal neighbor table support (#5520) * Initial commit for BGP internal neighbor table support. > Add new template named "internal" for the internal BGP sessions > Add a new table in database "BGP_INTERNAL_NEIGHBOR" > The internal BGP sessions will be stored in this new table "BGP_INTERNAL_NEIGHBOR" * Changes in template generation tests with the introduction of internal neighbor template files.
2020-10-28 18:41:27 -05:00
!
! template: bgpd/templates/internal/instance.conf.j2
!
neighbor {{ neighbor_addr }} remote-as {{ bgp_session['asn'] }}
neighbor {{ neighbor_addr }} description {{ bgp_session['name'] }}
[multi-ASIC] util changes with the BGP_INTERNAL_NEIGHBOR table (#5874) Reintroduce #5760, along with the fix needed in the template file for python3 compatibility.
2020-11-10 11:34:56 -06:00
neighbor {{ neighbor_addr }} timers 3 10
To decrease the Connect Retry Timer from default value which is 120sec to 10 sec. (#7087) Why I did it It was observed that on a multi-asic DUT bootup, the BGP internal sessions between ASIC's was taking more time to get ESTABLISHED than external BGP sessions. The internal sessions was coming up almost exactly 120 secs later. In multi-asic platform the bgp dockers ( which is per ASIC ) on switch start are bring brought up around the same time and they try to make the bgp sessions with neighbors (in peer ASIC's) which may be not be completely up. This results in BGP connect fail and the retry happens after 120sec which is the default Connect Retry Timer How I did it Add the command to set the bgp neighboring session retry timer to 10sec for internal bgp neighbors.
2021-03-18 01:14:38 -05:00
neighbor {{ neighbor_addr }} timers connect 10
[multi-ASIC] BGP internal neighbor table support (#5520) * Initial commit for BGP internal neighbor table support. > Add new template named "internal" for the internal BGP sessions > Add a new table in database "BGP_INTERNAL_NEIGHBOR" > The internal BGP sessions will be stored in this new table "BGP_INTERNAL_NEIGHBOR" * Changes in template generation tests with the introduction of internal neighbor template files.
2020-10-28 18:41:27 -05:00
!
{% if neighbor_addr | ipv4 %}
address-family ipv4
neighbor {{ neighbor_addr }} peer-group INTERNAL_PEER_V4
!
updated internal route policy for chassis-packet (#15349) What I did: Workaround for the issue seen here : FRRouting/frr#13682 It seems there is timing issue where there are multiple recursive lookup needed to resolve nexthop of the route it's possible that it does not happen correctly causing route to remain in inactive state Issue is seen on chassis-packet as there 2 level of recursive lookup needed for a given e-BGP learnt route - Level1 to resolve e-BGP peer (connected route via bgp ) over Loopback4096 (i-BGP peering) - Level 2 Loopback4096 over backend port-channels next-hops For VOQ chassis there is no e-BGP peer (connected route via bgp ) resolution as route is added as Static route by orchagent over Ethernet-IB. Also as part of this remove route-map policy from instance.conf.j2 as same is define in peer-group.j2. Microsoft ADO: https://msazure.visualstudio.com/One/_workitems/edit/24198507 How I verify: Functional Verification manually Updated UT. We will be adding sanity check in sonic-mgmt to make sure none of route are in inactive state. Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
2023-06-07 11:17:44 -05:00
{% if CONFIG_DB__DEVICE_METADATA['localhost']['sub_role'] == 'BackEnd' or CONFIG_DB__DEVICE_METADATA['localhost']['switch_type'] == 'chassis-packet' %}
Changes in FRR temapltes for multi-asic (#6901) 1. Made the command next-hop-self force only applicable on back-end asic bgp. This is done so that BGPL iBGP session running on backend can send e-BGP learn nexthop. Back end asic FRR is able to recursively resolve the eBGP nexthop in its routing table since it knows about all the connected routes advertise from front end asic. 2. Made all front-end asic bgp use global loopback ip (Loopback0) as router id and back end asic bgp use Loopbacl4096 as ruter-id and originator id for Route-Reflector. This is done so that routes learnt by external peer do not see Loopback4096 as router id in show ip bgp <route-prerfix> output. 3. To handle above change need to pass Loopback4096 from BGP manager for jinja2 template generation. This was missing and this change/fix is needed for this also https://github.com/Azure/sonic-buildimage/blob/master/dockers/docker-fpm-frr/frr/bgpd/templates/dynamic/instance.conf.j2#L27 4. Enhancement to add mult_asic specific bgpd template generation unit test cases.
2021-02-26 19:05:15 -06:00
neighbor {{ neighbor_addr }} next-hop-self force
[multi-ASIC] BGP internal neighbor table support (#5520) * Initial commit for BGP internal neighbor table support. > Add new template named "internal" for the internal BGP sessions > Add a new table in database "BGP_INTERNAL_NEIGHBOR" > The internal BGP sessions will be stored in this new table "BGP_INTERNAL_NEIGHBOR" * Changes in template generation tests with the introduction of internal neighbor template files.
2020-10-28 18:41:27 -05:00
{% endif %}
!
{% elif neighbor_addr | ipv6 %}
address-family ipv6
neighbor {{ neighbor_addr }} peer-group INTERNAL_PEER_V6
!
updated internal route policy for chassis-packet (#15349) What I did: Workaround for the issue seen here : FRRouting/frr#13682 It seems there is timing issue where there are multiple recursive lookup needed to resolve nexthop of the route it's possible that it does not happen correctly causing route to remain in inactive state Issue is seen on chassis-packet as there 2 level of recursive lookup needed for a given e-BGP learnt route - Level1 to resolve e-BGP peer (connected route via bgp ) over Loopback4096 (i-BGP peering) - Level 2 Loopback4096 over backend port-channels next-hops For VOQ chassis there is no e-BGP peer (connected route via bgp ) resolution as route is added as Static route by orchagent over Ethernet-IB. Also as part of this remove route-map policy from instance.conf.j2 as same is define in peer-group.j2. Microsoft ADO: https://msazure.visualstudio.com/One/_workitems/edit/24198507 How I verify: Functional Verification manually Updated UT. We will be adding sanity check in sonic-mgmt to make sure none of route are in inactive state. Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
2023-06-07 11:17:44 -05:00
{% if CONFIG_DB__DEVICE_METADATA['localhost']['sub_role'] == 'BackEnd' or CONFIG_DB__DEVICE_METADATA['localhost']['switch_type'] == 'chassis-packet' %}
Changes in FRR temapltes for multi-asic (#6901) 1. Made the command next-hop-self force only applicable on back-end asic bgp. This is done so that BGPL iBGP session running on backend can send e-BGP learn nexthop. Back end asic FRR is able to recursively resolve the eBGP nexthop in its routing table since it knows about all the connected routes advertise from front end asic. 2. Made all front-end asic bgp use global loopback ip (Loopback0) as router id and back end asic bgp use Loopbacl4096 as ruter-id and originator id for Route-Reflector. This is done so that routes learnt by external peer do not see Loopback4096 as router id in show ip bgp <route-prerfix> output. 3. To handle above change need to pass Loopback4096 from BGP manager for jinja2 template generation. This was missing and this change/fix is needed for this also https://github.com/Azure/sonic-buildimage/blob/master/dockers/docker-fpm-frr/frr/bgpd/templates/dynamic/instance.conf.j2#L27 4. Enhancement to add mult_asic specific bgpd template generation unit test cases.
2021-02-26 19:05:15 -06:00
neighbor {{ neighbor_addr }} next-hop-self force
[multi-ASIC] BGP internal neighbor table support (#5520) * Initial commit for BGP internal neighbor table support. > Add new template named "internal" for the internal BGP sessions > Add a new table in database "BGP_INTERNAL_NEIGHBOR" > The internal BGP sessions will be stored in this new table "BGP_INTERNAL_NEIGHBOR" * Changes in template generation tests with the introduction of internal neighbor template files.
2020-10-28 18:41:27 -05:00
{% endif %}
{% endif %}
!
[multi-ASIC] util changes with the BGP_INTERNAL_NEIGHBOR table (#5874) Reintroduce #5760, along with the fix needed in the template file for python3 compatibility.
2020-11-10 11:34:56 -06:00
{% if 'rrclient' in bgp_session and bgp_session['rrclient'] | int != 0 %}
[multi-ASIC] BGP internal neighbor table support (#5520) * Initial commit for BGP internal neighbor table support. > Add new template named "internal" for the internal BGP sessions > Add a new table in database "BGP_INTERNAL_NEIGHBOR" > The internal BGP sessions will be stored in this new table "BGP_INTERNAL_NEIGHBOR" * Changes in template generation tests with the introduction of internal neighbor template files.
2020-10-28 18:41:27 -05:00
neighbor {{ neighbor_addr }} route-reflector-client
{% endif %}
!
!
neighbor {{ neighbor_addr }} activate
exit-address-family
!
! end of template: bgpd/templates/internal/instance.conf.j2
!
Reference in New Issue Copy Permalink