routedbits / dn42-peers Goto Github PK

Look into if it's possible to have a issue template that is a form, then we can intake peering requests via that form right to a GitHub issue.

Additionally, we can either copy/submit responses to the Google form via the GitHub form or deprecate the Google form in favor of the GitHub form

https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#creating-issue-forms

We might be able to have a "form" per peering type, so when user selects New Issue they can then select the appropriate one

Every BGP neighbor must have a unique Link-Local IPv6 address (when using link-local) otherwise it will produce a configuration error:

ValueError: Failed to parse config: Node "bgp neighbor" has two children named "fe80::100"

We should update the documentation to reflect this.

The base automation repository fixes this situation. However the ipv4 or ipv6 key should never be in prefix notation (i.e. 192.168.1.0/24) and always be just an IP address (192.168.1.0).

Note that the key local_ipv6 should accept a prefix notation as that is an override that allows for a different subnet/static route configuration. This may be confusing other users, however the linter can correct for this.

Create a "linting" script to verify proper peer syntax and rules for PR requests.

This script should be triggered when pull requests are open to help verify proper configuration.

When using a DNS name for a peer's endpoint, we end up resolving it to an IP when deploying. We should have a validation that checks if the DNS name provided actually resolves to a valid AAAA (preferred) or A record.

It would be helpful to have a script that asks what router, what type of peering request, then based off that other questions for that type, then finally write it out to the appropriate router file

### New Peering ###
Router: router.gru1

1. Multi-protocol (IPv4/IPv6) with Extended Nexthop Capability 
2. Multi-protocol (IPv4/IPv6)
3. IPv4 and IPv6 in separate sessions
4. IPv4 Only
5. IPv6 Only

Type of peering: 5

Name: PEER-GRU
ASN: 123456
...

It could output the data to the screen too, as well as maybe a email template

We generally send a follow up email after a peering is merged+deployed, this has been copy+paste+modify from previous emails, but it's essentially a template

It would be super useful to have a GitHub actions job for this repo that we can manually run that takes an email (marks it as a secret to not reveal it), renders a template based on the files changes or even if we have to manually specify the routers.

We would need a SMTP service that we can use, ideally for free to send these emails.

https://github.com/marketplace/actions/send-email