Roller NetworkFirst there was J Root and now Reno is home to three: J, K and L Roots.
Access to the J, K, and L Roots are available through peering at TahoeIX and automatically to Roller Network customers since Rollernet already peers. TahoeIX also has prefixes for E root thanks to PCH, although it’s not indicated on the map. J Root should be turning up IPv6 soon, too.
At approximately 11:51 local time we were alerted to degraded performance on paths preferring transit through Charter AS20115. We collected data to open a ticket and attempted to apply a BGP community to lower localpref and move traffic away from AS20115. Oddly, we noticed, the alerts continued and no change was observed.
After attempting to tag a BGP community to lower localpref on announcements to AS20115 we decided to simply shut down the BGP neighbor completely at 11:59. However, we were horrified to discover that even after shutting down the BGP neighbor – effectively withdrawing all routes – Charter continued to announce ours and customer prefixes from AS20115.
The original problem we wanted to work around turns out to be a malfunctioning attenuator in a link bundle somewhere upstream, but this behavior of continuing to announce prefixes after we have withdrawn them or shutdown the BGP neighbor is a catastrophic loss of control over the network announcements from our autonomous system. We did employ what we like to call “stupid routing tricks” like deaggragation in a last ditch effort to drive traffic away from AS20115. However this could not help customer prefixes that were already at the minimum accepted size.
At this time there is no resolution. We’re simply at a loss in stopping Charter’s prefix hijacking other than to wait for them to address it.
UPDATE: The prefixes appear to have finally withdrawn this morning. We will post a complete update later, it’s been a long night.
UPDATE 2: Charter had a second emergency maintenance last night on the same equipment. We haven’t reestablished BGP with AS20115 yet.
UPDATE 3: We’re told that an IOS upgrade was performed on the device that hijacked the prefixes. On the morning of the 29th the affected device was rebooted at approximately 02:30 local time. We were told this solved our problem and our ticket was closed. However, we delayed reestablishing BGP until we could confirm a fix as a reboot would only clear the immediate problem, not fix the underlying issue. a second emergency maintenance occurred the next morning on the 30th with two observed reboots at 05:23 and again at 06:01. We’re told these were due to an IOS upgrade (through two independent sources) that should provide a fix for the bug. We did not reestablish BGP with AS20115 until October 1 at 17:45 local time. The time between our withdraw of prefixes and Charter’s propagation of our withdraw was approximately 14.5 hours. As far as we are aware no traffic was completely lost but was still affected by ~25% packet loss, which initiated our initial desire to withdraw routes.
This information is provided in an effort to maintain transparency in network operations at Roller Network.
On 24 September 2015, ARIN issued the final IPv4 addresses in its free pool. ARIN will continue to process and approve requests for IPv4 address blocks. Those approved requests may be fulfilled via the Wait List for Unmet IPv4 Requests, or through the IPv4 Transfer Market.
Read more at: https://www.arin.net/announcements/2015/20150924.html
We’re currently testing out the Cloudmark Authority system on our mail servers to see how it performs with our system. The fastest way to do this was by using their SpamAssassin plugin under the new rule “CMAE_1” in our SpamAssassin configuration.
If you have issues with scoring you can change the score for CMAE_1 (default is 10) in the SpamAssassin preferences. If you have issues with false positives or spam that wasn’t caught please send us a copy of the X-Spam-CMAE-Analysis header.
UPDATE: The CMAE_1 rule has been disabled. We never received pricing from Cloudmark to continue post-trial and we have other projects that need attention at the moment. We may revisit this in the future.
This has long been on the feature request list: attachment types. We’ve implemented some code to start this off with checking a static list of attachment extensions to reject. In addition to this list we’ll also be rejecting double extensions (like .exe.zip) and extensions with non-alphanumeric characters. Right now we’ve just deployed this as logging only to observe the results before switching on the rejecting portion of the code.
The rejected list of extensions will be:
chm, ade, adp, app, asp, bas, bat, cab, cer, chm, cmd, com, cpl, crt, csh, der, exe, fxp, gadget, hlp, hta, inf, ins, isp, its, js, jse, ksh, lib, lnk, mad, maf, mag, mam, maq, mar, mas, mat, mau, mav, maw, mda, mdb, mde, mdt, mdw, mdz, msc, msh, msh1, msh2, mshxml, msh1xml, msh2xml, msi, msp, mst, ops, pcd, pif, plg, prf, prg, pst, reg, scf, scr, sct, shb, shs, sys, ps1, ps1xml, ps2, ps2xml, psc1, psc2, tmp, url, vb, vbe, vbs, vsmacros, vsw, vxd, ws, wsc, wsf, wsh, xnk
In the future we will expand this in the account control center by allowing this feature to be disabled, add custom extensions to the list, and an inverse option of reject all extensions except a list of approved ones (as defined by the user). For now, contact support to request deactivation of this feature if you don’t want it applied to your domains.
UPDATE: Attachment extension name blocking is now live.
UPDATE July 7, 2016: We’ve added “docm”, “xlsm”, and “pptm” to the list.