🔥 Palo Alto BGP Case Study — Route Advertised, Session Up, Still NO Traffic

This one almost turned into a production routing incident.

🧩 Real Scenario
Multiple Palo Alto firewalls peered via iBGP
One site firewall admin confirmed:
Route was advertised
BGP session Established
On my firewall:
Route not visible
Traffic to that subnet blackholing
At first, it sounded like a remote firewall issue.
It wasn’t.

🔍 Deep Dive (What Most People Miss)
BGP troubleshooting usually stops at:
Session status ✅
Route advertised ✅
But on Palo Alto, that’s not enough.
I checked: ✔ BGP RIB
✔ Import policy
✔ Prefix match logic

That’s where the issue surfaced.
⚠️ Root Cause (Critical)
👉 The subnet was NOT allowed in the BGP Import Policy.
So the firewall:
Received the route
Evaluated the import policy
Rejected it silently
Never installed it into the routing table
No error.
No alert.
Just missing reachability.

💥 Why This Is Dangerous
This can easily lead to:
Partial site outages
Asymmetric routing
“Works from some firewalls, not others” issues
Long war rooms blaming the wrong team
Especially risky in:
Hub-and-spoke designs
Multi-DC environments
Firewall-to-firewall BGP meshes

🛠️ The Fix
Updated BGP Import Policy
Explicitly allowed the required subnet
Route installed immediately
Traffic restored

🧠 Architect-Level Lesson
In Palo Alto:
BGP route advertisement ≠ usable route
A route must: 1️⃣ Be advertised
2️⃣ Be received
3️⃣ Match Import Policy
4️⃣ Win route selection
Miss any one step, and traffic breaks.

🧠 Final Takeaway
Most BGP “mysteries” are not protocol problems.
They are policy problems.
If you don’t see a route: ❌ Don’t argue with the peer admin
✅ Check your import logic first
Have you faced a situation where BGP was “up” but routing was broken?
Those are the hardest ones. Let’s discuss