Common Customer Network Designs

#1: The most basic network configuration for Rubrik is a standard routeable network. In this scenario Rubrik Bond0 (10GbE / 25GbE) will be on
the same VLAN segment as the ESX hosts as well as other snappables. Or, at the very least the segment Rubrik is on has a fast routeable link
to other workloads. This negates the need for Bond1 or any type of VLAN trunking on Rubrik.

#2: This config is required in certain accounts where there are bottlenecks within the internal networking. Most common case would be
underperforming firewalls or just bad network design where bottlenecks exist for certain VLANs. Another example would be a DMZ with workloads
that are behind a firewall. The solution for this scenario is to trunk the VLAN that contains other workloads to Rubrik. This keeps all backup traffic
on Bond 0 (10GbE / 25GbE). Note that the 1GbE (R3XXX) and 10GbE Base T (R6XXX) Bond 1 ports are still not required. In this scenario it
would be a good idea to verify VMware backup traffic by looking at ESXTOP and verifying which VMKernel interface backup traffic is going down.
If you notice traffic using the wrong VMKernel interface then you can set the traffic to prefer a specific subnet / vlan by calling “ESX_SUBNETS”
within the Admin CLI or API. This scenario might also be used when the customer has database workloads on isolated VLAN’s. This will require
the use of VLAN trunking in order for Rubrik to be able to access the workloads over the appropriate network. Due not that floating IP’s might
also be required and should be created on the appropriate VLAN.

Customer Firewall Sample Config:

Rubrik Solution:
#3: In very rare circumstances a customer might have a physically isolated replication network. This is problematic in the fact that all 10GbE
interfaces on Rubrik need to be on the same network segment. The only way to support this configuration is to use the 1GbE (R3XXX) and
10GbE Base T (R6XXX) Bond 1 interfaces for replication. This can be cumbersome to set up. For this scenario you will need to bootstrap the
cluster with both Bond 1 and Bond 0. This will require IP addresses for each interface. Once the bootstrap is complete the Default Gateway will
live on Bond 1 instead of Bond 0 where we need it. Therefore you will need to enter the admin CLI and initiate the “set_default_gateway”
command to move the Default Gateway back to Bond 0.