Frequently asked questions
No, at this time. Triton will manage all of the addresses in your network. It keeps track of what addresses have been assigned, simplifying administration. Triton will allocate an unused address for you when this instance is provisioned.
We strongly suggest using Triton CNS for DNS management and service discovery inside the network.
Every user has a default network and VLAN created for them in each data center. The VLAN is id 2 and the default network is
No, by default existing containers and VMs cannot communicate with containers or VMs on a network fabric, unless either both instances have public IP addresses or some other common network.
You can add a new network interface to an existing container or VM using the CloudAPI NICs endpoint or using
sdc-nics create <network uuid> <instance uuid> (see instructions for installing the
smartdc commands). Support for adding NICs via Triton CLI is forthcoming.
You can create networks from the RFC 1918 address spaces. Specifically, the valid ranges are:
Your networks can be carved out of any valid sub-network from these ranges. For example, the following are all valid networks that can be created:
You can create up to 1024 VLANs.
You can create up to 1024 IPv4 networks.
The smallest IPv4 network you can create is a /28.
The largest IPv4 network you can create is a /8. However, it is limited by the size of the RFC 1918 space that you're using. For example, you cannot create a /8 sized network in
No. We reserve the first four IP addresses and the last IP address in each subnet.
Yes, ipf will continue to work the same.
Yes, iptables will continue to work the same.
Yes, your existing Cloud Firewall rules will still work for containers or VMs that have a network on a fabric.
If your container or VM does not have any public addresses, then other customers will not be able to reach it. If it does have public addresses, then other customers will be able to reach your container or VM, but only on the public address.
At this time there is no support for deploying a router that can route traffic between two different IPv4 networks on your fabric. Instead, make sure each container or VM has an interface on both networks, see [Common Configurations] for examples. In the future we will add better support for routing.
Yes, by default all networks on a fabric are created with an active Internet gateway that allows them to reach the Internet. However, this option can also be disabled on a per-network basis.
A given network and fabric is limited to a given data center. There is no way for the networks in the two data centers to join together by default. In the future, we'll add better support for connecting multiple data centers networking spaces together through the use of VPNs.
No, at this time you cannot attach a VPN to a fabric. We'll be exploring ways to allow for connecting both hardware and software VPNs in the future.
No, you cannot at this time. We're working on eliminating this limitation.
No, IPv6 is not supported at this time.
No, you cannot use DHCP to manage network addresses. Triton manages network addresses and assignments for you to ensure that you duplicate IP addresses cannot get assigned. If you traditionally use DHCP to manage which instances get which specific addresses, then that can instead be accomplished through the facilities that Triton provides.
No, you cannot directly change the IP address of an instance. You have to add a new interface and then remove the existing one.
No, you cannot. If you'd like to resize a network, you must remove all containers and VMs from the network, destroy it, and create a new one.
No, you cannot.
At the moment, reservations cannot made; however, instead the provisionable range can be changed. The ability to reserve IP addresses on a network so they do not get used for provisioning will be added in the future.
Yes, you can specify them as part of creating a network.
Yes. Currently a docker instance will use the default network to control which private network on a fabric it is on.