Support Support Downloads Knowledge Base Juniper Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[QFX] Using Microsoft NLB multicast-mode in EVPN-VXLAN fabric



Article ID: KB35379 KB Last Updated: 06 Jan 2020Version: 1.0

This article provides a work-around for supporting Microsoft NLB multicast-mode in EVPN-VXLAN fabric.

(The Microsoft offered Network Load Balancing (NLB) is a legacy clustering technology that enables load balancing of network traffic across multiple data center servers. The NLB is enabled at the server level for services, such as Web, streaming media, proxy, etc. It also brings high availability capabilities of the services by detecting host failures and automatically redistributing traffic to operational servers.)

  • The statically configured IP to multicast MAC is not translated to an EVPN MAC+IP advertisement.
  • The multicast MAC does not show up next to the unicast IP address in the EVPN database.

When implementing Microsoft NLB with servers connected to EVPN-VXLAN fabric, special care needs to be taken while implementing the IP gateway of the NLB servers. This is mainly because the current Junos OS implementation of the EVPN-VXLAN control plane MAC and MAC+IP learning is not allowing to map a unicast IP address to a multicast MAC address.


There is no multicast MAC to unicast IP T2 route support as of today. Please check back for an update to this article.


In order to work-around the current EVPN-VXLAN limitation of mapping unicast IP address to a multicast MAC address, the recommendation is to enable the first-hop gateways for the NLB servers outside of the fabric using external devices with traditional VRRP and route back to the fabric in order to reach the rest of the newer workloads.

NLB devices and external legacy gateways can be connected using an ESI-LAG in order to continue offering full network redundancy capabilities. The newer server application will continue using the modern Virtual-Gateway IRB.VGA active/active first-hop gateway approach and when needed the IP routing between the external gateway IP subnets and fabric subnets will take place accordingly for the NLB application. The external VRRP gateway will be provisioned with the multicast MAC to unicast IP hardcoded entries and will therefore not originate the ARP request itself for that MAC address. 

It's also recommended to disable the igmp-snooping inside the fabric for the NLB VLAN-name on all QFX nodes and also disable the default ARP-suppression capability for that particular NLB VLAN:

user101@qfx-node# set vlans vlanNLB no-arp-suppression 
user101@qfx-node# deactivate protocols igmp-snooping vlan vlanNLB

Additional Information: 

KB30135 - [EX/QFX] Example - Work-around for using Microsoft network load balancing on EX4300 and QFX5100 switches

MS Blog: The NLB Deployment Reference – All you need to know to implement and deploy Microsoft Network Load Balancing

Juniper documentation: Bridged Overlay Design and Implementation
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search