frr-mgmt-framework syntax for PREFIX_SET is impossible to use in a route-map #6943
Comments
|
@venkatmahalingam - could you please look into the issue, thanks. |
|
@jhujhiti HLD is pending to merge because of the BGP/route-map schema dependent YANG models are in review, will fix the table names. We should use IPv4 & IPv6 values, will create the PR with the fixes, meanwhile, please use the following fixes. Please change ipv4 -> IPv4 and ipv6 -> IPv6 sonic-buildimage/src/sonic-frr-mgmt-framework/templates/bgpd/bgpd.conf.db.route_map.j2 Also, use mode as "IPv4" instead of "ipv4" 127.0.0.1:6379[4]> hgetall PREFIX_SET|slash32
|
|
Since the HLD is still in a PR, the roadmap link ought to at least be updated. https://github.com/Azure/SONiC/wiki/Sonic-Roadmap-Planning links to an outdated document which, among other things, doesn't mention the need to enable the entire feature with the |
|
HLD is expected to be merged before the next release, will update the HLD soon. |
|
The HLD has merged already, @jhujhiti hope you got a chance to verify this issue with the suggested change, please confirm. |
|
Oh -- yes the template change works. I'd already applied that when I opened the issue. I see that the HLD is on master, but https://github.com/Azure/SONiC/wiki/Sonic-Roadmap-Planning still links to an outdated version of the HLD. |
Sure, we will fix to point to https://github.com/Azure/SONiC/blob/master/doc/mgmt/SONiC_Design_Doc_Unified_FRR_Mgmt_Interface.md instead of a specific commit. |
|
+1. I hit this issue with 202012 today. I was trying to understand how the templates were created to allow me to reverse engineer how to write the Do you have an estimate when this can be fixed and backported to 202012? I created #8454 to try to help along. |
This change makes the template match PREFIX_SET and the documentation. Fixes sonic-net#6943. Signed-off-by: Christian Svensson <[email protected]>
Fix #6943 This change makes the template match PREFIX_SET and the documentation. Signed-off-by: Christian Svensson <[email protected]>
|
I have verified the fix with the following configuration snippet: {
"ROUTE_MAP": {
"ALLOW-OUT|1": {
"route_operation": "permit",
"match_prefix_set": "LOCAL-NETS"
}
},
"PREFIX_SET": {
"LOCAL-NETS": {
"mode": "IPv6"
}
},
"PREFIX": {
"LOCAL-NETS|2a10:11c0::/64|exact": {}
}
}It does not seem to work with online configuration through frrcfgd but running The only part that did show up during "online" apply was this: |
|
It does not seem to work with online configuration through frrcfgd
|
|
Yep! I used |
Fix #6943 This change makes the template match PREFIX_SET and the documentation. Signed-off-by: Christian Svensson <[email protected]>
Description
The templates that write FRR configuration for route-maps and prefix-lists assume opposite and incompatible things about the
modefield of eachPREFIX_SET.bgpd.conf.db.pref_list.j2requires uppercase (eg.,IPv4) to match: https://github.com/Azure/sonic-buildimage/blob/a171e6c5e4e51a360a70190903e09decb44ec7e3/src/sonic-frr-mgmt-framework/templates/bgpd/bgpd.conf.db.pref_list.j2#L5bgpd.conf.db.route_map.j2requires lowercase (eg.,ipv4) to match: https://github.com/Azure/sonic-buildimage/blob/a171e6c5e4e51a360a70190903e09decb44ec7e3/src/sonic-frr-mgmt-framework/templates/bgpd/bgpd.conf.db.route_map.j2#L28This makes it impossible to define a prefix-list and use it in a route-map.
The latest documentation in sonic-net/SONiC#544 (not sure why this isn't merged) is also wrong. The document says that the database keys are
IP_PREFIX_SETandIP_PREFIX, but the templates actually matchPREFIX_SETandPREFIX.Steps to reproduce the issue:
Snippet of
/etc/sonic/config_db.jsonnecessary to reproduce:{ "DEVICE_METADATA": { "localhost": { "frr_mgmt_framework_config": "true" } }, "ROUTE_MAP": { "LOOPBACK|10": { "route_operation": "permit", "match_prefix_set": "slash32", "set_origin": "igp" } }, "PREFIX_SET": { "slash32": { "mode": "ipv4" } }, "PREFIX": { "slash32|0.0.0.0/0|32..32": { "action": "permit" } } }Describe the results you received:
The snippet above produces the FRR configuration
with no prefix-list defined. Changing the
modetoIPV4instead results inwith no match conditions at all.
Describe the results you expected:
Other parts of the template are case-insensitive, so I'd expect either upper- or lower- case modes to result in
Output of
show version:Built from master a few days ago: c617825. Confirmed that the bug still exists on master now.
The text was updated successfully, but these errors were encountered: