# Multi-Pod EVPN Troubleshooting: Extended BGP Communities

DevFeed: [Multi-Pod EVPN Troubleshooting: Extended BGP Communities](<https://devfeed.tech/articles/multi-pod-evpn-troubleshooting-extended-bgp-communities-11295.md>)

Original publisher: [Read original article](<https://blog.ipspace.net/2025/12/evpn-multi-pod-tshoot-xc/>)

Published: 2025-12-02T05:47:00Z

Content type: tutorial

Language: en

Sources: [ipSpace.net blog](<https://devfeed.tech/sources/ipspace-net-blog.md>)

Topics: [evpn](<https://devfeed.tech/topics/evpn.md>), [BGP](<https://devfeed.tech/topics/bgp.md>), [Network](<https://devfeed.tech/topics/network.md>)

Tags: [bgp](<https://devfeed.tech/tags/bgp.md>), [blog](<https://devfeed.tech/tags/blog.md>), [evpn](<https://devfeed.tech/tags/evpn.md>), [netlab](<https://devfeed.tech/tags/netlab.md>), [troubleshooting](<https://devfeed.tech/tags/troubleshooting.md>)

## AI overview

This fifth post in a multi-pod EVPN series troubleshoots a fabric where Site-B did not recognize a remote VTEP. The issue was missing extended BGP communities on remote EVPN routes; enabling extended BGP community propagation for the EBGP EVPN address family on Arista EOS resolved the problem, allowing the affected devices to ping each other.

## Source excerpt

Last week, we fixed the mismatched route targets in our sample multi-pod EVPN fabric. With that fixed, every PE device should see every other PE device as a remote VTEP for ingress replication purposes. We got that to work on Site-A (AS 65001), but not on Site-B (AS 65002); let's see what else is broken. Note: This is the fifth blog post in the Multi-Pod EVPN series. If you stumbled upon it, start with the design overview and troubleshooting overview posts. More importantly, familiarize yourself with the topology we'll be using; it's described in the Multi-Pod EVPN Troubleshooting: Fixing Next Hops. Ready? Let's go. Here's our network topology: Read more ...