skip to content

Explain the difference between listeners and advertised.listeners, and the role of listener.security.protocol.map.

level: middleimportance: must knowfreq 65%

answer

  1. listeners = bind (0.0.0.0)
  2. advertised = publish (reachable)
  3. name -> protocol map
  4. INTERNAL/EXTERNAL split
  5. inter.broker.listener.name

basics

~20 s

listeners is where the broker binds and accepts connections. advertised.listeners is the address it publishes in metadata for clients to connect back. listener.security.protocol.map maps each named listener to a security protocol (PLAINTEXT, SSL, SASL_SSL, etc.).

solid answer

~40 s

A broker can expose several network endpoints. listeners defines the sockets the broker actually binds locally (name://host:port), often binding 0.0.0.0 to accept on all interfaces. advertised.listeners is what the broker registers in cluster metadata and returns to clients in Metadata responses, so it must be an address clients can actually reach (a real hostname/IP, not 0.0.0.0). They differ whenever the bind address differs from the reachable address: containers, NAT, load balancers, multi-network setups. Each listener has a name; listener.security.protocol.map maps that name to a security protocol like PLAINTEXT, SSL, SASL_PLAINTEXT, or SASL_SSL. This lets you run, e.g., an INTERNAL listener as PLAINTEXT for inter-broker traffic and an EXTERNAL listener as SASL_SSL for clients. inter.broker.listener.name selects which listener brokers use to talk to each other.

go deeper

for a junior

Know listeners = where it binds, advertised = what clients use.

for a middle

Explain the protocol map and the internal/external listener pattern.

for a senior

Design multi-listener TLS/SASL topologies and inter.broker.listener.name selection.

for a principal

Architect connectivity across networks/clouds with security boundaries and debug subtle handshake/advertise failures.

## Why multiple listeners exist A broker often must be reachable on different networks with different security: e.g. fast plaintext between brokers inside a private network, and authenticated TLS for external clients. Kafka models this as multiple named **listeners**. ## listeners `listeners` is a comma-separated list of endpoints the broker **binds** locally, each formatted `LISTENER_NAME://host:port`, e.g. `INTERNAL://0.0.0.0:9092,EXTERNAL://0.0.0.0:9093`. Binding to `0.0.0.0` means "accept on every network interface." This config is about the *server socket*, not about how clients address the broker. ## advertised.listeners Clients never connect to `0.0.0.0`. `advertised.listeners` is the list the broker **publishes** into metadata and returns in Metadata responses, e.g. `INTERNAL://broker1.internal:9092,EXTERNAL://kafka.example.com:9093`. These must be addresses the respective clients can resolve and reach. If omitted, it defaults to `listeners`, which breaks the moment the bind address isn't routable (containers, NAT). The number-one connectivity bug is bootstrapping fine but failing on the data path because advertised addresses are wrong. ## listener.security.protocol.map A listener name like `INTERNAL` or `EXTERNAL` is just a label; Kafka must know what *security protocol* runs on it. `listener.security.protocol.map` maps name -> protocol, e.g. `INTERNAL:PLAINTEXT,EXTERNAL:SASL_SSL`. The four base protocols: - **PLAINTEXT** — no auth, no encryption. - **SSL** — TLS encryption (+ optional mutual TLS auth). - **SASL_PLAINTEXT** — SASL auth, no encryption. - **SASL_SSL** — SASL auth over TLS. For well-known names (PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL used directly as listener names) the mapping is implicit; for custom names you must define it explicitly. ## Tying it together - **inter.broker.listener.name** selects which named listener brokers use among themselves (e.g. `INTERNAL`). - A listener's port, bind interface, advertised address, and security protocol are configured independently, enabling internal-plaintext + external-TLS topologies. ## Edge cases - advertised host using a non-resolvable internal name -> external clients fail after a successful bootstrap. - Mismatched protocol map vs client security settings -> handshake failures that look like network errors. - Same port reused across listeners -> bind conflict.

  • Why should advertised.listeners not contain 0.0.0.0?
    Clients receive that address from metadata and try to connect to it; 0.0.0.0 is a bind wildcard, not a routable destination, so connections fail.
  • How do you make inter-broker traffic plaintext but client traffic TLS?
    Define two named listeners (e.g. INTERNAL/EXTERNAL), map them in listener.security.protocol.map (PLAINTEXT/SASL_SSL), and set inter.broker.listener.name=INTERNAL.

saying these in an interview costs you the question

  • Saying listeners and advertised.listeners are interchangeable
  • Putting 0.0.0.0 in advertised.listeners
  • Thinking the listener name itself implies a security protocol for custom names
  • Claiming a broker can only have one listener

context

resolving links…