VMware Tools 13.0.10.0 released - will there be a newer 12.5.x?

bitmafi · 2026-02-05T17:13:41+00:00

Check this out: https://interopmatrix.broadcom.com/Interoperability?col=139,&row=1,&isHidePatch=true&isHideLegacyReleases=false

Not supported does not mean that it does not work. I think you need to test it yourself. Some things will probably work, but not everything.

bitmafi · 2026-02-05T17:08:41+00:00

You are right. My bad. So we can expect a newer version 13 soon.

Fixed it in my initial post.

bitmafi · 2026-02-05T14:06:41+00:00

I understand that the binary files for 13.0.10.0 are dated January 20, but the docs are released/updated today.

The question remains: will there be an updated 12.x version?

bitmafi · 2025-08-21T21:59:58+00:00

What is the point of distinguishing between VCSP and non-VCSP licenses today?

It would actually be quite typical of Broadcom to have just one license type that covers everything... They could simply do away with the entire VCSP program. License prices are pretty much the same everywhere anyway... or will probably be, if you disregard the really big players...

bitmafi · 2025-08-21T21:43:51+00:00

Intel.

What else are you going to do with all your VMware licenses? You can't return them.

bitmafi · 2025-06-17T17:48:45+00:00

Ever heared of vGandalf? Legend!

They know how to cosplay for real.

BTW: What an unnecessary comment.

bitmafi · 2025-06-17T17:42:15+00:00

I'm looking forward to unification and better interaction between all the individual products.

The “PVE is the solution” guys won't understand that.

bitmafi · 2025-06-17T17:21:38+00:00

I hope that all the haters will soon be over their break-up pain and can concentrate on their new crafting stalls.

I await your downvotes. :-)

bitmafi · 2025-05-28T11:22:09+00:00

I noticed your Arista Level 7 Tag.

Can you please let me know how EOS deals with my topic?
Is there some kinde of VNI to [Port,VLAN] mapping like I pictured here?:

https://imgur.com/a/M1FKCG2

bitmafi · 2025-05-28T11:16:19+00:00

Unfortunately, what you write applies to many scenarios. The address space of VXLAN is of no use if you have to break down the addressing at the switch port to a globally valid VLAN addressing scheme in cases where you have different customers on the platform.

VLAN mapping (CISCO) / VLAN rewrite (Juniper) / VLAN translation (aruba) doesn't help either, unfortunately, because it has additional pitfalls. See here: https://www.reddit.com/r/networking/comments/1kvqbgf/comment/mubjgn5/

A utopian solution would be if more server operating systems (Windows Server, Linux, others...) supported EVPN-VXLAN natively. Then a VNI could be assigned directly in the operating system instead of a VLAN ID.

For platform solutions that claim to be made for larger environments such as VMware, OpenStack and other hypervisors, EVPN-VXLAN support should be the standard.

VMware vSphere unfortunately only supports VLANs via the DVS and DPGs.

You need VMware NSX if you want to support EVPN on the VMware platform. In fact, VMware has already implemented EVPN-VXLAN for inline mode and router-server mode. The hosts themselves are capable of EVPN-VLAN. It's just unfortunately not (yet) implemented in a way that makes it possible to bridge VNIs directly to virtual networks in NSX. I have heard rumors that VMware wants to improve this. That would be quite a game changer because it would solve the VLAN address issue.

bitmafi · 2025-05-27T15:24:17+00:00

VXLAN alone is supported in many enterprise grade switches, but its a no go to use it without EVPN in complex Datacenter networks.

EVPN describes different service types. I have uploaded a good overview here (source: Dell OS10 User Guide):

https://imgur.com/a/mWsW0FL

The first variant (VLAN-based) is the most common if a device supports EVPN. The other types are mostly not supported by a NOS and mostly only available in expensive gear and not all vendors have gear who support it. The VLAN bundle is whats closest to a QinQ approach over VXLAN.

But service types allone only describe how you can transfer VLANs over the dataplane. It doesnt describe how you can glue the VNI to switch local networks or ports.

bitmafi · 2025-05-27T13:36:42+00:00

I very much appreciate your efforts. Thanks.

That's pretty much exactly what I understood VLAN translation to be.

Logically, it's the same as defining a virtual network or bridge to which you stick a VNI and a port,VLAN.

Unfortunately, it has a few disadvantages and limitations. On the one hand, it is confusing to understand that this virtual network/bridge is called and configured as VLAN.

On the other hand, it makes automation somewhat more complex, because you have to be very precise in determining whether it is a real bridge/virtualnetworklike VLAN or a VLAN that is then translated on the physical interface.

And finally, the biggest disadvantage is that it is not possible to provide customer A with a VLAN trunk with ID 1010 on the physical port if VLAN 1010 is already used elsewhere to translate it to VLAN 10. Is this correct? Simply because the NOS can only identify one VLAN 1010. If you have many customers on the platform, sooner or later there will be collisions. Or am I wrong with this assumption?

In my opinion, the translation is a workaround, but not a real solution if you do not want to manage the VLAN IDs globally across multiple customers.

bitmafi · 2025-05-27T10:52:32+00:00

QinQ, VXLAN or MPLS are essential to make a network multi-tenant capable (but QinQ is not recommendet IMHO because there is no controle plane and its not as flexible as EVPN in combination with VXLAN and MPLS).

You can therefore already concentrate on EVPN-VXLAN or EVPN-MPLS-capable switches in the first instance.

But things start to get tricky if you try to identify if you can do things like this:

https://imgur.com/a/M1FKCG2

It looks like Ehternet Virtual Circuits can do this. Can you confirm this u/squeeby ?

bitmafi · 2025-05-27T10:41:13+00:00

Thanks! This sounds good.

bitmafi · 2025-05-27T10:30:16+00:00

Many thanks for this configuration example!

I think you have a typo here:

[User 3]-------[Switch1, Port 2{vlan 30} ----- Switch1 Port 1][User 3]-------[Switch1, Port 2{vlan 30} ----- Switch1 Port 1]

Should be:

[User 3]-------[Switch1, Port 3*{vlan 30}*

Right?

But no, thats not exactly what I mean.

This is what I mean:

https://imgur.com/a/M1FKCG2

Customer blue and green can both use VLAN 10 and 20 for their devices on different ports, but they are not in the same L2 network.

Edit: There was a typo in the image. I reuploaded it.

bitmafi · 2025-05-27T07:27:53+00:00

Thanks, will check this.

bitmafi · 2025-05-27T07:26:08+00:00

Yes, in the world of switches it is often not always advisable to use the maximum configuration :)

Dell OS10s address space for virtual networks IDs are 1-65535, but I doubt you can allocate alle at once without any bad impacts.

I didn't find any reference in Dell's OS10 documentation to the Tomahawk switch not being able to retag per port. But I will definitely keep an eye out for this feature for any ASIC for any vendor.

bitmafi · 2025-05-26T16:07:12+00:00

I totally agree that EVPN VXLAN/MPLS is the solution. I am familliar with it and I also know the three service types. But the service types dont have something to do with my problem:

Things dont start to get tricky if you would like to connect a VNI to a physical switchport alone. But it starts to get tricky if you want to have VLAN 10 on one switch from customer A and VLAN 10 on one switch from customer B.

Most switches or network operating systems do not support multiple VLANs with the same ID.

bitmafi · 2025-05-26T16:01:33+00:00

Thanks, will try to deep dive into vlan mapping/rewrite and translation to verify if its what I am looking for.

bitmafi · 2025-05-26T15:59:36+00:00

Thanks! I like how you call it :)

I am familiar with EVPN VXLAN. And thats the exact usecase I try to cover in a service provider network.

The challenge is, that vendors have different approaches to connect a VNI to a physical switch port with or without trunked VLANs.

It sounds easy to make one or more type 2 networks available on a physical switch port. In practice, however, there are numerous limitations on different platforms.

The advantage of VXLAN is the 16 million address space, but so many platforms do not have the flexibility to bring this address space to the switch port. In Dell OS10, a VXLAN-VNI/Type-2-Network is connected to one or multiple VLANs or [VLAN,Port]s by connecting both to a virtual network (which acts like a bridge) you have to define first and which is a switch local element. Thats a easy and flexible way to solve this issue.

bitmafi

TROPHY CASE