You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Whois
RDAP
Parsing the delegated-extended file of each RIR
The text was updated successfully, but these errors were encountered:
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:
The text was updated successfully, but these errors were encountered: