# Common Services VRF with EVPN Control Plane

DevFeed: [Common Services VRF with EVPN Control Plane](<https://devfeed.tech/articles/common-services-vrf-with-evpn-control-plane-11053.md>)

Original publisher: [Read original article](<https://blog.ipspace.net/2024/08/evpn-common-services-vrf/>)

Published: 2024-08-29T05:49: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>), [Virtual Private Network](<https://devfeed.tech/topics/vpn.md>), [networking](<https://devfeed.tech/topics/networking.md>)

Tags: [evpn](<https://devfeed.tech/tags/evpn.md>), [netlab](<https://devfeed.tech/tags/netlab.md>), [server](<https://devfeed.tech/tags/server.md>), [tests](<https://devfeed.tech/tags/tests.md>), [validation](<https://devfeed.tech/tags/validation.md>), [vpn](<https://devfeed.tech/tags/vpn.md>)

## AI overview

The article tests implementing a common services L3VPN with an EVPN control plane on Arista cEOS. It describes hub and spoke VRF route-import behavior and reports that the expected connectivity and validation results work.

## Source excerpt

After discovering that some EVPN implementations support multiple transit VNI values in a single VRF, I had to check whether I could implement a common services L3VPN with EVPN. A common services VPN is a VPN in which server sites can communicate with each other and the clients, but the clients cannot communicate between themselves. TL&DR: It works (on Arista cEOS)1. Here are the relevant parts of a netlab lab topology I used in my test (you can find the complete lab topology in netlab-examples GitHub repository): Read more ...