Request for Comments: 4271 - Interpretation of 9.1.2 - is Cisco not compliant to this RFC?

[SamuelLewis40515]

Hello Everyone,

I have been unable to find a satisfactory answer online to this question so I thought I would try here as a last resort!

We recently had a large outage due to different interpretations of this RFC, specifically the part about AS path loop prevention mechanism and iBGP. The discussion with our vendor ended up with the vendor saying that Cisco are not compliant with this RFC and I have to admit they have a good point! 

Cisco does not implement AS path loop prevention in iBGP peerings, I was expecting the RFC to state that this is relevant only for eBGP but I cannot find this statement anywhere, is our vendor right that Cisco have purposefully not complied here or is it just implicit that this is only relevant for eBGP?

On our production network I see Cisco (IOS-XE and XR) will not block prefixes containing its own AS on iBGP peerings, I have edited our AS to be 666 in the following output and changed a few relevant IPs, the rest of the output remains the same though, you can see that Cisco will accept the prefixes. Below this I have pasted an the section from the RFC and the link, if anybody can put me out of my misery it would be highly appreciated!

RP/0/0/CPU0:PE100#sho run router bgp 666 address-family vpnv4 unicast
router bgp 666
address-family vpnv4 unicast
advertise best-external
additional-paths selection route-policy BACKUP
!
!

RP/0/0/CPU0:PE100#show bgp vpnv4 unicast rd 666:13429070 10.15.163.49/32
BGP routing table entry for 10.15.163.49/32, Route Distinguisher: 666:13429070
Versions:
Process bRIB/RIB SendTblVer
Speaker 444871730 444871730
Local Label: 16454
Last Modified: Nov 10 21:04:33.366 for 3y10w
Paths: (2 available, best #2)
Not advertised to any peer
Path #1: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.2
65505 65505 666 65505
172.20.98.158 from 172.20.98.158 (172.20.98.158)
Origin IGP, localpref 100, valid, external, best-external, backup, add-path, import suspect
Received Path ID 0, Local Path ID 2, version 444871730
Community: 34:20 8009:8009
Extended community: RT:666:13956066
Path #2: Received by speaker 0
Not advertised to any peer
65505 666 65505
66.66.91.156 (metric 100010) from 66.66.90.178 (66.66.91.156)
Received Label 17832
Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported, import suspect
Received Path ID 0, Local Path ID 1, version 444871730
Community: 34:20 8009:8009
Extended community: RT:666:13956066
Originator: 66.66.91.156, Cluster list: 66.66.90.178

RP/0/0/CPU0:PE100#show route vrf IPSA_666:13429070 10.15.163.49

Routing entry for 10.15.163.49/32
Known via "bgp 666", distance 200, metric 0
Tag 65505
Number of pic paths 1 , type internal and external
Installed Jan 18 23:06:08.879 for 1d10h
Routing Descriptor Blocks
172.20.98.158, from 172.20.98.158, BGP best-external, BGP backup path
Route metric is 0
66.66.91.156, from 66.66.90.178
Nexthop in Vrf: "default", Table: "default", IPv4 Unicast, Table Id: 0xe0000000
Route metric is 0
No advertising protos.
RP/0/0/CPU0:PE100#

   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.

https://tools.ietf.org/html/rfc4271#section-9.1.2

[Giuseppe Larosa]

Hello @SamuelLewis40515 ,

the RFC refers to BGP version 4 definition and for sure Cisco applies the AS path loop avoidance on address family ipv4 unicast  (the classic BGP ).

Here yoiu are using MP BGP with address family vpnv4 and other vrf specific address families.

In this specific context AS path check is likely disabled by default to allow for some features to work like as-override or remove private as.

For SP it is typical to assign a private AS number to a specific L3 VPN customer and then to use one of the two features as-override or remove private as to make a remote CE to accept a route that otherwise would contain its own AS number.

if you see your AS path is

65505 666 65505

also the appearance of 65505 as peer AS and righmost AS would be a problem.

I realize my answer might be partial but it is all I can say based on my experience.

Hope to help

Giuseppe

[SamuelLewis40515 · Accepted solution]

Hello Giuseppe,

Thanks for the response! I should have mentioned in the post that I also tested in a lab environment (GNS3 admittedly) with the ipv4 unicast family and the same thing occurred. Of course for eBGP Cisco will block its routes inbound unless you configure allowas-in but for iBGP it doesn´t make the check.  

I did in fact get a response from one of the authors of the RFC and his response was that although it is not explicitly said in the document it should be obvious that iBGP shouldn't be making this check:

"The RFC is pretty clear that the AS path should not be modified by IBGP.  If the first hop EBGP speaker has done loop prevention already, then there is nothing to be gained by an IBGP receiver doing the loop prevention step again. "

So basically he agrees with Cisco´s interpretation.

I´m not sure if I am supposed to mention vendor names here but lets just say our other (big) PE vendor agrees with our SD WAN vendor and implements the checks for iBGP also. I think ideally the RFC should be edited to be more specific but it is clearly causing very few problems in real life as nobody else seems to have noticed! 

Thanks,

Sam 

[Giuseppe Larosa]

Hello @SamuelLewis40515 ,

thanks for your feedback.

So it is actually a grey zone in this RFC that allows for interpretation by vendors.

Best Regards

Giuseppe