Skip to main content
Solved

Kasten on openshift integration with existing Veeam B&R

  • January 21, 2026
  • 4 comments
  • 72 views
K

Hi all,

I’m looking for best practices / guidelines for integrating Kasten K10 with an existing Veeam Backup & Replication (VBR) environment, specifically around network design and traffic flow.

Current Veeam B&R setup (simplified)

VLANs / networks in use

  • MGMT VLAN – control/management traffic

  • iSCSI VLAN

  • Backup Traffic VLAN – L2 only, dedicated NICs

All control-plane communication happens over the MGMT VLAN, while all heavy data movement is isolated to the Backup Traffic VLAN.

Veeam components

  • VBR Server

    • Connected only to MGMT VLAN

  • Proxy Servers

    • Connected to MGMT, iSCSI, and Backup VLANs

    • Integrated with Dell PowerStore via the Veeam plugin

    • Data path: SAN → Proxy → Repository over Backup VLAN

  • Repository Servers

    • Connected to MGMT VLAN and Backup VLAN

Kasten K10 on OpenShift

  • Deployed via the Operator on worker nodes

  • Integrated with multiple storage systems via CSI

  • Configured locations:

    • S3 object storage

    • Existing Veeam B&R repositories

Policy workflow

  • Snapshot at storage level

  • Export to S3 profile

  • Export volume snapshot data to VBR via block mode export

(This works intermittently, but I’ll address that separately.)

The actual problem: traffic flow

When a block export starts:

  • Kasten spins up block export mover pods

  • These pods egress using the worker node egress IP

  • On the firewall, I see traffic attempts to:

    1. The repository’s Backup VLAN IP (not routed → fails)

    2. The repository’s MGMT VLAN IP (works if allowed)

If I allow this traffic over the MGMT VLAN, the export succeeds — but this defeats our network design and is not something we want long-term.

Questions / best-practice guidance

What is the recommended approach here?

  • Should Kasten traffic use:

    • A dedicated egress IP for the Kasten namespace?

  • Is it best practice to:

    • Attach a secondary network interface to the block export mover pods (e.g. via Multus) connected to the Backup VLAN?

  • Or is there another supported / recommended Kasten networking model to ensure block export traffic uses a dedicated backup network instead of MGMT?

Any real-world designs or guidance would be greatly appreciated.

Thanks!

Best answer by liguoqiang

​@kvtomino 

I am also working on a Kasten design that is largely consistent with your architecture and requirements. Regarding the use of dedicated network interfaces for different scenarios, here is my approach:

  1. NFS: In OpenShift, remote NFS is mounted via the Worker Nodes. Therefore, you need to use a NodeNetworkConfigurationPolicy (NNCP) to create a dedicated network and assign IP addresses. This ensures that backup exports follow a direct route via Layer 2.

  2. S3/VBR Repository: This is implemented via NetworkAttachmentDefinition (NAD). First, use an NNCP to create a Bridge, then define the NAD. Finally, configure the Kasten Operator by setting global.podAnnotations (specifically k8s.v1.cni.cncf.io/networks). This provides all Kasten Pods with a second network interface via Multus, allowing backup data to be transmitted through this dedicated path.

To be honest, I haven't found an 'official' best practice either; the above is simply a design based on my understanding of OpenShift and Kasten for your reference.

Additionally, I am very interested in the issue you mentioned—“This works intermittently, but I’ll address that separately.” Could you share more details on what specifically is causing the instability?

    4 comments

    AndrePulia
    Forum|alt.badge.img+9
    • AndrePulia
    • Veeam Vanguard
    • January 21, 2026

    ​@kvtomino I’m not familiar with Kasten yet, but you can check Michael Cade’s blog, https://github.com/MichaelCade you will find a lot of information there. 
    you can also look at the Geoff’s content, recently, he published 15 videos regarding Kasten 

     

    André Pulia - VMCA | VMCE | VMCT |Veeam Vanguard | VUG Leader Brazil | ObjectFirst ACE | HPECI | VCI | Nutanix Certified Instructor | Twitter: @andrepulia | Blog Site – https://pulia.com.br | https://www.credly.com/users/andre-pulia
      L
      • liguoqiang
      • Not a newbie anymore
      • Answer
      • January 25, 2026

      ​@kvtomino 

      I am also working on a Kasten design that is largely consistent with your architecture and requirements. Regarding the use of dedicated network interfaces for different scenarios, here is my approach:

      1. NFS: In OpenShift, remote NFS is mounted via the Worker Nodes. Therefore, you need to use a NodeNetworkConfigurationPolicy (NNCP) to create a dedicated network and assign IP addresses. This ensures that backup exports follow a direct route via Layer 2.

      2. S3/VBR Repository: This is implemented via NetworkAttachmentDefinition (NAD). First, use an NNCP to create a Bridge, then define the NAD. Finally, configure the Kasten Operator by setting global.podAnnotations (specifically k8s.v1.cni.cncf.io/networks). This provides all Kasten Pods with a second network interface via Multus, allowing backup data to be transmitted through this dedicated path.

      To be honest, I haven't found an 'official' best practice either; the above is simply a design based on my understanding of OpenShift and Kasten for your reference.

      Additionally, I am very interested in the issue you mentioned—“This works intermittently, but I’ll address that separately.” Could you share more details on what specifically is causing the instability?

        K
        • kvtomino
        • Author
        • Not a newbie anymore
        • January 26, 2026

        ​@liguoqiang 

        Thank you for your comment! That was indeed what we were thinking of doing as well, but I also asked veeam support for their opinion/supported method. I’ll share it here once I get an answer.

        Regarding the instability, for this we also have a case open with veeam support. It’s been escalated to engineering now. 

        Errors we’re seeing are: Algorithm errors and sometimes unsupported volume type Last one is odd since the volume is certainly supported and it also works sometimes :-). When it fails block-mode-upload-session pods become stale and we need to clean up manually.
         

        Storage classes we use on openshift are Ceph RBD and Powerstore block and block exports go to a immutable linux repo. 

        I’ll share the result of that case here as well.
         

        K
        • kvtomino
        • Author
        • Not a newbie anymore
        • March 11, 2026

        ​@kvtomino 

        I am also working on a Kasten design that is largely consistent with your architecture and requirements. Regarding the use of dedicated network interfaces for different scenarios, here is my approach:

        1. NFS: In OpenShift, remote NFS is mounted via the Worker Nodes. Therefore, you need to use a NodeNetworkConfigurationPolicy (NNCP) to create a dedicated network and assign IP addresses. This ensures that backup exports follow a direct route via Layer 2.

        2. S3/VBR Repository: This is implemented via NetworkAttachmentDefinition (NAD). First, use an NNCP to create a Bridge, then define the NAD. Finally, configure the Kasten Operator by setting global.podAnnotations (specifically k8s.v1.cni.cncf.io/networks). This provides all Kasten Pods with a second network interface via Multus, allowing backup data to be transmitted through this dedicated path.

        To be honest, I haven't found an 'official' best practice either; the above is simply a design based on my understanding of OpenShift and Kasten for your reference.

        Additionally, I am very interested in the issue you mentioned—“This works intermittently, but I’ll address that separately.” Could you share more details on what specifically is causing the instability?

        Small update: 

        Adding backup VLAN via multus increased speed a lot. Only downside is it adds that to all the kasten pods. Support told me they have a feature request open to be able to add it to ephemeral pods only. 

        The problem with writing to VBR is still not solved. Has been a priority 1 ticket for quite a while now :-).
        Problem is only on Linux immutable repository’s, writing to our Datadomain via VBR works fine. The jobs we point to our Immutable repo locks up, and become stale. We had to disable them completely as it was messing with our regular non kasten backups to that repository.

        We also had one other issue of bigger PVC’s failing during backup no matter what repo it was writing to. This was resolved by increasing these timeouts:

         

          timeout:

            blueprintBackup: 360

            workerPodReady: 360


         

          Terms & ConditionsAccessibility statement