Common issues
Symptoms and checks for a BGP session with the BGPCast route server and for the connector agent. Each entry is one problem and what to verify on your side.
Updated
Session not coming up (Active/Connect)
Active or Connect means the TCP connection to the route server is never established — BGP never gets a chance to negotiate. Check that <bgpcast-ip> is reachable from the router and that outbound TCP/179 is not filtered by your firewall or your ISP. If the router sits behind NAT or CGNAT with no public address of its own, a direct session cannot work at all — use the connector agent instead.
nc -vz <bgpcast-ip> 179
No established state, but the port is open
TCP is up and BGP is not, which means the OPEN message is being rejected. A mismatched ASN is the usual cause. Check your ASN and the BGPCast ASN against the values shown in your account: on a mismatch the session cycles Idle → Connect → Active and never reaches Established. The second most common cause is the wrong neighbour address on your side.
/routing/bgp/session/print
vtysh -c 'show bgp summary'
birdc show protocols all bgpcast
Established, but 0 prefixes
The session is up and no routes arrive. Make sure you are subscribed to at least one category and that the peer is enabled in your account: per-peer isolation means a peer only receives the categories it is subscribed to. Check your inbound filter as well — it can drop the prefixes before they reach the table.
/routing/bgp/session/print
vtysh -c 'show bgp ipv4 unicast neighbors <bgpcast-ip> received-routes'
birdc show route protocol bgpcast
Session is flapping
The session comes up and drops repeatedly. Two typical causes. First: a cloud peer is not on a shared link with you, so multihop is required — without it TTL is 1 and the session stalls or breaks. Second: the peer is configured as iBGP on your side while the ASNs differ — the role must be eBGP.
/routing/bgp/connection/set [find name=bgpcast] multihop=yes
neighbor <bgpcast-ip> ebgp-multihop 255
multihop 255;
Agent: session not coming up
The agent accepts no inbound connections — it dials out over HTTPS/WSS, so no port forwarding is needed. Check the token on the LAN settings page and that outbound 443 to bgpcast.cc is not blocked. If the token is right and there is still no session, read the agent service log: it shows whether authentication was reached.
logread -e bgpcast-agent
Agent: BGP won't start / port 179 already in use
On Entware and OpenWrt the agent listens on TCP/179 itself, and BIRD 2 claims the same port by default — only one of them starts. Move BIRD to another port with the local port directive in bird.conf and leave 179 to the agent. Restart BIRD afterwards and confirm both processes are alive.
local port 1791 as <your-asn>;
Agent: settings page unreachable
The agent settings page is served on the local network only and is deliberately not exposed to the internet. Open it from a device on the same network, and address it by the router's IP rather than an external hostname: saving settings is protected against DNS rebinding and will reject a request carrying a foreign Host header.
http://<router-lan-ip>:8080
MikroTik: container won't start
The container needs a mounted disk (disk1) and the veth-bgpcast interface; without them it will not come up. Check DNS on the veth interface separately: with no resolver the container cannot reach bgpcast.cc, and the log shows this as an ordinary timeout. Also set BGPCAST_AGENT_BGP_LISTEN to a high port, or the agent collides with RouterOS's own BGP.
/container/print detail
Unsubscribed from a category, but the routes are still on the router
Refresh the view first: WinBox does not redraw the route list on its own, and \"stuck\" prefixes are usually a stale picture rather than the real table. If the prefixes are genuinely still there after a refresh, check the session counters: they show how many prefixes are accepted right now. A gap between that and the route table means the withdraw never applied, because an inbound policy is holding the route.
/routing/bgp/session/print
vtysh -c 'show bgp summary'
birdc show protocols all bgpcast
The same prefix arrives more than once
This is not a fault. One CIDR can belong to several of the categories you subscribe to, and it arrives as a separate announcement from each, carrying its own BGP community. Your router picks one best path and keeps the rest in adj-in. If the duplicates are in the way, drop the extra category or filter on the community.
vtysh -c 'show bgp ipv4 unicast <prefix>'
birdc show route for <prefix> all