--- title: Combining MLAG Clusters with VXLAN Fabric « ipSpace.net blog description: When connecting MLAG clusters to a VXLAN fabric, dynamic MAC learning breaks because the same source MAC can arrive from two different VTEPs (S1 and S2). The... canonical: https://daily.dev/posts/combining-mlag-clusters-with-vxlan-fabric-ipspace-net-blog-tngnp4r4l twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Combining MLAG Clusters with VXLAN Fabric « ipSpace.net blog | daily.dev og:description: When connecting MLAG clusters to a VXLAN fabric, dynamic MAC learning breaks because the same source MAC can arrive from two different VTEPs (S1 and S2). The... og:url: https://daily.dev/posts/combining-mlag-clusters-with-vxlan-fabric-ipspace-net-blog-tngnp4r4l og:image: https://api.daily.dev/og/posts/TngnP4r4L.png og:image:alt: Combining MLAG Clusters with VXLAN Fabric « ipSpace.net blog og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Combining MLAG Clusters with VXLAN Fabric « ipSpace.net blog **[ipSpace.net Blog](https://daily.dev/sources/ipspace)** · 7 min read · 0 upvotes · 0 comments ## Summary When connecting MLAG clusters to a VXLAN fabric, dynamic MAC learning breaks because the same source MAC can arrive from two different VTEPs (S1 and S2). The solution is an anycast VTEP IP address shared by both cluster members, which also enables load balancing for free. Orphan hosts introduce a secondary problem: return traffic may land on the wrong switch, requiring ASIC support for per-ingress-interface VTEP selection. BUM flooding is handled differently depending on whether the fabric uses IP multicast (designate one cluster member as flooder) or ingress replication (anycast VTEP naturally distributes packets, standard MLAG flooding procedures handle the rest). Peer link flooding rules must also be extended to treat the VXLAN interface like an MLAG interface to avoid duplicate flooding. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why do MLAG cluster members need to share the same anycast VTEP IP address in a VXLAN fabric? MLAG cluster members must share an anycast VTEP IP address because dual-attached hosts send traffic via both switches simultaneously. If S1 and S2 used different VTEP IPs, the remote switch (Sx) would see the same source MAC arriving from two different VTEPs, corrupting its MAC-to-VTEP mapping table. A shared anycast VTEP IP prevents this confusion and also enables load balancing for return traffic. _Engineers designing MLAG+VXLAN topologies track nuances like these on daily.dev before they hit production._ ### How does BUM flooding work in a VXLAN fabric when the egress switch is part of an MLAG cluster using ingress replication? With ingress replication, all MLAG cluster members advertise the same anycast VTEP IP, so replicated BUM packets are received by a random cluster member. That member floods the packet to all local ports and the peer link, and standard MLAG flooding procedures handle further distribution. Packets received from the peer link must not be re-flooded to the VXLAN fabric to avoid duplication. _Keeping up with MLAG flooding edge cases is easier when the right posts surface on daily.dev._ ### What is the orphan host problem in MLAG plus VXLAN deployments and how is it solved? Orphan hosts (single-homed to one MLAG member) cause return traffic from the fabric to use the anycast VTEP, landing roughly half the packets on the wrong switch, which must then hairpin them over the peer link. The solution requires ASIC support for selecting a per-switch VTEP source address based on ingress interface, so orphan host traffic is encapsulated with a unique VTEP IP rather than the shared anycast address. _Architects weighing MLAG orphan host trade-offs find peer discussion and related posts on daily.dev._ --- [View this post on daily.dev](https://daily.dev/posts/combining-mlag-clusters-with-vxlan-fabric-ipspace-net-blog-tngnp4r4l) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Combining MLAG Clusters with VXLAN Fabric « ipSpace.net blog","url":"https://daily.dev/posts/combining-mlag-clusters-with-vxlan-fabric-ipspace-net-blog-tngnp4r4l","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/combining-mlag-clusters-with-vxlan-fabric-ipspace-net-blog-tngnp4r4l"},"datePublished":"2026-08-11T08:52:23.435Z","dateModified":"2026-08-11T08:57:42.334Z","description":"When connecting MLAG clusters to a VXLAN fabric, dynamic MAC learning breaks because the same source MAC can arrive from two different VTEPs (S1 and S2). The...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/8782ed40f58043c8850e0c03de055b1b?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/8782ed40f58043c8850e0c03de055b1b?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"ipSpace.net Blog","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"ipSpace.net Blog","logo":"https://media.daily.dev/image/upload/s--xS7E82MT--/f_auto,q_auto/v1786438303/logos/ipspace?_a=BAMAMicg0","url":"https://daily.dev/sources/ipspace"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/combining-mlag-clusters-with-vxlan-fabric-ipspace-net-blog-tngnp4r4l","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"","timeRequired":"PT7M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"ipSpace.net Blog","item":"https://daily.dev/sources/ipspace"},{"@type":"ListItem","position":3,"name":"Combining MLAG Clusters with VXLAN Fabric « ipSpace.net blog"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/combining-mlag-clusters-with-vxlan-fabric-ipspace-net-blog-tngnp4r4l#faq","mainEntity":[{"@type":"Question","name":"Why do MLAG cluster members need to share the same anycast VTEP IP address in a VXLAN fabric?","acceptedAnswer":{"@type":"Answer","text":"MLAG cluster members must share an anycast VTEP IP address because dual-attached hosts send traffic via both switches simultaneously. If S1 and S2 used different VTEP IPs, the remote switch (Sx) would see the same source MAC arriving from two different VTEPs, corrupting its MAC-to-VTEP mapping table. A shared anycast VTEP IP prevents this confusion and also enables load balancing for return traffic. Engineers designing MLAG+VXLAN topologies track nuances like these on daily.dev before they hit production."}},{"@type":"Question","name":"How does BUM flooding work in a VXLAN fabric when the egress switch is part of an MLAG cluster using ingress replication?","acceptedAnswer":{"@type":"Answer","text":"With ingress replication, all MLAG cluster members advertise the same anycast VTEP IP, so replicated BUM packets are received by a random cluster member. That member floods the packet to all local ports and the peer link, and standard MLAG flooding procedures handle further distribution. Packets received from the peer link must not be re-flooded to the VXLAN fabric to avoid duplication. Keeping up with MLAG flooding edge cases is easier when the right posts surface on daily.dev."}},{"@type":"Question","name":"What is the orphan host problem in MLAG plus VXLAN deployments and how is it solved?","acceptedAnswer":{"@type":"Answer","text":"Orphan hosts (single-homed to one MLAG member) cause return traffic from the fabric to use the anycast VTEP, landing roughly half the packets on the wrong switch, which must then hairpin them over the peer link. The solution requires ASIC support for selecting a per-switch VTEP source address based on ingress interface, so orphan host traffic is encapsulated with a unique VTEP IP rather than the shared anycast address. Architects weighing MLAG orphan host trade-offs find peer discussion and related posts on daily.dev."}}]} ```