---
name: containers-ts-lb-tainted-nodes
title: 'Classic clusters: Why does source IP preservation fail when using tainted nodes?'
description: Source IP preservation fails when using tainted nodes in classic clusters, preventing traffic from reaching your app.
last-updated: 2026-05-14
---

> ## Documentation Index
> The table of contents for this documentation set is at https://cloud.ibm.com/docs/containers?format=markdown
> The index for all IBM Cloud docs is at: https://cloud.ibm.com/docs/llms.txt
> Use these files to discover more information as needed.

# Classic clusters: Why does source IP preservation fail when using tainted nodes?
{: #cs_source_ip_fails_lb}
{: support}

[Classic infrastructure]{: tag-classic-inf}

Source IP preservation fails when using tainted nodes in classic clusters, preventing traffic from reaching your app.
{: shortdesc}

In a classic cluster, you enabled source IP preservation for a [version 1.0 load balancer](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer&format=markdown#lb_source_ip) service by changing `externalTrafficPolicy` to `Local` in the service's configuration file. However, no traffic reaches the back-end service for your app.
{: tsSymptoms}


When you enable source IP preservation for load balancer services, the source IP address of the client request is preserved.
{: tsCauses}

The service forwards traffic to app pods on the same worker node only to ensure that the request packet's IP address isn't changed. Typically, load balancer service pods are deployed to the same worker nodes that the app pods are deployed to. However, some situations exist where the service pods and app pods might not be scheduled onto the same worker node. If you use [Kubernetes taints](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/){: external} on worker nodes, any pods that don't have a taint toleration are prevented from running on the tainted worker nodes. Source IP preservation might not be working based on the type of taint you used:

* **Edge node taints**: You [added the `dedicated=edge` label](https://cloud.ibm.com/docs/containers?topic=containers-edge&format=markdown#edge) to two or more worker nodes on each public VLAN in your cluster to ensure that load balancer pods deploy to those worker nodes only. Then, you also [tainted those edge nodes](https://cloud.ibm.com/docs/containers?topic=containers-edge-workload-prevent&format=markdown) to prevent any other workloads from running on edge nodes. However, you didn't add an edge node affinity rule and toleration to your app deployment. Your app pods can't be scheduled on the same tainted nodes as the service pods, and no traffic reaches the back-end service for your app.

* **Custom taints**: You used custom taints on several nodes so that only app pods with that taint toleration can deploy to those nodes. You added affinity rules and tolerations to the deployments of your app and load balancer service so that their pods deploy to only those nodes. However, `ibm-cloud-provider-ip` `keepalived` pods that are automatically created in the `ibm-system` namespace ensure that the load balancer and the app pods are always scheduled onto the same worker node. These `keepalived` pods don't have the tolerations for the custom taints that you used. They can't be scheduled on the same tainted nodes that your app pods are running on, and no traffic reaches the back-end service for your app.

Resolve the issue by choosing one of the following options:
{: tsResolve}

**Edge node taints**: To ensure that your load balancer and app pods deploy to tainted edge nodes, [add edge node affinity rules and tolerations to your app deployment](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer&format=markdown#lb_edge_nodes). Load balancer pods have these affinity rules and tolerations by default.

**Custom taints**: Remove custom taints that the `keepalived` pods don't have tolerations for. Instead, you can [label worker nodes as edge nodes, and then taint those edge nodes](https://cloud.ibm.com/docs/containers?topic=containers-edge&format=markdown).

If you complete one of the previous options but the `keepalived` pods are still not scheduled, you can get more information about the `keepalived` pods:

1. Get the `keepalived` pods.
    ```sh
    kubectl get pods -n ibm-system
    ```
    {: pre}

2. In the output, look for `ibm-cloud-provider-ip` pods that have a **Status** of `Pending`. Example:
    ```sh
    ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-7zv9t     0/1       Pending   0          2m        <none>          <none>
    ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-8ptvg     0/1       Pending   0          2m        <none>          <none>
    ```
    {: screen}

3. Describe each `keepalived` pod and look for the **Events** section. Address any error or warning messages that are listed.
    ```sh
    kubectl describe pod ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-7zv9t -n ibm-system
    ```
    {: pre}

4. After resolving the issue, verify that traffic is reaching your app by checking the load balancer service endpoints.

    ```sh
    kubectl get svc -o wide
    ```
    {: pre}