VRRP with E1000e ESXI 7.0?
The past few days I've spent a while trying to configure VRRP using VMXNET3 only to realize that it isn't supported (I should have rtfm), but I recently made some new TNSR VMs with E1000e and I still can't get VRRP "working". The routers have elected a master/backup and they are sending the advertisements and failing over correctly when one goes down or an int goes down, but I cannot ping the VIP or connect to anything if I use the VIP as the gateway. The virtual MAC is in the test VMs arp table though. The vSwitches have Promiscuous mode, MAC changes and Forged Transmits all set to accept. I can provide configs in a bit, but the main purpose of this post was me just wondering if anyone actually got VRRP working on ESXi 7.0 and if so, what NIC type? I haven't tried E1000, PVRDMA or VMXNET2 Enhanced yet. It definitely could be something in my configs, but I wanna try and rule this out first.
Connect the ISP to two WAN switches and connect them together. Then the ISP monitors themselves and you can route as you like using IP monitoring for GW down/up.
This is for a lab environment and I'm only looking to have VRRP run on the LAN interfaces (unless that isn't possible, I'm pretty new to this stuff). I'm basically trying to have it setup like the wiki does but minus the WAN side.
@machoherbivore9 Its basically BGP and normally something the ISP is using.
What are you trying to achieve on LAN?
Sorry I'm confused, is VRRP not a failover/HA protocol for routers? Like if one goes down is seamlessly switches to the other and devices use the Virtual Router IP as their gateway? BGP is a routing protocol isn't it?
@machoherbivore9 Yes but normally only used on WAN's from ISP's with multiple connections.
I havent heard anyone using BGP on LAN before.
Dobby_ last edited by
@machoherbivore9 said in VRRP with E1000e ESXI 7.0?:
Sorry I'm confused, is VRRP not a failover/HA protocol for routers?
Yes it is. But on the other hand there are some more
methods, different practices and use cases between
that many points.
redundant = two or more routers are in the "game"
will often count until 25.000 €/$ (pending on the company or use case size)
(in the same rack or two resp. more racks and/or rooms, switches or more devices will be also able to double)
HA = two or more routers but in a different way!
will often start at 25.000 €/$ (pending on the company or use case size)
(In two or more racks and they in two or more rooms and they are in two or more fire sections in on or more buildings)
Active/active and/or active/passive mode will be also very nice to know before using or needing.
- active/active over CARP protocol (with load balancing)
- active/passive over VRRP (no load balancing)
Loadbalancing with "automatic" failover can also be done with using the following (in pfSense)
- policy based routing (load balancing)
- service based routing (load balancing)
- session based routing (load balancing)
There are often as today in modern times also switches they are capable of doing this job fully, partwise or better
said they will nice playing together with that routing protocols.
Like if one goes down is seamlessly switches to the
other and devices use the Virtual Router IP as their
It works like that.
BGP is a routing protocol isn't it?
Yes this is right eBGP and iBGP are available for usage.
It is pending on your used firewalls, routers and or switches and what they are supporting well or not.
Alright so I'll ask this then:
If I want to make it so that if one TNSR router goes down there is very limited interruption with devices on the LAN side what do I do? This is on ESXi 7.0. I do not have access to more equipment like physical switches. I can have as many addresses from the "ISP" as I want and they can be set statically as this is a lab environment.
This is just for proof on concept it doesn't need to be setup with an actual real need for redundancy, it just needs to work.
Will VRRP work for this?
@machoherbivore9 Use failover on the Vswitch instead so the TNSR works like normal but Vsphere takes over the failover unnoticed.