BGP Route Maps on PAN-OS

Configure BGP route maps on Palo Alto Networks firewalls to manipulate path attributes and implement routing policy.

BGP Route Maps on PAN-OS

Route maps give you fine-grained control over BGP path selection and advertisement. They let you match on specific prefixes or attributes and then set new values — local preference, MED, AS path prepending — before routes are installed into the RIB or advertised to peers.

Prerequisites

Item Requirement
PAN-OS version 9.0 or later
Feature license None — BGP is included with all firewall licenses
BGP session At least one eBGP or iBGP peer established

You need an existing BGP configuration before adding route maps. At minimum: a virtual router with BGP enabled, your AS number set, and one configured peer.

How Route Maps Are Built

PAN-OS uses three stacked objects:

  1. Address Prefix — defines which networks to match (with optional exact-length flag)
  2. Filter — combines match conditions (prefix list, AS path regex, community string)
  3. Route Map — references a filter, sets a permit or deny action, and applies attribute overrides

Step 1 — Define Address Prefixes

# Match 10.0.0.0/8 and all more-specific prefixes (exact no = include longer prefixes)
set network virtual-router vr-main routing-protocol bgp policy \
    address-prefix-list RFC1918-10 address 10.0.0.0/8 exact no

# Match exactly 192.168.100.0/24 — no more-specifics
set network virtual-router vr-main routing-protocol bgp policy \
    address-prefix-list DC-LOOPBACKS address 192.168.100.0/24 exact yes

Step 2 — Create a Filter

Filters are reusable — you can reference the same filter in multiple route maps.

set network virtual-router vr-main routing-protocol bgp policy \
    filter MATCH-RFC1918 address-prefix-list RFC1918-10
set network virtual-router vr-main routing-protocol bgp policy filter MATCH-RFC1918 match-afi ipv4

Inbound Route Maps

Inbound maps run on prefixes received from a peer before they enter the BGP RIB.

Setting Local Preference

Local preference controls which exit point your AS uses for outbound traffic. Higher value wins.

set network virtual-router vr-main routing-protocol bgp policy \
    import rule PREFER-PRIMARY \
    action allow \
    match address-prefix-list RFC1918-10 \
    set local-preference 200

set network virtual-router vr-main routing-protocol bgp policy \
    import rule PREFER-BACKUP \
    action allow \
    match address-prefix-list RFC1918-10 \
    set local-preference 100

Note: Local preference is an iBGP-only attribute. It is stripped before advertising to any eBGP peer — do not rely on it to influence external neighbours.

Filtering Unwanted Prefixes

Deny rules stop specific prefixes from entering your RIB entirely.

# Drop all default route advertisements from peers
set network virtual-router vr-main routing-protocol bgp policy \
    address-prefix-list DEFAULT-ROUTE address 0.0.0.0/0 exact yes

set network virtual-router vr-main routing-protocol bgp policy \
    import rule BLOCK-DEFAULT \
    action deny \
    match address-prefix-list DEFAULT-ROUTE

Rules are evaluated top-down. Add a catch-all permit rule at the end if you want all other prefixes accepted — otherwise the implicit default is deny all.

Outbound Route Maps

Outbound maps run on prefixes being advertised to a peer.

AS Path Prepending

Prepend your own AS number to artificially lengthen the path, signalling to upstream peers that this link is a backup.

set network virtual-router vr-main routing-protocol bgp policy \
    export rule PREPEND-BACKUP \
    action allow \
    match address-prefix-list DC-LOOPBACKS \
    set as-path-limit 3 \
    set as-path-type prepend

This appends your AS three extra times. Most upstream peers will prefer the shorter path via your primary link.

Setting MED

MED (Multi-Exit Discriminator) influences which entry point a neighbouring AS uses for inbound traffic. Lower value is preferred, and it only works if both peers are in the same adjacent AS.

set network virtual-router vr-main routing-protocol bgp policy \
    export rule SET-MED-PRIMARY \
    action allow \
    match address-prefix-list DC-LOOPBACKS \
    set med 10

set network virtual-router vr-main routing-protocol bgp policy \
    export rule SET-MED-BACKUP \
    action allow \
    match address-prefix-list DC-LOOPBACKS \
    set med 100

BGP Attribute Quick Reference

Attribute Scope Better value Typical use
Local Preference iBGP only Higher Choose outbound exit from your AS
MED eBGP, 1 hop Lower Influence inbound from adjacent AS
AS Path Length Both Shorter Backup path via prepending
Weight Local router only Higher Per-router preference (not propagated)
Community Both n/a Tag routes for downstream policy

Applying the Map to a Peer

Route maps don't take effect until they are assigned to a BGP peer under import-rules or export-rules.

# Assign inbound and outbound maps to a specific peer
set network virtual-router vr-main routing-protocol bgp peer-group UPSTREAM \
    peer PEER1 \
    import-rules PREFER-PRIMARY

set network virtual-router vr-main routing-protocol bgp peer-group UPSTREAM \
    peer PEER1 \
    export-rules PREPEND-BACKUP

Verification

After committing, verify route map application without bouncing sessions:

# Soft-reset inbound policy (no session drop)
clear routing protocol bgp peer PEER1 soft-reset in

# Check the BGP RIB for local preference values
show routing protocol bgp loc-rib

# Inspect a specific prefix
show routing protocol bgp loc-rib prefix 10.0.0.0/8

Expected output for a matched inbound prefix:

Destination     NH             Metric  LocPref  Weight  Status
10.0.0.0/8      192.168.1.1    0       200      100     A iBest

The LocPref column confirms the route map was applied. If it shows the BGP default of 100, the map is not matching — check your prefix list and filter assignment.

Common Issues

Route map not matching any prefixes

Verify the prefix list uses the correct network and exact-match setting. A /8 with exact yes matches only 10.0.0.0/8, not 10.1.0.0/24. Use exact no to include more-specifics.

Attribute changes not visible after commit

Policy changes require a soft reset to re-process existing prefixes: clear routing protocol bgp peer <peer> soft-reset in. Avoid a hard reset (clear routing protocol bgp peer <peer>) in production — it drops and re-establishes the session.

Local preference has no effect on eBGP peer

Expected behaviour. Local preference is stripped at every eBGP boundary. Use MED or AS path prepending to influence external neighbours instead.

Implicit deny dropping legitimate prefixes

PAN-OS applies an implicit deny all at the end of every rule list. If your map only has deny entries, all other prefixes are silently dropped. Add a final permit rule with no match conditions to pass everything else through.