Palo Alto rejecting one route

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Palo Alto rejecting one route

L2 Linker

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

 

 

1 accepted solution

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

13 REPLIES 13

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

Pavel

Help the community: Like helpful comments and mark solutions.

Thanks for the reply. My import list is allow 10.0.0.0/16 & the route I’m missing is 10.240.0.0/16. 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?

Thanks

Do you have 10.240.0.0/16 allowed on an import list? That doesn't fall in 10.0.0.0/16.

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

StevenTurner_0-1653506017036.png

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 10.240.0.0 is an ibgp neighbor, is 'next-hop-self' configured? Maybe the advertised next hop for 10.240.0.0 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.

 

Thanks,

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 10.242.0.0/16 that is accepted and placed in the fib. However the 10.240.0.0/16 seems to be rejected. Next hop on both destinations is the same. The suggested logs did not produce any insight to the cause.

 

10.200.250.26 - is the PAN

10.200.250.25 - is the DMVP peer

 

StevenTurner_0-1653665913900.png

 

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

  • 1 accepted solution
  • 5128 Views
  • 13 replies
  • 0 Likes
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!