# Demystifying Cassandra’s broadcast_address

[Blog](/blog/)&gt;[Technology](/blog/category/technical/)&gt;Demystifying Cassandra’s broadcast\_address 

Demystifying Cassandra’s broadcast\_address
===========================================

October 11, 2016 | By [ Instaclustr ](https://www.instaclustr.com/blog/author/instaclustr/)

 

 

 

 



   [ ](https://x.com/intent/tweet?text=Demystifying%20Cassandra%E2%80%99s%20broadcast_address&url=https://www.instaclustr.com/blog/demystifying-cassandras-broadcast-address/) [ ](https://www.linkedin.com/shareArticle?mini=true&url=https://www.instaclustr.com/blog/demystifying-cassandras-broadcast-address/&title=&summary=Demystifying%20Cassandra%E2%80%99s%20broadcast_address&source=) 

When configuring [Apache Cassandra](/platform/managed-apache-cassandra/) to work in a new environment or with a new application or service we sometimes find ourselves asking *“What’s the difference between broadcast\_address and broadcast\_rpc\_address again?”*.

The difference is **broadcast\_address** relates to **gossip** and **node to node** **communications**, whereas **broadcast\_rpc\_address** is associated with **client connections**. Read on for more details.

The Cassandra configuration file has a few interdependent properties related to communication, which can take a bit of concentration to make sense of. Here is a (hopefully) easy to understand explanation.

Node to node communication (i.e. gossip)
----------------------------------------

Cassandra will bind to the **listen\_address** or **listen\_interface** and listen on the storage\_port or ssl\_storage\_port for gossip. In most cases, these properties may be omitted, resulting in Cassandra binding to the hostname’s IP address (Cassandra uses [InetAddress.getLocalHost()](https://docs.oracle.com/javase/8/docs/api/java/net/InetAddress.html#getLocalHost--)). **Note:** setting listen\_address to “localhost” results in Cassandra binding to the loopback interface (not recommended as it only works as a 1-node cluster).

**broadcast\_address** is reported to nodes for peer discovery. Topologies that span separate networks need this set to a public address. If this property is omitted, the listen\_address will be broadcast to nodes. **Note:** Nodes can be configured to gossip via the local network and use public addresses for nodes outside its local network by setting `prefer_local=true` in *Cassandra-rackdc.properties* and using certain endpoint\_snitches (such as GossipingPropertyFileSnitch or Ec2MultiRegionSnitch).

Client to node communication
----------------------------

#### rpc\_address, rpc\_interface and broadcast\_rpc\_address

By “client” I mean Cassandra drivers and clqsh. The drivers may use the Thrift transport or the Native transport (CQL binary protocol). Cqlsh uses Native transport.

Cassandra will bind to the **rpc\_address** or **rpc\_interface** and listen on rpc\_port and native\_transport\_port for client connections. If these properties are omitted, Cassandra will bind to the hostname’s IP address (and would need to be specified to a locally running cqlsh because `<strong>cqlsh</strong>` = `<strong>cqlsh</strong> <strong><loopback address></strong>`).

**broadcast\_rpc\_address** is a property available in Cassandra 2.1 and above. It is reported to clients during cluster discovery and as cluster metadata. It is useful for clients outside the cluster’s local network. This property is typically either:

- the public address if most clients are outside the cluster’s local network
- the local network address if most clients are in the cluster’s local network

If this property is omitted, rpc\_address will be reported to clients.

**Note 1:** If there are a mix of clients inside and outside the local network, use an AddressTranslator policy to compensate for unreachable addresses (only available for Java and Python drivers at the time of writing. [Here is a Java example](/blog/apache-cassandra-deployed-on-private-and-public-networks/).)

**Note 2:** *rpc\_address* may be set to 0.0.0.0. In this case, Cassandra binds to all available interfaces, including loopback, which is used by cqlsh when no host is specified. But 0.0.0.0 is not routable, so Cassandra will use a different property to determine the address to broadcast to clients:

- for Cassandra 2.1 and later: broadcast\_rpc\_address must be set and will be reported to clients.
- for Cassandra prior to 2.1: broadcast\_address (or listen\_address if omitted) will be reported to clients.

Summary:

Cassandra VersionPurposePropertiesTypical SettingAllgossiplisten\_address or listen\_interface (with storage\_port or ssl\_storage\_port)Omit to bind to InetAddress.getLocalHost()Allpeer discovery (within the cluster)broadcast\_address else listen\_addresspublic addressAllclient requests (CQL and Thrift)rpc\_address or rpc\_interface (with rpc\_port and native\_transport\_port)Omit to bind to InetAddress.getLocalHost()2.1 and latercluster discovery | metadata (to the client)broadcast\_rpc\_address else rpc\_addressOmit to broadcast InetAddress.getLocalHost()2.0 and priorcluster discovery | metadata (to the client)rpc\_address or broadcast\_address if 0.0.0.0Omit to broadcast InetAddress.getLocalHost() 

 [ Add Instaclustr as a preferred source on Google ](https://google.com/preferences/source?q=instaclustr.com)



 

 ![mail icon]()#### Get the latest articles for open sourceIn your inbox

 <a class="btn btn-primary btn-popup text-dark" href="">Sign up now</a> 

 

 

 

  ### Related content

 [ Zero Downtime Migration to Instaclustr 

 

 Yes, we can migrate existing Cassandra clusters to Instaclustr without any downtime. Here's what to expect from the process... 

 

 

 

 

 

 

 ](https://www.instaclustr.com/blog/zero-downtime-migration-to-instaclustr/) 

 [ Workflow Comparison: Uber Cadence vs Netflix Conductor 

 

 When choosing what’s right for your company’s opensource workflow needs it is important to know the difference and similarities ... 

 

 

 

 

 

 

 ](https://www.instaclustr.com/blog/workflow-comparison-uber-cadence-vs-netflix-conductor/) 

 [ Will Your Cassandra Database Project Succeed?: The New Stack 

 

 Open source Apache Cassandra® continues to stand out as an enterprise-proven solution for organizations seeking high availability... 

 

 

 

 

 

 

 ](https://www.instaclustr.com/blog/will-your-cassandra-database-project-succeed-the-new-stack/) 

 

  <a class="close-modal" href="">×</a>Sign upto ourNewsletter
-----------------------
