Hello Alfredo,
I believe you are trying to force local-as to do something it was not intended to do: You are trying to make R1 appears as an iBGP neighbor of R2. This won't work.
R1 knows that R2 is an eBGP neighbor because R1 is in AS 65500 while R2 is in AS 200. The local-as is not going to change it; it only makes R1 to claim ASN 200 when opening a BGP session with R2, and to add this ASN to the AS_PATH when exchanging paths with R2; however, to R1, R2 is still an external neighbor.
R2, on the other hand, believes that R1 is an iBGP neighbor, because in R2's configuration, both R2 and R1 are the part of ASN 200. That changes the way R2 advertises routes to R1, and among other things, it causes R2 not to change the AS_PATH attribute when advertising paths to R1 because in an iBGP peering, AS_PATH should not be modified. For routes originated from AS 200, this means that they will have an empty AS_PATH.
R1 is therefore receiving routes with an empty AS_PATH attribute from R2, and that is what it complains about; surely, routes received through an eBGP peering cannot have an empty AS_PATH.
Unfortunately, I do not believe there is any quick solution to this. From R2's perspective, R1 is an iBGP neighbor. This influences multiple attributes; for example, when R2 advertises networks to R1, neither AS_PATH nor NEXT_HOP will be modified. I am not sure whether you can modify AS_PATH of routes advertised over iBGP; my experience has been that this cannot be done, but even if it worked, there are multiple attributes that behave differently for iBGP and eBGP, and you would need to take care of all of them to properly implement eBGP-like treatment of R1 by R2.
Properly, local-as should be used between eBGP neighbors so that even with the local AS, the neighbors still treat each other as eBGP. In your case, this is not true: R1 treats R2 as eBGP, but R2 treats R1 as iBGP.
Are you sure that you want R1 to make appear as an internal neighbor to R2?
Best regards,
Peter
