There are a few instances where the storage_port setting might commonly need to be changed. You might be trying to run multiple Cassandra instances or configurations on one server, and that server could only have one IP address. In this case, each Cassandra node will need to use its own storage_port. Network configurations can also require different storage_port settings. For example, firewall restrictions, port forwarding at upstream routers, and even network address translation issues all have the possibility of requiring different port settings. Finally, there may be a conflict on port 7000. Perhaps some other application or service needs to use that port.

If you need to change the storage_port setting for one of your Cassandra nodes, you will need to change the storage_port setting for all of the nodes in that ring. If you have multiple rings across different data centers, then you will need to set up some kind of port-forwarding solution at the firewall or router level if those data centers use different storage_port settings. You will need to check with your firewall or router documentation to learn how to configure port forwarding. There are many variations across vendors and models.

Prior to Cassandra 4.0, which was released in July 2021, inter-node communication would use two different ports. One was the standard storage_port, which defaulted to 7000. This was used for legacy unencrypted communication. The other was ssl_storage_port, which defaulted to 7001 and was used for legacy encrypted inter-node communication. However, as of version 4.0, both encrypted and unencrypted communications are allowed on storage_port. This means you no longer have to specify two separate ports in your configuration file. If this looks like something significant that is changing in your Cassandra configuration, make sure to check the server_encryption_options section of your cassandra.yaml file to ensure that enable_legacy_ssl_storage_port is set to false.

Cassandra relies on its masterless architecture to enable each node in a ring to provide the exact same functionality. This requires every node to have information about the entire database, even though it may only store data associated with the tokens in its partition. Cassandra nodes disseminate database information to each other using a peer-to-peer communication protocol called gossip The gossip protocol broadcasts data over the storage_port, which is why correctly configuring this setting is essential to getting your Cassandra ring operating properly. This protocol is used for peer discovery as well as for propagating metadata.

Get up and running quickly with our quickstart guide!