You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have been using FRR for over a year now, initially starting with version 9.0.1 and later upgrading to version 9.1, which worked perfectly for our use case of announcing /32 IPs for Anycast purposes. However, upon upgrading to FRR version 10.0.1, we started encountering the following error logs:
Jul 12 12:12:15 dvxxxxx02 mgmtd[20278]: [HCZYS-5H9EK] mgmt_txn_create_config_batches: ERROR: No connected daemon is interested in XPATH /frr-filter:lib/prefix-list[type='ipv4'][name='ANYCAST']
Jul 12 12:12:15 dvxxxxx02 mgmtd[20278]: [HCZYS-5H9EK] mgmt_txn_create_config_batches: ERROR: No connected daemon is interested in XPATH /frr-filter:lib/prefix-list[type='ipv4'][name='ANYCAST']/entry[sequence='5']
Jul 12 12:12:15 dvxxxxx02 mgmtd[20278]: [HCZYS-5H9EK] mgmt_txn_create_config_batches: ERROR: No connected daemon is interested in XPATH /frr-filter:lib/prefix-list[type='ipv4'][name='ANYCAST']/entry[sequence='5']/action
Jul 12 12:12:15 dvxxxxx02 mgmtd[20278]: [HCZYS-5H9EK] mgmt_txn_create_config_batches: ERROR: No connected daemon is interested in XPATH /frr-filter:lib/prefix-list[type='ipv4'][name='ANYCAST']/entry[sequence='5']/ipv4-prefix
Jul 12 12:12:15 dvxxxxx02 mgmtd[20278]: [HCZYS-5H9EK] mgmt_txn_create_config_batches: ERROR: No connected daemon is interested in XPATH /frr-filter:lib/prefix-list[type='ipv4'][name='DENY']
Jul 12 12:12:15 dvxxxxx02 mgmtd[20278]: [HCZYS-5H9EK] mgmt_txn_create_config_batches: ERROR: No connected daemon is interested in XPATH /frr-filter:lib/prefix-list[type='ipv4'][name='DENY']/entry[sequence='5']
Jul 12 12:12:15 dvxxxxx02 mgmtd[20278]: [HCZYS-5H9EK] mgmt_txn_create_config_batches: ERROR: No connected daemon is interested in XPATH /frr-filter:lib/prefix-list[type='ipv4'][name='DENY']/entry[sequence='5']/action
Jul 12 12:12:15 dvxxxxx02 mgmtd[20278]: [HCZYS-5H9EK] mgmt_txn_create_config_batches: ERROR: No connected daemon is interested in XPATH /frr-filter:lib/prefix-list[type='ipv4'][name='DENY']/entry[sequence='5']/any
Despite these errors, the functionality of announcing to neighbors remains unaffected. Could you please provide insight into why these logs appear in version 10.0.1 and not in version 9.1? We are keen to understand the root cause of these errors and whether they indicate any potential misconfiguration or deprecated features that we should be aware of.
Additionally, we have observed that the issue also manifests when route-maps are present in our configuration.
How it works:
The /32 IP addresses are managed by a Keepalived binary, which, through health checks, determines whether or not to assign the Anycast IP address to a particular node. This mechanism allows us to condition the BGP announcement of the Anycast IP based on the health check results from Keepalived. Essentially, only when Keepalived deems a node healthy and assigns it the Anycast IP, do we proceed to announce this IP to our BGP peers. This setup ensures that traffic is only directed to nodes that are currently capable of handling it.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi,
We have been using FRR for over a year now, initially starting with version 9.0.1 and later upgrading to version 9.1, which worked perfectly for our use case of announcing /32 IPs for Anycast purposes. However, upon upgrading to FRR version 10.0.1, we started encountering the following error logs:
Despite these errors, the functionality of announcing to neighbors remains unaffected. Could you please provide insight into why these logs appear in version 10.0.1 and not in version 9.1? We are keen to understand the root cause of these errors and whether they indicate any potential misconfiguration or deprecated features that we should be aware of.
Additionally, we have observed that the issue also manifests when route-maps are present in our configuration.
How it works:
The /32 IP addresses are managed by a Keepalived binary, which, through health checks, determines whether or not to assign the Anycast IP address to a particular node. This mechanism allows us to condition the BGP announcement of the Anycast IP based on the health check results from Keepalived. Essentially, only when Keepalived deems a node healthy and assigns it the Anycast IP, do we proceed to announce this IP to our BGP peers. This setup ensures that traffic is only directed to nodes that are currently capable of handling it.
versions:
Anthony
Beta Was this translation helpful? Give feedback.
All reactions