Question:
BGP path selection process difference in 16.1R1 and 16.1R2
Solution
Refer to this table to understand the BGP configuration between Versa Director 16.1R1 and 16.1R2:
16.1R1 | 16.1R2 |
Step 1: If both routes are learnt through BGP, they are compared as below:
| Step 1: Lower value of protocol preference is preferred (Default value of protocol preference is 0 for connected routes, 1 for static routes, 30 for OSPF internal routes, 110 for OSPF external routes, 20 for EBGP routes and 200 for IBGP routes) |
Step 2: Else lower value of protocol preference is preferred (Default value of protocol preference is 0 for connected routes, 1 for static routes, 30 for OSPF internal routes, 110 for OSPF external routes, 20 for EBGP routes and 200 for IBGP routes) | Step 2: Else if both routes are learnt through BGP, they are compared as below:
|
Step 3: Else, the following types of routes are preferred in decreasing order:
| Step 3: Else the following types of routes are preferred in decreasing order:
|
Example
When compared with the policy config change in 16.1R1, you must change the BGP policy config (in 16.1R2) as presented below when local-preference is set through a policy to prefer L3VPN routes that are learnt over IBGP over DIA routes learnt from internet transport VR.
Run the set routing-instances <name of the routing instance> protocols bgp <instance ID> routing-peer-policy Import-From-SDWAN-Policy term Allow-All action set-preference <value> CLI command to selectively change the preference value of some routes received through eBGP to worse (for example change it to 201) in the routing-peer-policy term. The default preference value is set to 200 for iBGP route.
This make the Versa FlexVNF to prefer L3VPN routes learnt over IBGP over routes learnt through EBGP.
In 16.1R1, you can remove the configuration which was either setting better (higher) value of local-preference for iBGP routes or set worse (lower) value of local-preference for eBGP routes.
In 16.1R2, The aove behaviour was changed and now the protocol preference is used as first tie-breaker and hence local preference config is not needed any more for this purpose.