Configurable placeholder ASN for 4B RS ASN

[johannesmoos]

Configuring a 4 Byte RS ASN will clash with using the rs_as macro in BGP Standard and Extended Communities. Would it make sense to have a configurable macro that will substitute rs_as in case the value of rs_as is > 65535?

Something like rs_as_sub: 65534

Now, when using a 4 Byte RS ASN, rs_as_sub is used instead of rs_as and it will produce BGP (Extended) Communities like 0:65534 (do not announce to any), 65534:64500 (announce to AS64500) and so on. When using a 2B ASN, the current behavior would apply.

[pierky]

Hello @johannesmoos,

thanks for the feedback.

When the ARouteServer configuration policy is initially setup using the configure command, the program actually uses ASN 65534 in place of rs_as to set the communities:

• example of the output of configure:

  
  [...]
  Router server's ASN
  ===================

What's the ASN of the route server? 99999999

Place-holder 16-bit ASN for BGP communities

Since the ASN used for the route server is a 32-bit value, features and services offered to clients using BGP communities will be configured to use a placeholder 16 bit ASN: 65534 ...

- example of a BIRD function used to manipulate announcement, where 65534 is used:

function route_can_be_announced_to(int peer_as; ip client_ip; string client_id) [...]

do_not_announce_to_any

if (0, 65534) ~ bgp_community then
    return false;
if (99999999, 0, 0) ~ bgp_large_community then
    return false;
if (rt, 0, 65534) ~ bgp_ext_community then
    return false;

If I'm understanding that correctly, you are proposing to add a new optional config statement to the general.yml file, like this:

```yaml
cfg:
  # The route server AS number.
  rs_as: 99999999
  rs_as_sub: 65534

and then used that value to expand rs_as in the BGP communities settings when rs_as is a 32bit number. Is that right?

I'll think more about the solution that you're proposing. The configure command already provides an easy way to deal with those cases and to build an initial configuration file that takes the 32bit -> 16bit placeholder mapping into account; the file can then be customised by the operators. Moreover, the entire file can already be edited and crafted manually, so there are already ways to work around the use of a 32bit ASN. I'm not sure about the ratio between benefits (easiness of use of the general.yml file) vs complexity added by it

[johannesmoos]

Hi @pierky, thanks for the fast reply!

I have to admit that I just changed the rs_as macro to a 4B value in the general.yml that has been generated for a 2B RS ASN before and did not run arouteserver configure again.

I now understand that there's already a logic that does exactly what I proposed when detecting a 4B RS ASN. Perfect!

Let me rephrase my proposal: Can we make the placeholder ASN configurable? A prompt in arouteserver configure where 65534 is the default (just press enter) and where I can change the ASN would be perfect.

[pierky]

Hello @johannesmoos,

I've implemented your suggestion. Actually, the code was already there, but commented; I guess I had a similar idea in the past, but then I left it behind and eventually forgot to ship it!

Also the Docker image will be adapted to take an additional environment variable into account, when the route-server's ASN is a 32bit value.

I've also fixed an issue with the way Euro-IX BGP Large Communities for reject reasons were created by configure.

The CI/CD pipeline is now running, if everything goes well a pre-release will be out in about one hour: v1.12.0-alpha4 In case you want to give it a try, please refer to the instructions on https://arouteserver.readthedocs.io/en/latest/INSTALLATION.html#development-and-pre-release-versions on how to install pre-releases from the test instance of PyPi.

Thanks

[pierky]

Sorry, the pre-release will be v1.12.0-alpha5, the alpha4 was broken.

[johannesmoos]

Hi @pierky, great, thank you very much!

[pierky]

Hello @johannesmoos, 1.12.0 is out, it contains the improvement. Thanks for the feedback!