BGP Advertising prefix to same AS it was learned from.

[Tyler_C]

I'm working on a VRF-centric DC model that utilizes a PA as the firewall platform between VRFs. One of the snags I'm hitting is that if a route is learned from R1 on an AS (say 65001), and is advertised via eBGP to the PA (AS 65002), the PA won't even attempt to advertise it to R2 (Really R1, in VRF AF - AS 65001). I can work around this by spoofing my AS number to the PA, but I'd rather not add more complexity than necessary.

I understand the behavior is documented below, however this goes against the RFC, where eBGP uses the AS path as loop prevention. The PA is not in AS 65001, and should not be making this decision on behalf of R1 and R2.

https://live.paloaltonetworks.com/t5/Management-Articles/BGP-Advertisements-through-an-eBGP-Peer-not...

Expected behavior per RFC is that the device receiving the Prefix Advertisement will make the decision.

https://tools.ietf.org/html/rfc4271

"If the AS_PATH attribute of a BGP route contains an AS loop, the BGP route should be excluded from the Phase 2 decision function. AS loop detection is done by scanning the full AS path (as specified in the AS_PATH attribute), and checking that the autonomous system number of the local system does not appear in the AS path. Operations of a BGP speaker that is configured to accept routes with its own autonomous system number in the AS path are outside the scope of this document."

[nextgenhappines]

@Tyler_C  Just curious is the R1 a Cisco router?    You may want to check out the allowas-in 

See AS_PATH includes the local AS

http://packetlife.net/blog/2008/nov/19/probable-reasons-bgp-isnt-installing-route/

[Tyler_C]

Thanks for taking the time to reply.

Allow-AS in is already configured on my devices, but the problem is on the PA side. If you check the routing table, it has an eBGP learned default route, and is not trying to advertise it at the neighbor. Ideally, the PA should accept the route, and pass it along, leaving it up to my device to decide what to do with the PA. That is not happening. If I change the AS on one side, the route is now advertised, and my device sees it being presented.

[nextgenhappines]

@Tyler_C  Can you take some screen shots on your PAN VR setup?  specificlly on the BGP -> Export and BGP -> Redist-Rules ?

Also, can you include "show routing protocol bgp summary" and " show routing protocol bgp rib-out-detail"  output.

[Tyler_C]

Here's the CLI output. First two are with R9-Ext configured for AS 65104 (same as R9 in VRF). Second two are when configured for a public AS. Ignore the public IP addressing, it was pulled out of nowhere to build this in a lab.

Not using redistribution, 100% eBGP routing. Import/Export is really simple, one profile created for each that contains all three peers (R10 is inactive), and allowing all routes inbound and outbound.

---------------Using the same AS number on both sides--------------------
####@PA-VM> show routing protocol bgp summary
==========
router id: 10.208.254.100
virtual router: Global-VR
reject default route: no
redist default route: block
Install BGP routes: yes
Graceful Restart: supported
AS size: 2
Local AS: 65110
Local member AS: 0
Cluster id: 10.208.254.100
Default local preference: 100
Always compare MED: no
Aggregate regardless MED: no
Deterministic MED processing: no
Accept ORF: no
Accept CISCO style prefix: yes
rib-out entries: current 0, peak 10
peer R9: AS 65104, Established, IP 10.208.254.9
bgpAfiIpv4/unicast pfx: Accepted pfx: 3, Advertised pfx: 0
peer R10: AS 65104, Connect, IP 10.208.254.10
peer R9-EXT: AS 65104, Established, IP 117.35.200.250
bgpAfiIpv4/unicast pfx: Accepted pfx: 1, Advertised pfx: 0

####@PA-VM> show routing protocol bgp rib-out-detail

VIRTUAL ROUTER: Global-VR (id 2)
==========

------------Spoofing AS number as public ASN on one side----------------

####@PA-VM> show routing protocol bgp summary

==========
router id: 10.208.254.100
virtual router: Global-VR
reject default route: no
redist default route: block
Install BGP routes: yes
Graceful Restart: supported
AS size: 2
Local AS: 65110
Local member AS: 0
Cluster id: 10.208.254.100
Default local preference: 100
Always compare MED: no
Aggregate regardless MED: no
Deterministic MED processing: no
Accept ORF: no
Accept CISCO style prefix: yes
rib-out entries: current 4, peak 10
peer R9: AS 65104, Established, IP 10.208.254.9
bgpAfiIpv4/unicast pfx: Accepted pfx: 3, Advertised pfx: 1
peer R10: AS 65104, Connect, IP 10.208.254.10
peer R9-EXT: AS 100, Established, IP 117.35.200.250
bgpAfiIpv4/unicast pfx: Accepted pfx: 1, Advertised pfx: 3

#####@PA-VM> show routing protocol bgp rib-out-detail

VIRTUAL ROUTER: Global-VR (id 2)
==========
----------
Prefix: 0.0.0.0/0
Nexthop: 10.208.254.100
Peer: R9 (id 16)
Advertise status: advertised
Aggregation status: no aggregate
Originator ID: 0.0.0.0
AS Path: 65110,100
Origin: N/A
MED: 0
Local Preference: 0
Atomic aggregate: no
Aggregator AS: 0
Aggregator ID: 0.0.0.0
----------
Prefix: 10.99.201.0/24
Nexthop: 117.35.200.15
Peer: R9-EXT (id 18)
Advertise status: advertised
Aggregation status: no aggregate
Originator ID: 0.0.0.0
AS Path: 65110,65104,65101
Origin: N/A
MED: 0
Local Preference: 0
Atomic aggregate: no
Aggregator AS: 0
Aggregator ID: 0.0.0.0
----------
Prefix: 10.208.101.0/24
Nexthop: 117.35.200.15
Peer: R9-EXT (id 18)
Advertise status: advertised
Aggregation status: no aggregate
Originator ID: 0.0.0.0
AS Path: 65110,65104,65101
Origin: N/A
MED: 0
Local Preference: 0
Atomic aggregate: no
Aggregator AS: 0
Aggregator ID: 0.0.0.0
----------
Prefix: 10.208.250.155/32
Nexthop: 117.35.200.15
Peer: R9-EXT (id 18)
Advertise status: advertised
Aggregation status: no aggregate
Originator ID: 0.0.0.0
AS Path: 65110,65104,65111
Origin: N/A
MED: 0
Local Preference: 0
Atomic aggregate: no
Aggregator AS: 0
Aggregator ID: 0.0.0.0

[nextgenhappines]

Do you have a diagram?  This show the default route is getting advertised.   Can you check on the receiving what routes are receiving and what is it rejecting?

#####@PA-VM> show routing protocol bgp rib-out-detail

VIRTUAL ROUTER: Global-VR (id 2)
==========
----------
Prefix: 0.0.0.0/0
Nexthop: 10.208.254.100
Peer: R9 (id 16)
Advertise status: advertised
Aggregation status: no aggregate
Originator ID: 0.0.0.0
AS Path: 65110,100
Origin: N/A
MED: 0
Local Preference: 0
Atomic aggregate: no
Aggregator AS: 0
Aggregator ID: 0.0.0.0
----------

[Tyler_C]

Cleaned up formatting a bit, hopefully it's easier to read now. The first grouping is when using 65104 on both peers, and the second grouping is when 65104 has been spoofed to AS100 by one side (still 65104 internally, but to the PA, it's 100). 

The advertisements show that when using the same ASN on both peers, the PA seems to be invoking BGP loop prevention, even though it should not due to it not being a member of AS65104. Only devices in AS65104 should do anything about a loop in the AS-Path. Once I trick the PA into thinking the peers are in a different ASN, it starts advertising the routes through (this is the second grouping).

[nextgenhappines]

This is taking from https://www.safaribooksonline.com/library/view/junos-high-availability/9780596805449/ch13s02.html (JUNOS High Availability Book).  Is that how you have it setup now R1 is the firewall, R2 and R3 are the same router but with different VRF and using the same ASN?

[Tyler_C]

It's similar, but not exactly the same, but yes this is the behavior I'm trying to achieve (having R1 make the decision to drop the traffic, not R2). The inside-VRF doesn't peer directly with the global table (outside-VRF).

[Default Route}AS65104-R9-EXT <-> AS65110-PA <-> AS65104-R9-VRF[Connected Routes]

R9-EXT only advertises a default route to the PA, and R9-VRF advertises some connected routes to the PA. The PA is then expected to pass both sets of routes to the other peer.

The diagram you linked is following the RFC as written: only R1 should make the decision of whether to drop the prefix advertisement, based on if it sees it's own AS number in the path. The behavior we're seeing is that the PA sees it's peered to the same AS and dropping the prefix early. This breaks the RFC and makes it so that any standard controls to work around BGP loop prevention are ineffective.

[nextgenhappines]

Have you try enable Allow Redistribute Default Route, under Network -> Virtual Router > BGP > Redist Rules. 

####@PA-VM> show routing protocol bgp summary

==========
router id: 10.208.254.100
virtual router: Global-VR
reject default route: no
redist default route: block

[Tyler_C]

I have, it made no difference.

[nextgenhappines]

Have you open a case?  This is interesting, if you can keep us posted on the tac result, that will be great.

[nextgenhappines]

@Tyler_C   Does each of the VRF have an unique router-ID?

[Tyler_C]

Yes, both sides are presenting different router IDs to the Palo. Haven't opened a TAC case yet, will soon.

[DavisJames]

Did you ever get this resolved...

I'm going to be facing this situation soon, normally I would use local-as, or allow-as-in or override-as

I'm trying to work a method on the import policy with regex remove... it's not nice...

it's some basic functionality that's missing.