We have an AWS Palo Alto VM-Series firewall with a BGP tunnel to an AWS Transit Hub.
Palo Alto was advertising all connected cloud region subnets.
BGP session was established and stable.
Routes were visible on the Palo Alto firewall.
However, the AWS admin could not see any routes on the Transit Hub side
At first glance, this looked like a classic BGP configuration issue.
🔍 Investigation and Analysis
We validated the setup step by step:
BGP session was up.
Routes were present in the Palo Alto routing table.
ASNs and peer IPs were correct.
No export or redistribution filters were blocking prefixes
Yet, routes were still not received on the AWS side.
This led us to verify something that is often overlooked.
⚠️ Root Cause
AWS had reached the maximum allowed BGP route limit for the existing Transit Hub plan.
Once this threshold is reached:
AWS silently stops accepting new routes
No explicit BGP error is generated
Palo Alto continues to advertise routes normally
Engineers often keep troubleshooting the firewall
✅ Resolution
AWS team upgraded the Transit Hub plan
Route capacity was increased
All advertised routes from Palo Alto immediately appeared
Traffic started flowing without any firewall configuration changes
🧠 Key Takeaways (Architect Perspective)
A BGP session being up does not guarantee route acceptance
Always validate cloud platform route limits during troubleshooting
Cloud networking failures can be silent and misleading
Firewalls are often blamed while the root cause is platform capacity
Capacity planning is a core part of network and security design
💡 Final Thought
Most BGP issues in cloud environments are not protocol problems.
They are service limits presenting themselves as network failures.
Have you encountered similar silent route drops in cloud networking?
No comments:
Post a Comment