Palo Alto rejecting one route

[StevenTurner]

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

[PavelK]

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

[StevenTurner]

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

[rmfalconer]

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

[StevenTurner]

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

[StevenTurner]

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

[rmfalconer]

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? 

[StevenTurner]

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,

[rmfalconer]

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

[StevenTurner]

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

[aleksandar.astardzhiev]

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

[StevenTurner]

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

[rmfalconer · Accepted solution]

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?

[StevenTurner]

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