Sunday, 4 January 2026

๐Ÿ” BGP routes were advertised… but never used.


(Palo Alto Networks case)

On a Palo Alto firewall, the BGP session was UP.
Routes were visible in the routing table.
Yet… traffic still didn’t flow ❌

In this setup:
BGP peering was established on Palo Alto Networks firewall
Routes were successfully learned via BGP
No session drops, no errors
Still, applications were unreachable.
What was the real issue?
➡️ Routing ≠ Forwarding (especially on Palo Alto)
Although the route existed:
It was not the active route
A static / connected route had higher preference
The BGP route never made it to the forwarding table (FIB)

So traffic never followed the BGP path.
๐Ÿง  What fixed it:
✔️ Verified Palo Alto route preference (Admin Distance)
✔️ Checked overlapping static routes
✔️ Cleaned up temporary test configs
✔️ Validated the forwarding table, not just the routing table

๐Ÿงฉ Architect takeaway:
On Palo Alto firewalls,
having a route ≠ traffic using it.
Always check:
Which route is installed
Why it’s preferred
How traffic is actually forwarded
If you’ve ever said
“The route is present on Palo Alto” —
this is why traffic still fails.

No comments:

Post a Comment

๐Ÿ”ฅ The Hidden Risk of “Wide Open” Internal Policies — And How To Remove Them Safely

In one of my recent projects, I noticed a wide open internal traffic policy in place. Later, I was asked to work on this issue and remove th...