Manual

A BGP session will not come up, or keeps flapping

BGP is TCP. Without a session, look at reachability and the firewall first and at BGP second.

You set up a BGP peering with your provider, with a second site or between two routers in your own network. The session never reaches established, or it comes up and drops a minute later, or it is up and not a single route arrives.

What it is not: in most cases this is not a BGP problem. BGP talks over an ordinary TCP connection on port 179. If that connection does not come up, BGP has not entered the picture yet and you are looking in the wrong place. So take the bottom layer first.

Three pictures, three causes. A session that never comes up is reachability, firewall or authentication. A session that goes up and down is a timer expiring. A session that stands and delivers nothing is a filter.

The quick checks, in order

  1. What is the state? /routing bgp session print. A good answer: a session with established: yes and an uptime that climbs. An uptime that keeps restarting at zero is a flap.
  2. What does the log say? /log print where topics~"bgp". This is the shortest route to the answer. On a refusal BGP sends a notification with the reason in it, and it ends up here.
  3. Is the peer reachable? /ping peer, and if you use a local address /ping peer src-address=your address. A good answer: replies, from the address you also use for BGP.
  4. Does port 179 get in? /ip firewall filter print stats and look at the input chain. A good answer: a rule accepting TCP 179 from this peer, and a final drop whose counter does not climb while you try.
  5. What comes in and what goes out? /ip route print where bgp for what you receive and /routing bgp advertisements print for what you send. A good answer: exactly the prefixes you expected, and no more.

The usual causes, most common first

The firewall does not let port 179 in

The default input chain accepts traffic from the LAN list and drops the rest. A peering with your provider arrives from WAN and therefore falls outside it. Add a rule accepting TCP 179 from that one peer's address, not from everything.

The AS number is wrong

With eBGP the AS number is checked in the OPEN. A different number on your side than the peer expects gives a notification and the session closes again immediately. Check both sides literally, your own AS included.

The source address is not what the peer expects

If you peer on loopback addresses, your session has to leave from that loopback too. Leave the local address empty and the router picks the outgoing interface's address, which the peer does not recognise.

Multihop is off while there is more than one hop

An eBGP session leaves with a TTL of 1 by default, so it survives exactly one router. Peering on loopbacks needs multihop on both sides.

The MD5 key differs

A TCP MD5 password set on one side, or different on both, makes the TCP connection itself fail. You then get no clean BGP message but a connection that never comes up, which makes the search a good deal longer. Check the key character by character.

The session flaps: a timer expires

BGP expects keepalives at regular intervals. When those go missing through packet loss, a full CPU or an MTU narrowing along the way, the hold timer expires and everything starts over. Large UPDATE packets vanishing silently through a small MTU give exactly this picture; test with /ping peer size=1400 do-not-fragment.

The session is up, but nothing goes out

That is a filter, and it is the most common surprise in a fresh setup. See below what the tool does here.

What the configurator does about it

  • BGP lives in the Routing section, off by default. You fill in your own AS, a router ID or a loopback, a list of networks to advertise, and per peer a name, address, remote AS, local address, TCP MD5 password, multihop and the choice to accept only a default route.
  • The script writes one default template with your AS and router ID, and below it one /routing bgp connection per peer. The role is derived: a remote AS equal to yours makes it iBGP, otherwise eBGP. So it is not a field you choose.
  • The networks you list go into an address list bgp-networks, and that list becomes the template's output.network.
  • Two filter chains are written. bgp-in-default-only accepts only 0.0.0.0/0 and attaches to a peer when you tick "accept default only". bgp-out-networks accepts only your own networks and attaches to every peer.
  • That is where the trap is: leave the networks field empty and bgp-out-networks consists of a single rule, and that rule is reject. The session comes up neatly and you advertise nothing. No warning is raised about it. So always fill your networks in, even when you assume it will sort itself out.
  • The tool does warn when a peer has no TCP MD5 password.
  • The connections get address-families=ip. IPv6 prefixes are therefore not exchanged.
  • In a site with several devices you can switch BGP on for a routed tunnel. The tool then fills in the peering on the tunnel addresses at both ends, drops the static routes over that tunnel because BGP now delivers them, and raises an error when one of the two routers has no AS number.
  • What the tool does not do: it does not open port 179 in the firewall. If you peer over WAN, add that rule yourself in the Firewall section, under Services on the router itself reachable from the internet, with the peer's address in the "only from" field.

Where the cause lies outside your router

  • The peer. With a provider the fault is just as often on the other side. Ask for the session state from their end before you keep digging.

Read on: BGP, Site-to-site tunnels and Firewall & NAT.

Want to try it right away? Open the configurator