Skip to main content
Solved

Kasten on openshift integration with existing Veeam B&R

  • January 21, 2026
  • 3 comments
  • 29 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?

    3 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.
         

        Terms & ConditionsAccessibility statement