Palo Alto rejecting one route

Showing results for 
Search instead for 
Did you mean: 

Palo Alto rejecting one route

L1 Bithead

I'm having trouble seeing one route in my RIB and FIB. My BGP peer shows it is advertising the route to the Palo Alto, however I see the following when showing the peer at the PAN:

sstadmin@200-PFW-01> show routing protocol bgp peer peer-name DMVPN-Router

Prefix counter for: bgpAfiIpv4 / unicast
Incoming Prefix: Accepted 49, Rejected 0, Policy Rej 1, Total 49


Notice one router is rejected by policy. I feel this is my missing route. FYI the reject default route but is not ticked in the BGP configuration, so this rejected route is not that.


What is causing this one rejected route by policy?






Accepted Solutions

The PAN didn't place it's own AS in the path, that was inserted along the way. It looks like 10.240 was originated by AS 65201, which peers with AS 65200. Is there another 65200, or another device besides the PAN in 65200?

View solution in original post


Cyber Elite
Cyber Elite

Thank you for the post @StevenTurner


I just looked into my BGP peer and I can see hundreds of policy rejected routes. In my case, I credit this to BGP Import map with exact match. Import list would be the first thing I would be looking into. If you have any filter in place, add this route to the list.


Kind Regards


Help the community: Like helpful comments and mark solutions.

Thanks for the reply. My import list is allow & the route I’m missing is Exact match is not checked. It’s odd to me as non of my FW are having this drop by policy ticking. They are all on the same template with the same BGP peer.

I’m have trouble finding any documentation on what this policy deny is meaning.

Anyone know?


Do you have allowed on an import list? That doesn't fall in

Sorry, you are correct. My allow list is Had a brain fart.


screen shot of my Import rule "Import-From-DMVPN" is the one we are looking at. The exact match button is not checked.

Have you looked at routed.log or run any debugs or captures? The captures could verify you're receiving the prefix and the log may show why it's not being installed.

If the advertising device of is an ibgp neighbor, is 'next-hop-self' configured? Maybe the advertised next hop for isn't reachable by the PA? 


The peer is ebgp. The next hop is available, same as all the other routes. That is the oddity here, this route is no different than all the others.


What logs and degus would you recommend? I have not had much experience going down that route to troubleshoot.



In Monitor-Packet Capture, you could start a capture on a specific interface, with filters for the BGP peer. 

Then reset the BGP peer so that you can generate some fresh traffic for the capture and logs. If you go through the capture in Wireshark, you can find which prefixes are being sent from the peer.


You might find something interesting with these at the CLI:

show log system direction equal backward subtype equal routing

less mp-log routed.log

So with a capture I can see my route getting sent in the update message. In fact, I see a second route that is accepted and placed in the fib. However the seems to be rejected. Next hop on both destinations is the same. The suggested logs did not produce any insight to the cause. - is the PAN - is the DMVP peer




Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!