#Changing MTU values

1 messages · Page 1 of 1 (latest)

thin ravine
#

Hi all,

We want to move a cluster to an external location connected via IPSec, thus we need to change the MTU values from the default 1500 to 1440.
Will this change have negative impact on our storage cluster? It will only be used as a vault as a destination cluster for snapmirror.

Because MTU values will also need to be changed on the production cluster (source) and network equipment in between, would this also have impact on the production (source) cluster?

nimble crypt
#

seems like 2023 would be time to finally use jumbo frames between locations

thin ravine
#

Unfortunately we'll be using a fortigate that doesn't support Jumboframes

nimble crypt
#

i guess you could ask for an exception and point to encryption for intercluster links

#

smaller mtu's certainly aren't going to be a positive thing... more frames mean more load, probably less maximum bandwidth

#

i'd limit the smaller mtu to a broadcast domain dedicated to intercluster lifs ...

plucky sphinx
#

is it possible to use dedicated physical ports and broadcast domains for intercluster traffic?

nimble crypt
#

if you can assign a port to a broadcast domain (and you can), then i can't see why not

#

the lif assigned to the port just has to be an "intercluster lif" ...

plucky sphinx
#

sorry, to clarify my question: Are unused network ports available in this config @thin ravine ? Dedicated ports would work around any mtu problems that might arise on the production side

thin ravine
#

We are using dedicated lifs for intercluster traffic with a dedicated "replication" broadcast domain

#

on all three clusters, (source, replica, vault)

#

good to mention is that we are using SVMDR

#

between source, replica

#

source and vault relation is a regular snapmirror relation

nimble crypt
#

dedicated ports are generally not a great idea because you lose a lot of flexibility

#

so reducing the mtu is as simple as modifying the broadcast domain... there will be a short drop in traffic

thin ravine
#

SourceCluster_ic01 up/up 10.1.1.40/27 a0a-2986
SourceCluster_ic02 up/up 10.1.1.41/27 a0a-2986

ReplicationCluster_ic01 up/up 10.1.1.42/27 a0a-2986
ReplicationCluster_ic02 up/up 10.1.1.43/27 a0a-2986

VaultCluster_ic01 up/up 10.1.1.44/27 a0a-2986
VaultCluster_ic02 up/up 10.1.1.45/27 a0a-2986

These are the intercluster lif's we are using

nimble crypt
#

broadcast-domain show -ports *2986 will tell you the relevant broadcast-domain and the mtu and ipspace, etc

thin ravine
#

it's just the 2 lifs in the replication vlan (2986)

thin ravine
# plucky sphinx sorry, to clarify my question: Are unused network ports available in this config...

We have two physical ports available on each node of the cluster

                                              Speed(Mbps) Health

Port IPspace Broadcast Domain Link MTU Admin/Oper Status


a0a Default - up 1500 -/- healthy
a0a-2985 Default Management up 1500 -/- healthy
a0a-2986 Default Replication up 1500 -/- healthy
a0a-2987 Default NFS up 1500 -/- healthy
a0a-2988 Default NFS-Nextcloud up 1500 -/- healthy
a0a-2989 Default CIFS up 1500 -/- healthy
a0a-2991 Default Antivirus up 1500 -/- healthy
e0M Default Default up 1500 auto/1000 healthy
e0a Cluster Cluster up 9000 auto/10000 healthy
e0b Cluster Cluster up 9000 auto/10000 healthy
e0c Default - up 1500 auto/10000 healthy
e0d Default - down 1500 auto/- -
e0e Default - up 1500 auto/10000 healthy
e0f Default - down 1500 auto/- -

nimble crypt
#

yeah, you'll have to reduce the mtu on all of the relevant broadcast-domains on all of the clusters

thin ravine
#

yes, i thought so. let's hope that doesn't give any performance issues

#

perhaps it's wiser to create additional lifs on both source and vault cluster? and change the MTU values of those broadcast domain / lif only?

#

so it doesn't impact the replication traffic betweer source/destination for production?

nimble crypt
#

if you can get an exception for vlan 2986 and just use encryption on the intercluster links it woud be more ideal...

#

yeah, if you need different mtu's for different tasks, then you'll need more vlans and ip networks

thin ravine
#

can you clarify on the exception? where would i need this exception ? 😄

nimble crypt
#

if you only need the smaller mtu between 2 of the 3 clusters, then use a separate vlan for communication to the cluster on the remote side of your ipsec tunnel, then you can reduce the mtu just for that traffic... you'll need a new ip net as well normally

thin ravine
#

we are using tls-psk for the encryption betweer the cluster peers

nimble crypt
#

or 1 of the 3 ... one point in your triangle

#

yes, the encryption there should be basically as good as what your old fortinet box is going to offer, if not better... so one might argue that vlan 2986 doesn't really need to go through an ipsec tunnel

thin ravine
#

yes that's what we want 😄 we'll talk to our network engineers to see what's possible.