Yeah, That BGP Auth Error Is Annoying
You're staring at a log full of BGP-AUTH-FAILURE messages, and the neighbor just won't stay up. I've been there. Last month a client's entire inter-DC link went down because someone copy-pasted the config wrong. Let's get this fixed.
First Thing to Check: The Password Itself
On Cisco IOS or IOS-XE, the BGP neighbor command looks like this:
router bgp 65001
neighbor 10.0.0.1 remote-as 65002
neighbor 10.0.0.1 password mySecretKeyOn Juniper, it's under protocols bgp group:
set protocols bgp group external neighbor 10.0.0.1 authentication-key mySecretKey9 times out of 10, the password doesn't match on both ends. It's case-sensitive. One space at the end of the string? Breaks it. I've seen people use “password” with quotes by mistake. Don't.
Real Fix: Verify Both Sides with a Show Command
On Cisco, run:
show running-config | section router bgpOn Juniper:
show configuration protocols bgp group <group-name>Compare the authentication-key or password strings exactly. If they match, move to the next check.
Second Common Culprit: MD5 Algorithm Mismatch
BGP uses TCP MD5 for authentication. Some older gear (like Cisco 2600 series) uses a different hash algorithm than newer ones. If you're mixing IOS versions, you might need to set the message-digest-algorithm to md5 explicitly. On newer IOS, it's default. On Juniper, check authentication-algorithm md5. If one side uses a different algorithm (like SHA-1 on some platforms), the neighbor won't form.
Less Common Variations
Case: TCP Port Blocking
I once spent 2 hours debugging a BGP auth failure only to find that a firewall between the routers was dropping TCP segments with the MD5 option set. The MD5 signature is carried in the TCP header's options field. Some cheap firewalls or older ACLs strip that. Check if you can form a neighbor without password first — if it works, then the problem is the MD5 option being blocked.
Case: Time Sync Issues
BGP authentication doesn't check time itself, but MD5 relies on a consistent TCP connection. If both routers' clocks are way off (like more than a few minutes), TCP sequence numbers can get out of sync and cause auth failures. Run show ntp associations on both ends. I had a client whose NTP server died, and the drift caused BGP flaps every 10 minutes.
Case: VRF or Routing Instance
If the neighbor is in a VRF on one side but not on the other, the authentication key might not apply to the right VRF. On Cisco, you need neighbor 10.0.0.1 password xyz under the VRF configuration. On Juniper, ensure the authentication-key is under the correct routing-instance. Simple mistake, but it bites people who manage multiple VRFs.
Why This Fix Works
BGP authentication is just a TCP MD5 checksum of the segment plus the password. If the passwords don't match, the checksum won't validate, and the router drops the TCP segment. No OPEN message, no neighbor. It's binary. So checking the password string is the most direct fix. The algorithm mismatch or TCP option blocking are less common but still real. The fix works because it removes the most common variable: human error in config.
How to Prevent This
- Use a password manager or keep a plaintext copy of the password in your network inventory. Never rely on memory.
- Standardize on one algorithm across all routers. If you mix vendors, pick MD5 for compatibility.
- Automate config backups and compare after changes. Tools like RANCID or oxidized catch mismatches fast.
- Test BGP neighbor with password disabled during maintenance windows to rule out firewall issues. Then reenable.
- Set up monitoring that alerts on BGP state changes. A flap is a sign of something wrong.
And if you're still stuck, check the ASCII value of the password. I once found a hidden non-printable character from a bad copy-paste. Use show running-config | include password and look for any odd characters. That's the kind of edge case that makes you question your sanity.
Bottom line: BGP auth failure is almost always a simple mismatch. Check the string, check the algorithm, check the firewall. Don't overthink it.