Roller NetworkAlmost 9 years ago we set up some publicly accessible IPv6 time servers. At the time there were few to no options for NTP over IPv6.
However, it’s time to retire those servers. They’ve run faithfully for almost 10 years and their watch is over. We won’t offer a replacement for this service, but NIST has IPv6 NTP servers in their pool: https://tf.nist.gov/tf-cgi/servers.cgi
The IP addresses of our mail forwarding servers will be changing:
mxfwd1.rollernet.us
mxfwd2.rollernet.us
If you have created whitelists or used these servers in SPF records (we will update include:m._spf.rollernet.us accordingly) please make sure to add the new addresses alongside the old addresses while this transition is in progress. Once completed, the old IP addresses will no longer be used for any mail-related functions.
CNAME records will be added pointing the legacy names to the new names, so it will be safe to continue referencing the old names.
If you are not using the Mail Forwarding functions in the account control center you will not be affected by this change. Log in to your account and see https://acc.rollernet.us/mail/mapping.php to check if you have mail forwarding configured.
The physical servers are being retired and their mail-related functions replaced with virtual machines. We’ll be repurposing the subnet for timing services since the forwarding servers were also used for NTP (ntp.rollernet.us) and installing Rubidium-based timing systems. This will ensure that functions that are more DNS friendly SMTP functions will transition smoothly, and NTP configurations which are normally configured by IP or only resolved in DNS once will continue with no impact.
UPDATE: All changes were completed successfully.
Roller Network AS11170 will be updating our routing policy to reject any IPv4 or IPv6 prefix with a BGP RPKI validation result of “invalid” on both the peering and transit borders of our network. We’ve been running RPKI validation internally for a while with the “bgp bestpath prefix-validate allow-invalid” setting configured. This routing policy change will simply remove this line from our BGP address family configurations.
We’re changing the behavior of the whitelist for the “All Filters” entry type to now include the Antivirus filter when whitelisting.
The original behavior for the last decade or so has been to continue applying the antivirus filter while whitelisting everything else unless a second whitelist entry was added explicitly for the antivirus filter. Lately we’ve spent too much time explaining this, so we’ve decided the time has come to change the behavior so that an “All Filters” whitelist entry now truly means all filters (including antivirus).
With the activation of the Hurricane Electric POP in Reno, NV the time has finally come to turn down our transit connection to AS20115 Charter/Spectrum. We’ve given our required 30 day termination notice to Charter/Spectrum effective today, April 9, for a end of service date of May 10, 2019.
In the meantime, our routing policy for AS20115 will change to that of a local peering type connection for data collection purposes. We’re curious how much utilization we will see if we restrict it for its last month. Incoming announcements from AS20115 will be filtered with an as-path-access-list of “permit ^20115$” and outgoing announcements will be tagged with community 20115:666 (Do not advertise outside of Charter AS). We will also move the physical connection away from the border router where our policy is one provider per router – a role now assigned to Hurricane Electric on that router – and over to our core peering router. With these filters we only expect to see about 2700 IPv4 prefixes. Charter’s IPv6 BGP session is broken again, but it’s not worth the fight to fix it so this exercise will be IPv4 only.
While we would like to maintain a regional peering connection with Charter/Spectrum, our previous account reps were not able to understand our needs (and our customer’s needs) to successfully negotiate a renewal for interconnection and peering over simply “buying internet”, the latter of which is no longer interesting to us as a colocation datacenter operator.
UPDATE: Effective 4/10/2019, AS20115 has been moved to our core peering router where it will remain until it’s shut down for good.
UPDATE 2: As soon as our Any2 peering port is ready we will remove our connection to Charter/Spectrum. (5/7/2019)
UPDATE 3: Shut down BGP to AS20115. (5/8/2019)
UPDATE 4: Our port to AS20115 Charter/Spectrum is now unplugged and cross connects removed: disconnect complete. (5/8/2019)