Palo Alto rejecting one route

cancel
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?

 

Thanks

 

 

13 REPLIES 13

Hey @StevenTurner ,

Unfortunately I also not able to explain what "reject by policy" means, but looking at the two screenshots you provide it seems the prefix is rejected because of the BGP loop prevention:

- From first screenshot it seems that PAN FW is using ASN 65200

- From the packet capture screenshot you can see that 65200 is part of the AS PATH advertised for this prefix. BGP loop prevention will reject any prefix when it sees its own ASN in the path. You can see that for 10.242.0.0/16 FW ASN is no in the AS PATH, therefor it is accepted.

 

If you are absolutetly sure that you need to accept this prefix, even if FW ASN is in AS PATH, you can tell the firewall to remove specific AS from the path with Import rule. That way BGP loop prevention will not kick in and will accept the route. The following link gives example how to configure Import rule that will remove ASN https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClEkCAK In the example they use regex, that will remove any of the two ASN, but in your case you can simply remove only 65200

I do see the PAN AS in the path for 10.240.0.0/16, didn't notice that as it is not expected. The 10.242.0.0/16 route is learned from the same neighbor and is just another route same as the 10.240, the PAN AS does not show up in this one, odd. Both routes are out the same interface and are NOT learned from any other peer.

 

Why would the PAN place it's own AS here? 

 

Thanks for the help Astardzhiev

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?

One of my peers did remember another site using the same AS. Didn't even know it was there. Thanks for the help

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!