> Source: [sk1000009](https://support.checkpoint.com/results/sk/sk1000009)

# sk1000009 - "Unable to ipsrd_transact get VIRTUALSYSTEM:default:vrrp:NVrid" error when editing BGP configuration on Locally Managed Spark Firewall 

| Property | Value |
|----------|-------|
| Solution ID | sk1000009 |
| Date Created | 2026-08-20 |
| Last Modified | 2026-08-25 |
| Technical Level | General |
| Products | Spark Firewall (Locally Managed) |
| Versions | R82.00.X |
| OS | Gaia Embedded |

## Symptoms

- <br />

* "*Unable to ipsrd_transact get VIRTUALSYSTEM:default:vrrp:NVrid* " error when editing BGP configuration on a Locally Managed Spark Firewall via WebUI or Clish.
* The routed daemon restarts approximately every 5 seconds.
* The WAN status remains at "Connecting..."
* The */var/log/routed_messages* file contains this message: "BGP remote peer address can't be an address on the local machine".

<br />

## Cause

The configured BGP peer address is the same as the gateway's local IP address. The routed daemon rejects the configuration because the peer address is a local address. The daemon exits, and the watchdog process restarts it approximately every five seconds. This can cause symptoms such as:

* "WAN stuck on "Connecting...""
* Spark Management registration can fail because the routed daemon is not running.
* "*Unable to ipsrd_transact get VIRTUALSYSTEM:default:vrrp:NVrid*" error output on every WebUI/Clish CLI BGP edit. The configuration process communicates with the routed daemon through a local socket. When the routed daemon is not running, configuration changes fail.

## Solution

1. **Try a normal Clish/CLI fix first. Remove the misconfigured BGP peer, then add the correct one:**

   * *set bgp external remote-as
     \<xxxxx\> peer \<wrong_IP_address\> off*

   * *set bgp external remote-as
     \<xxxxx\> peer \<wrong_IP_address\> on*

2. Because the routed daemon may run briefly between restarts, these commands can succeed after one or more retries. If necessary, retry 2-3 times before moving to Step 2.
3. **Fix the generated BGP configuration directly from Expert mode so that the routed daemon can start:**

   1. Locate the *routed0.conf* file that the routed daemon is using. This appears in the parse-error line in */var/log/routed_messages*, or use "find / -name routed0.conf 2\> /dev/null".

   2. Back up the routed0.conf file: *cp routed0.conf routed0.conf.bak*

   3. Edit the invalid peer configuration in *routed0.conf* or delete the affected peer stanza.

   4. No restart command is required. The watchdog process automatically restarts the routed daemon within approximately 5 seconds and reloads the updated configuration file.

4. The *routed0.conf* file is generated automatically from the configuration database. Changes made directly to this file are temporary. After the routed daemon starts successfully, repeat Step 1 in Clish to correct the configuration database. Otherwise, future configuration changes can regenerate the misconfigured BGP configuration.
5. **Verify:**

   * The*cpwd_admin list* command shows that the routed daemon PID remains unchanged and that no additional restarts occur.

   * The*tail /var/log/routed_messages* command shows a successful startup with no new error messages.

   * The WAN status no longer shows "**Connecting...**" (if applicable).

   * In the WebUI, the **Advanced Routing** \> **BGP** page opens successfully, displays the configured peers, and can be edited without generating the error message.

---

# Agent Instructions

This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products.

## Navigating This Knowledge Base

- **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt)
- **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml)
- **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}`
- **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content