ixCtl can manage the route server containers and provide tools for queries, status updates and reconfiguration using ixCtl’s route server config utility.

When you first sign up your IX for ixCtl you can pull in all needed data with a one time automatic import of the “Peers at this Exchange Point” list of connected networks from PeeringDB. Just search for your IX within the ixCtl dashboard and then click ‘import.’ It’s that easy to get started.

ixCtl integrates with PeeringDB for both user authentication, and of course connected network information as well. ixCtl imports PeeringDB data to drive automatic configurations. All data imported from PeeringDB can be overridden by admins or users as needed. You can also authenticate users with PeeringDB, and if you want, incorporate its user permissions for each connected AS. Specific permission levels not supported in PeeringDB can be assigned within ixCtl as needed.

In order to create secure route server configurations, ixCtl allows you to configure MAC addresses and MD5 hashes for each connected network. These values are then used when the route server configuration is built and deployed. Any change in the ixCtl source of truth leads to an update of the route server configuration.

ixCtl is designed to be the ultimate source of truth for your Internet Exchange. Your dgys of searching through spreadsheets, emails, and chat messages are over! This single source of truth is a great foundation for additional automation efforts. And the FullCtl team is here to help you build the perfect automation and orchestration system for your IX.

ixCtl allows you to export data as an IX-F connected networks list schema. This export can be published publicly or password protected. This creates an excellent source of truth for PeeringDB, which requires this format but doesn’t provide tools to create it. Some early adopters have used ixCtl for this one feature alone.

Allows the synchronization of NetBox and/or Nautobot data to ixCtl as well as to send updates to NetBox/Nautobot. You can set up devices in NetBox or Nautobot, which are then pulled into ixCtl for use in traffic graphing, etc. You can also pull “Facilities” (locations / PoPs) from PeeringDB and push them into NetBox/Nautobot, providing live updates from PDB.

Not only is the API (Application Programming Interface) a first class citizen, it’s the only citizen - the web interface is 100% API driven. Our API allows any external system to interact with any individual component in our system which helps customers easily automate their workflow.

All FullCtl products come with audit logging and role based access control (RBAC) out of the box. Anytime someone makes a change to the system, others from that company can identify who made the change and how the system was impacted. The system can auto-populate ixCtl groups and give IX operators assigning privileges to streamline the admin process. The system can also import existing restrictions such as read-only users.

The FullCtl suite of tools are fully modular. Use as much as or as little as you want. Do you have an internal system that owns customer data? We can integrate with that. Have a homegrown provisioning system that needs to be called on changes? Yep, check. Components are designed to be run as a microservice in a container or VM orchestration platform of your choice. We currently have production services running on Kubernetes and in VMs. We're also happy to host it and/or operate it for you.

Gives the ability to gracefully shutdown, restart, and/or update the version of Bird in use; all with a single click.

Allows connected networks to login and configure their own peering sessions on the IX, saving time by eliminating the need to contact the IX and request changes. No more waiting for human responses or manual updates. The client portal will also include per-network traffic charts, network-to-network traffic charts (s-flow), and the ability to update payment information and pay invoices.