🚨 Kafka Error Guide: 'BrokerEndPointNotAvailableException' Missing Listener

Exact Error Message

This exception is thrown when a broker has no endpoint advertised for the listener or security protocol a client (or another broker) is trying to use:

[2026-06-29 08:21:54,610] ERROR [Broker id=2] Error processing fetch request from replica (kafka.server.ReplicaManager)
org.apache.kafka.common.errors.BrokerEndPointNotAvailableException: End point with listener name SASL_SSL not found for broker 2

It also appears in metadata handling and inter-broker contexts with variations on the listener name:

org.apache.kafka.common.errors.BrokerEndPointNotAvailableException:
  Broker does not have a listener with name INTERNAL, but the client uses listener name INTERNAL
[2026-06-29 08:21:55,002] ERROR [KafkaApi-2] Error when handling request: listenerName=INTERNAL (kafka.server.KafkaApis)

What the Error Means

Each Kafka broker exposes one or more listeners, each tied to a name and a security protocol (for example PLAINTEXT, INTERNAL://SSL, EXTERNAL://SASL_SSL). When a client or peer broker requests the endpoint for a given listener name and the broker has no matching advertised endpoint, it raises BrokerEndPointNotAvailableException.

In short: the listener the requester asked for is not defined, not advertised, or not mapped to a security protocol on that broker. Unlike a down-broker error, the broker is up and responding — it simply cannot give back a usable endpoint for the requested listener name.

This is fundamentally a configuration error rooted in listeners, advertised.listeners, listener.security.protocol.map, and inter.broker.listener.name. It commonly surfaces when introducing multiple listeners (internal vs external), enabling TLS/SASL on a new listener, or when one broker’s listener config drifts from the rest of the cluster.

Common Causes

• Listener name not defined in listeners / advertised.listeners, but referenced by a client or by inter.broker.listener.name.
• Missing entry in listener.security.protocol.map for a named listener, so its security protocol is unknown.
• advertised.listeners omits a listener that exists in listeners, so no endpoint is published for it.
• Inconsistent config across brokers — one broker lacks a listener the rest advertise, breaking inter-broker requests.
• Client requests a listener name (or security protocol) the broker never exposes.
• Typo or case mismatch between the listener name in client config and the broker’s listener definition.
• New security protocol added to clients before the corresponding broker listener was configured.

How to Reproduce the Error

Configure a client to request a listener/security protocol the broker does not expose:

# Inspect the broker's configured listeners
grep -iE 'listeners=|advertised.listeners|listener.security.protocol.map|inter.broker.listener.name' /opt/kafka/config/server.properties
# A client set to security.protocol=SASL_SSL connecting to a broker that only
# advertises a PLAINTEXT listener will surface BrokerEndPointNotAvailableException.

Equivalently, set inter.broker.listener.name=INTERNAL on one broker while another broker in the cluster never defines an INTERNAL listener; inter-broker fetches against that broker fail with this exception.

Diagnostic Commands

Inspect the broker’s listener configuration directly:

grep -iE 'listeners=|advertised.listeners|listener.security.protocol.map|inter.broker.listener.name|control.plane.listener.name' /opt/kafka/config/server.properties
ss -ltnp | grep -E ':9092|:9093|:9094'

Check which security protocols a broker actually offers and confirm reachability:

kafka-broker-api-versions.sh --bootstrap-server kafka-1:9092
kafka-broker-api-versions.sh --command-config /opt/kafka/config/client-ssl.properties --bootstrap-server kafka-1:9093

Look at broker logs and cluster metadata for the listener mismatch:

sudo journalctl -u kafka --since "15 min ago" | grep -iE 'listener|endpoint|BrokerEndPoint|security.protocol'
kafka-metadata-quorum.sh --bootstrap-server kafka-1:9092 describe --status

Step-by-Step Resolution

1. Identify the requested listener name. The exception names it (e.g. listener name SASL_SSL not found or listener with name INTERNAL). That is the endpoint the requester expected.
2. Inspect the broker’s listeners. grep listeners /opt/kafka/config/server.properties. Confirm whether that listener name exists in both listeners and advertised.listeners.
3. Check the security protocol map. Every named listener must have an entry in listener.security.protocol.map (for example INTERNAL:SSL,EXTERNAL:SASL_SSL). A missing entry produces this error.
4. Reconcile across all brokers. Every broker must define the listener used for inter-broker traffic (inter.broker.listener.name). Compare configs cluster-wide and fix the broker that drifted.
5. Align the client. If the client requests a protocol the broker does not offer, either point the client at a listener the broker exposes or add the required listener to the brokers.
6. Apply config and restart the affected broker(s) so the new/corrected listener is advertised. Listener changes require a restart to take effect.
7. Verify. Run kafka-broker-api-versions.sh against each listener port with the matching client config; a clean response confirms the endpoint is now advertised and reachable.

Prevention and Best Practices

• Keep listener configuration identical and version-controlled across all brokers — most occurrences come from one broker’s config drifting from the rest.
• Always pair each listener name with a listener.security.protocol.map entry and a matching advertised.listeners entry; treat the three settings as a unit.
• When adding a new security protocol (e.g. enabling SASL_SSL), roll the broker listener out first, then switch clients — never the reverse.
• Document the listener topology (internal vs external names, ports, protocols) so client teams request the right listener name.
• Validate broker config in CI before deploy to catch undefined listener names and missing protocol-map entries.
• After any listener change, smoke-test each listener with kafka-broker-api-versions.sh from the relevant network. More patterns are in the Kafka guides.

Related Errors

• Connection ... could not be established. Broker may not be available — a transport failure, versus this configuration-level missing-endpoint error.
• NoBrokersAvailable — client-side failure that often stems from a security-protocol mismatch like the one behind this exception.
• SaslAuthenticationException — authentication fails on a listener that does exist, a later stage than this error.
• SSLHandshakeException — TLS negotiation fails on an SSL listener that is correctly advertised.

Frequently Asked Questions

What does “listener name X not found for broker N” mean? Broker N has no advertised endpoint for listener name X. Either X is not defined in that broker’s listeners/advertised.listeners, or it lacks a listener.security.protocol.map entry.

Why did this start after enabling TLS/SASL? You likely switched clients (or inter.broker.listener.name) to the new security protocol before defining the corresponding listener on every broker. Add the listener to the brokers first.

Is the broker down when I see this? No. The broker is up and responding — it just cannot return an endpoint for the requested listener name. It is a configuration mismatch, not a connectivity outage.

Why does only one broker throw it? Almost always config drift: that broker’s listener configuration differs from the rest of the cluster. Reconcile its server.properties with the others.

Do listener changes need a restart? Yes. Changes to listeners, advertised.listeners, and the protocol map are applied at startup, so the affected broker must be restarted for the new endpoints to be advertised.