How to Check BGP Session Status on Linux: BIRD 2 and FRRouting, Idle/Active/Established Explained

When you announce your own IP prefixes from a dedicated server, the first thing to check is the BGP session status: it must be Established. This guide shows how to inspect and verify BGP sessions on Linux with BIRD 2 and FRRouting (FRR), explains states such as Idle, Active and Established, and walks through troubleshooting when a session will not come up. It applies to Debian/Ubuntu and CentOS/Rocky/AlmaLinux. In the examples the local ASN is 64500, the upstream peer is 203.0.113.1 and the announced prefix is 198.51.100.0/24.

Step 1: Install BIRD 2 or FRRouting

If nothing is installed yet, pick one of the daemons below. BIRD has a compact configuration that suits single-server announcements; FRR uses a Cisco-like syntax familiar to network engineers.

# Debian / Ubuntu
apt install -y bird2        # or: apt install -y frr
# CentOS / Rocky / AlmaLinux
dnf install -y epel-release && dnf install -y bird   # BIRD 2.x from EPEL
dnf install -y frr                                  # or FRRouting

Step 2: Check BGP session status in BIRD with birdc

birdc show protocols lists all protocols; a BGP session showing Established in the Info column is healthy. Adding all reveals the peer ASN, hold timer, route counts and the last error, while show route export confirms your prefix is actually being sent upstream.

birdc show protocols
birdc show protocols all upstream1
birdc show route export upstream1
birdc show route protocol upstream1 count

Name       Proto      Table      State  Since         Info
device1    Device     ---        up     2026-10-01
upstream1  BGP        ---        up     2026-10-01    Established

Step 3: Check BGP session status in FRR with vtysh

Run show bgp summary. If the State/PfxRcd column shows a number (prefixes received), the session is Established; words such as Idle, Active or Connect mean it is not. The neighbors subcommands show details plus advertised and received routes.

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast neighbors 203.0.113.1"
vtysh -c "show bgp ipv4 unicast neighbors 203.0.113.1 advertised-routes"
vtysh -c "show bgp ipv4 unicast neighbors 203.0.113.1 routes"

Note that recent FRR releases enable ebgp-requires-policy by default. An eBGP neighbor without inbound/outbound policy shows (Policy) in the summary: the session is up but no routes are exchanged. Attach route-maps to fix it:

router bgp 64500
 address-family ipv4 unicast
  network 198.51.100.0/24
  neighbor 203.0.113.1 route-map UPSTREAM-IN in
  neighbor 203.0.113.1 route-map UPSTREAM-OUT out
 exit-address-family

Step 4: Understand the common BGP session states

Both BIRD and FRR follow the BGP finite state machine defined in RFC 4271. These commands print only the current state and the last error:

birdc show protocols all upstream1 | grep -E "BGP state|Neighbor AS|Last error"
vtysh -c "show bgp ipv4 unicast neighbors 203.0.113.1" | grep -E "BGP state|Last reset"

Step 5: Troubleshoot a BGP session that is not Established

Confirm you can ping the peer and reach TCP 179, then make sure the local firewall accepts port 179 from the peer.

ping -c 4 203.0.113.1
nc -zv 203.0.113.1 179
ss -tnp | grep ':179'

# iptables (Debian / Ubuntu)
iptables -I INPUT -p tcp -s 203.0.113.1 --dport 179 -j ACCEPT
# firewalld (CentOS / Rocky / AlmaLinux)
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.1" port port="179" protocol="tcp" accept'
firewall-cmd --reload

Read the logs for the exact error, for example "Bad peer AS" (wrong ASN) or "Hold timer expired" (link or firewall problem). After changing the configuration you can restart just that session:

journalctl -u bird -n 50 --no-pager
journalctl -u frr -n 50 --no-pager
birdc restart upstream1
vtysh -c "clear bgp ipv4 unicast 203.0.113.1 soft"

FAQ

The session is Established but my prefix is not visible on the internet

Check that the export filter permits the prefix, that it has an IRR route object and a valid ROA, and that the upstream has refreshed its filters. Verify with a public looking glass.

The session keeps flapping between Active and Idle

Usually TCP 179 is unreachable or the peer is not configured yet. Recheck IPs, ASNs, multihop requirements and the MD5 password on both sides.

Can IMIDC help set up the BGP session?

If you lease IPs or an ASN from IMIDC and announce them from IMIDC servers, open a ticket with your ASN, prefixes and session requirements and our engineers will help with the peering.

Still stuck? Open a ticket with IMIDC 24/7 technical support.