Category: Network

Post dealing with changes to how we route packets and configure our network.

Working to restore connectivity!

There were some upstream issues that resulted in us loosing power a few times. Our team will be checking disk images and slowly getting connectivity back online, please have a bit of patience with us while we work on this.

–updates–

Core and Catos routers were restored from local images and should be alive again, we are still working on Ikus to see if it was damaged or not.

Ikus and CX were also damaged, Ikus has been restored from local. CX might need to be rolled back.

IPv6 Edge router is fine and is working as should. Web, email, NMS and Minecraft all seem to be okay as well.

Accounting completed for August through September

I finished up accounting for the past month this morning and sent off emails to our project members and end users. If you have any questions about your usage, please feel free to reach out to us at our support desk.

Accounting is automated within our NMS but email creation is a manual task performed by our volunteers when they have time to do so. As a result, email timing may vary between months and may done in batches around the 28th. Also, for the past month, not a single member got close to the 600GB de-priority threshold and we had very moderate network use. Another little tid bit, yes…our NMS calls the accounting functions “bills” but MFN/FurrIX does not charge for network access.

More PTR support work!

Reached out to our data center about pointing the reverse zone for our main /48 to our name servers and they approved it. As of today, we are in control of the reverse zone meaning that we can now set records for our project members and end users.

We have also changed the way we set records for our members and users:

  • For all members, when you are given access to a subnet from our project, your subnet will receive a PTR record on the ::0 address in the format <subnet-id>.<member-nickname>.<city>.<state/province>.<country>.<router>.furrix.zone. For example: ‘sub40-64.foxxo.jacksv.fl.us.ikus.furrix.zone’ would show that you have access to the subnet ‘2604:4300:f03:40::/64’ and you are based out Jacksonville, Florida.
  • For our members who are sharing their access with another member, the suffix for PTR records will always be <device>.<shared-to-nickname>.<shared-from-nickname>.<city>.<state/province>.<country>.<router>.furrix.zone. For example: ‘slate.smol-dwagon.ty-dwagon.longv.tx.us.catos.furrix.zone’ would show that you are allowing another member to make use of your subnet, possibly for in network routing.
  • Members are allowed to supply our network engineers with their own PTR prefixes, given that the chosen prefix makes sense and is not derogatory or otherwise. Device names, floor locations, etc are permitted. Be aware that PTR records are globally viewable.

A better example of the use of PTR records within our project is the record for ‘2604:4300:f03::’ which returns the following data: ’30f.0034.4062.kc.mo.us.furrix.zone’ – ’30f.0034.4062′ is our IPv6 prefix entered backwards which identifies our network. – ‘kc.mo.us’ stands for Kansas City, MO, US which identifies where our network core is operated out of – ‘furrix.zone’ identifies our project as the network operator.

As you can see, having support for this is a massive help to our volunteers when needing to check who is responsible for traffic on our network or for when project members or end users have a protocol or software stack that requires a record is set in order to function properly.