<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/dear-vendors-evpn-route-attributes-matter-ipspace-net-blog-xcc1lwi64" -->

---
title: Dear Vendors, EVPN Route Attributes Matter « ipSpace.net...
description: A bug in FRRouting release 10.3 causes it to strip the BGP Encapsulation Extended Community (ET:8, indicating VXLAN) from EVPN routes when propagating them...
canonical: https://daily.dev/posts/dear-vendors-evpn-route-attributes-matter-ipspace-net-blog-xcc1lwi64
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: Dear Vendors, EVPN Route Attributes Matter « ipSpace.net blog | daily.dev
og:description: A bug in FRRouting release 10.3 causes it to strip the BGP Encapsulation Extended Community (ET:8, indicating VXLAN) from EVPN routes when propagating them...
og:url: https://daily.dev/posts/dear-vendors-evpn-route-attributes-matter-ipspace-net-blog-xcc1lwi64
og:image: https://api.daily.dev/og/posts/XCc1lwi64.png
og:image:alt: Dear Vendors, EVPN Route Attributes Matter « 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.

# Dear Vendors, EVPN Route Attributes Matter « ipSpace.net blog

**[ipSpace.net Blog](https://daily.dev/sources/ipspace)** · 6 min read · 0 upvotes · 0 comments

## Summary

A bug in FRRouting release 10.3 causes it to strip the BGP Encapsulation Extended Community (ET:8, indicating VXLAN) from EVPN routes when propagating them over EBGP sessions. This breaks interoperability with ArubaCX, Dell OS10, and Nokia SR-OS, which refuse to use EVPN routes lacking that community. Other vendors (Cumulus, EOS, Nexus OS, SR Linux, VyOS) silently accept routes without it. The root cause traces to ambiguous language in RFC 8365, which makes the community both optional and seemingly mandatory depending on which paragraph you read. A community-submitted PR fixed the bug in FRR within days of the report, and the fix shipped in FRR releases 10.3.2 and 10.4.1 less than two months later. The post also notes that SR-OS defaults to MPLS encapsulation while SR Linux defaults to VXLAN, explaining why missing the community causes different behavior across Nokia's own product line.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://blog.ipspace.net/2025/06/evpn-route-attributes-matter>

## Questions this post answers

### Why does Nokia SR-OS refuse to use EVPN routes received from FRRouting over EBGP?

SR-OS rejects EVPN routes that are missing the BGP Encapsulation Extended Community (ET:8, signaling VXLAN). FRRouting 10.3 introduced a regression where it strips this community when re-advertising routes over EBGP, even though the BGP next hop is unchanged and the intermediate device is not in the VXLAN data path. The fix shipped in FRR 10.3.2 and 10.4.1. A workaround is to set SR-OS's default EVPN encapsulation to VXLAN via def-recv-evpn-encap vxlan.

_Engineers running multi-vendor EVPN fabrics track regressions like this on daily.dev before they hit production._

### What is the BGP Encapsulation Extended Community ET:8 in EVPN and is it mandatory?

ET:8 refers to the BGP Encapsulation Extended Community with tunnel type 8, meaning VXLAN, as defined in RFC 8365. RFC 8365 is ambiguous: some sections treat the community as optional while others imply it is required. In practice, ArubaCX, Dell OS10, and Nokia SR-OS refuse EVPN routes without it, while Cumulus, EOS, Nexus OS, SR Linux, and VyOS accept routes regardless of its presence.

_Developers navigating RFC ambiguities in EVPN implementations find real-world interop findings on daily.dev._

### What changed between FRRouting 10.2 and 10.3 that broke EVPN with overlapping leaf AS numbers?

FRRouting 10.3 stopped propagating the BGP Encapsulation Extended Community when re-advertising EVPN routes over EBGP sessions, a behavior that worked correctly in FRR 10.2. This broke EVPN setups where leaf switches share the same AS number and use allowas-in, specifically when the spine re-advertises routes to the other leaf. The regression was fixed in FRR 10.3.2 and 10.4.1, less than two months after the bug report.

_Teams upgrading FRRouting in production EVPN fabrics watch for regressions like this on daily.dev._

## Similar posts on daily.dev

- [EVPN with SR-MPLS Core « ipSpace.net blog](https://daily.dev/posts/evpn-with-sr-mpls-core-ipspace-net-blog-taobtibzc) · ipSpace.net Blog · 0 upvotes · 0 comments
- [Multivendor SR-MPLS « ipSpace.net blog](https://daily.dev/posts/multivendor-sr-mpls-ipspace-net-blog-qekokwduk) · ipSpace.net Blog · 0 upvotes · 0 comments

---

Tags: [#networking](https://daily.dev/tags/networking), [#bgp](https://daily.dev/tags/bgp), [#evpn](https://daily.dev/tags/evpn)

[View this post on daily.dev](https://daily.dev/posts/dear-vendors-evpn-route-attributes-matter-ipspace-net-blog-xcc1lwi64)

```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":"Dear Vendors, EVPN Route Attributes Matter « ipSpace.net blog","url":"https://daily.dev/posts/dear-vendors-evpn-route-attributes-matter-ipspace-net-blog-xcc1lwi64","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/dear-vendors-evpn-route-attributes-matter-ipspace-net-blog-xcc1lwi64"},"datePublished":"2026-08-11T08:52:08.301Z","dateModified":"2026-08-24T06:52:12.818Z","description":"A bug in FRRouting release 10.3 causes it to strip the BGP Encapsulation Extended Community (ET:8, indicating VXLAN) from EVPN routes when propagating them...","image":"https://media.daily.dev/image/upload/s--qPvKM23u--/f_auto/v1722860399/public/Placeholder%2009","thumbnailUrl":"https://media.daily.dev/image/upload/s--qPvKM23u--/f_auto/v1722860399/public/Placeholder%2009","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/dear-vendors-evpn-route-attributes-matter-ipspace-net-blog-xcc1lwi64","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"networking,bgp,evpn","timeRequired":"PT6M"}
{"@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":"Dear Vendors, EVPN Route Attributes Matter « ipSpace.net blog"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/dear-vendors-evpn-route-attributes-matter-ipspace-net-blog-xcc1lwi64#faq","mainEntity":[{"@type":"Question","name":"Why does Nokia SR-OS refuse to use EVPN routes received from FRRouting over EBGP?","acceptedAnswer":{"@type":"Answer","text":"SR-OS rejects EVPN routes that are missing the BGP Encapsulation Extended Community (ET:8, signaling VXLAN). FRRouting 10.3 introduced a regression where it strips this community when re-advertising routes over EBGP, even though the BGP next hop is unchanged and the intermediate device is not in the VXLAN data path. The fix shipped in FRR 10.3.2 and 10.4.1. A workaround is to set SR-OS's default EVPN encapsulation to VXLAN via def-recv-evpn-encap vxlan. Engineers running multi-vendor EVPN fabrics track regressions like this on daily.dev before they hit production."}},{"@type":"Question","name":"What is the BGP Encapsulation Extended Community ET:8 in EVPN and is it mandatory?","acceptedAnswer":{"@type":"Answer","text":"ET:8 refers to the BGP Encapsulation Extended Community with tunnel type 8, meaning VXLAN, as defined in RFC 8365. RFC 8365 is ambiguous: some sections treat the community as optional while others imply it is required. In practice, ArubaCX, Dell OS10, and Nokia SR-OS refuse EVPN routes without it, while Cumulus, EOS, Nexus OS, SR Linux, and VyOS accept routes regardless of its presence. Developers navigating RFC ambiguities in EVPN implementations find real-world interop findings on daily.dev."}},{"@type":"Question","name":"What changed between FRRouting 10.2 and 10.3 that broke EVPN with overlapping leaf AS numbers?","acceptedAnswer":{"@type":"Answer","text":"FRRouting 10.3 stopped propagating the BGP Encapsulation Extended Community when re-advertising EVPN routes over EBGP sessions, a behavior that worked correctly in FRR 10.2. This broke EVPN setups where leaf switches share the same AS number and use allowas-in, specifically when the spine re-advertises routes to the other leaf. The regression was fixed in FRR 10.3.2 and 10.4.1, less than two months after the bug report. Teams upgrading FRRouting in production EVPN fabrics watch for regressions like this on daily.dev."}}]}
```

