BGP AS-Path Prepending Rejected by Peer: Causes and Fixes with BIRD and FRR Examples

AS-path prepending is the standard way to steer inbound traffic in a multi-homed BGP setup: you repeat your own ASN in announcements to one upstream so that path looks longer and less preferred. Many operators find that their BGP AS-path prepending is rejected by the peer: the prefix disappears from that upstream or the prepend has no effect. This guide covers the usual causes (path length limits, AS-path filters, IRR/RPKI checks) and shows correct BIRD 2 and FRRouting configurations for Debian/Ubuntu and CentOS/Rocky/AlmaLinux. Examples use local ASN 64500, upstream 203.0.113.1 (AS64496) and prefix 198.51.100.0/24; replace them with your real values.

Step 1: Confirm that the AS-path prepend is being rejected

First check that your router really sends the prepended path, then look in the logs for NOTIFICATION messages or session resets, and use a public looking glass to see which AS paths the world receives. If your output is correct but no path via that upstream is visible externally, it is being filtered by the upstream or further away.

# BIRD 2
birdc show route 198.51.100.0/24 export upstream1 all
journalctl -u bird --since "1 hour ago" --no-pager
# FRRouting
vtysh -c "show bgp ipv4 unicast neighbors 203.0.113.1 advertised-routes"
vtysh -c "show bgp ipv4 unicast neighbors 203.0.113.1" | grep -iE "state|prefix|notification"

curl -s "https://stat.ripe.net/data/looking-glass/data.json?resource=198.51.100.0/24" | grep -o '"as_path":"[^"]*"' | sort | uniq -c

Step 2: Prepend only your own ASN

The most common mistake is prepending a foreign ASN (the upstream's or another network's) or inserting one at the end of the path, which changes the origin AS. Upstreams usually enforce that the first ASN equals the neighbor ASN and validate the origin against your as-set; unrelated ASNs in the path look like a hijack and are dropped. Private ASNs (64512–65534) are often filtered too. Here is the correct BIRD 2 configuration; BIRD adds the local ASN once more on eBGP export:

# /etc/bird/bird.conf (BIRD 2)
filter export_upstream1 {
  if net = 198.51.100.0/24 then {
    bgp_path.prepend(64500);   # own ASN only
    bgp_path.prepend(64500);
    accept;
  }
  reject;
}

protocol bgp upstream1 {
  local as 64500;
  neighbor 203.0.113.1 as 64496;
  ipv4 {
    import none;
    export filter export_upstream1;
  };
}

birdc configure

Step 3: Configure AS-path prepending in FRRouting

FRR applies prepends with an outbound route-map. Use a soft out reset afterwards so the session stays up.

vtysh
configure terminal
ip prefix-list MY-NETS seq 10 permit 198.51.100.0/24
route-map UPSTREAM-OUT permit 10
 match ip address prefix-list MY-NETS
 set as-path prepend 64500 64500
exit
route-map UPSTREAM-OUT deny 100
exit
router bgp 64500
 address-family ipv4 unicast
  neighbor 203.0.113.1 route-map UPSTREAM-OUT out
 exit-address-family
end
write memory
clear bgp ipv4 unicast 203.0.113.1 soft out

Step 4: Keep the AS path short enough to avoid length filters

Many networks drop routes with overly long AS paths, and some limit how many times one ASN may repeat. One to three prepends are enough to influence path selection; beyond five there is almost no benefit and a growing risk of filtering. Another frequent cause is an overly strict AS-path filter at the upstream, for example a regex like ^64500$, which rejects "64500 64500 64500". Ask the upstream to use something like ^(64500_)+$ instead.

Check the actual AS path you send:

birdc show route 198.51.100.0/24 export upstream1 all | grep BGP.as_path
vtysh -c "show bgp ipv4 unicast 198.51.100.0/24"

Step 5: Check IRR route objects and RPKI/ROA

Prepending does not change the origin AS, but the upstream will still reject the prefix if it has no IRR route object, is missing from the as-set you registered with them, or the ROA origin ASN or max length does not match. Check with:

whois -h whois.radb.net -- '-i origin AS64500'
whois -h whois.ripe.net -- '-T route 198.51.100.0/24'
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS64500&prefix=198.51.100.0/24"

The RPKI status should be valid; if it is invalid, fix the ROA first. Upstream filter lists usually refresh automatically after a while, or you can ask the upstream for a manual update.

FAQ

I prepended but traffic did not move

Remote networks may prefer routes using Local Preference, which beats AS-path length, so prepending has no effect there. Try upstream communities or change the granularity of the prefixes you announce.

Can I prepend my upstream's ASN?

No. Only repeat your own ASN. Adding other ASNs breaks path authenticity and most networks will drop the route.

Can IMIDC help with prepending?

If you announce your own or leased IPs from IMIDC servers, describe your requirements in a ticket and our engineers will check the session, filters and IRR/ROA status.

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