I know that the ARouteServer project also includes the possibility of generating configurations for Route-Servers that establish sessions with Peers using private ASNs. But I guess the vast majority of cases are for Peers with Public and ACTIVE ASNs.
In a first analysis, it makes sense that the verification of whether the ASN exists or not is done in the acceptance of the Peer as a participant in the IXP.
But today, it is common for some ASNs that were delegated in the past to be excluded in their RIR/NIR/LIR.
(Ex.: An ISP has purchased the operation of another ISP.)
I observed some cases of some ASNs that no longer existed in the respective RIR/NIR/LIR bases, were still configured in the Route-Serves, and with the BGP session ACTIVE.
My suggestion is to add an option that defines whether ARouteServer will check through some method whether or not the ASN is still allocated by the respective RIR/NIR/LIR.
The possibilities I imagine are possible for these methods are:
I know that the ARouteServer project also includes the possibility of generating configurations for Route-Servers that establish sessions with Peers using private ASNs. But I guess the vast majority of cases are for Peers with Public and ACTIVE ASNs.
In a first analysis, it makes sense that the verification of whether the ASN exists or not is done in the acceptance of the Peer as a participant in the IXP.
But today, it is common for some ASNs that were delegated in the past to be excluded in their RIR/NIR/LIR. (Ex.: An ISP has purchased the operation of another ISP.)
I observed some cases of some ASNs that no longer existed in the respective RIR/NIR/LIR bases, were still configured in the Route-Serves, and with the BGP session ACTIVE.
My suggestion is to add an option that defines whether ARouteServer will check through some method whether or not the ASN is still allocated by the respective RIR/NIR/LIR.
The possibilities I imagine are possible for these methods are: