Link to home
Start Free TrialLog in
Avatar of Bill H
Bill H

asked on

Vmware NIC Teaming

Hey Guys,

I have ESXi 5.5 and the server has 2 nics. The 1st nic is going to a switch, and that switch lately seems to be having issues with dropping packets, i have a lot of leg work to do to completely remove (Which is the plan soon), now i have a second switch on the same vlan and i can run a cable to that switch for us to work off of. Should i set this is up as NIC teaming or can i actually use this new NIC as part of the same network without any downtime - essentially move everything to this nic without making network changes ?
Avatar of Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
Flag of United Kingdom of Great Britain and Northern Ireland image

Should i set this is up as NIC teaming or can i actually use this new NIC as part of the same network without any downtime - essentially move everything to this nic without making network changes ?

Any network changes can cause an outage. Technically it does not require a host reboot, but to be honest rather than look like a "cowboy" in the IT department. Schedule some downtime, to make the change, to prevent loss of service.

If you have two network interfaces, both should be used to prevent a single point of failure, and yes that means teaming, which will give you resilience and additional throughput, but needs to be plan and configured rather than just plug it in and runaway and hope for the best!
Avatar of Bill H
Bill H

ASKER

I have a window, can i get an answer please.
now i have a second switch on the same vlan and i can run a cable to that switch for us to work off of.

yes - but if you've got an issue with that switch, why just disable that port, and use this new link ?

why carry on using a faulty nic, port, cable or switch port ? any traffic data which goes over this fault link you know about will still be faulty, even when teamed ?

unless disabled/removed.
Avatar of Bill H

ASKER

Can you please not drift away and answer my question, right now i have both nics plugged in, what is the next steps.
1. Inbound traffic to the host is dictated by the configuration of the physical switches.

2. Outbound traffic leaving the host is dictated by the configuration of the teaming policy on the HOST.

Properties of the vSwitch.

LACP is NOT Supported, so make sure physical switches are configured for Static Trunk, if you are using trunks.

So it depends, on what physical switch config you have, make and model. Are these two switches trunked/lagged ?

What is the current teaming policy.....

I would be inclined to set as Route based on Originating Port.
Avatar of Bill H

ASKER

Ok lets do this.

1) How can i add the second NIC to part of the same vswitch?
ASKER CERTIFIED SOLUTION
Avatar of Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Bill H

ASKER

OK so now, i have both of them added to the  vSwitch, what happens if i shut the other port as you mentioned?
traffic will route via the other nic.

but you should remove the nic from the config.

No changes on the physical switch are required for Route Based on Originating Virtual Port.
Avatar of Bill H

ASKER

Oh, well then i guess dont need 'teaming' then if it will use the other NIC? I did not know that.
Teaming will distribute the load between the network interfaces connected to the vSwitch.

If you have a faulty circuit, network interface, port, cable, bucket of water connected to the nic, it's not really that intelligent to know packets that left the nic, didn't get to the destination....

hence why I suggested to remove it, if it's known to be faulty!

you can drop it, select unsed, remove it, or standby, but to be honest with you it's best to fix the issue, and team both for resilience, and remove the single point of failure