Contents
Introduction
In this document we demonstrate deployment of Arista’s CloudEOS Router in Google Cloud Platform (GCP). Sections of this document have been set forth based on order of execution, hence it is pertinent that the order is maintained for successful deployment of Arista’s CloudEOS Router.
Overview
Arista’s cloud infrastructure both public and private offers significant efficiencies that make it a compelling option for workload placement. We have proven this in the private cloud with a simple yet scalable Spine/Leaf topology utilizing industry standard protocols across all of Arista switches. With Any Cloud, Arista is extending two proven software platforms, EOS and CloudVision, to offer a consistent multi-cloud architectural and operational approach.
Prerequisites
In order to provision Arista CloudEOS Router in GCP, following prerequisites must be satisfied:
- Obtain a GCP account.
- Determine the scale of the deployment and hence the machine type that is required. This demonstration covers a Series: N1 machine type for Arista CloudEOS Router.
- SSH clients like putty on windows. OSX and Linux provide SSH clients natively.
Topology
We will demonstrate deployment of an Edge / Leaf topology (emulating a Spine / Leaf deployment in a private data center), all of its components, CloudEOS Routers and Linux VM’s as shown below.
As shown in this logical layout a pair of Arista CloudEOS Routers reside in each VPC. We will provision the CloudEOS Router machine with a single NIC only and enforce a routing policy that defaults all the traffic for all the subnets, with exception of the one that CloudEOS Router’s Ethernet interface resides on, to the CloudEOS Router’s Ethernet interface.
Routes will be added with tags to ensure machines deployed in a specific zone route via the CloudEOS Router in that zone, for example in Leaf1 VPC – static route will be applied as following:
- In the Leaf1 VPC, a route will be added for the destination IP range of Leaf2 VPC CIDR.
- In the Leaf2 VPC, a route will be added for the destination IP range of Leaf1 VPC CIDR.
GCP Login
Initial login to the GCP console (https://console.cloud.google.com/) will direct you to the following dashboard as shown below:
VPC and its components
A Virtual Private Cloud (VPC) is a global private isolated virtual network partition that provides managed networking functionality for your GCP resources. You must specify an IPv4 address range for your VPC. Specify the IPv4 address range as a Classless Inter-Domain Routing (CIDR) block.
Create ‘Edge1’, ‘Leaf1’ and ‘Leaf2’ VPCs
- Click on the ‘Navigation Menu’ (drop down menu top-left of the screen that looks like this: ) and then select ‘VPC Network’ dashboard:
- From the ‘VPC Network’ dashboard select ‘Create VPC Network’:
- Click on ‘Create a VPC Network’ and enter the following details for ‘edge1’ VPC:
We will be creating 2 subnets for the edge1 VPC as it’s a transit VPC only and there will be no other compute machines (VM’s) in it. Please reference the topology diagram for details pertaining to the subnets and their CIDR.
For this demonstration we will select the routing mode as ‘Regional’ and then ‘Create’ the VPC:
Similarly create the ‘Leaf1’ and ‘Leaf2’ VPC’s as well:
Here is a summary of all 3 VPC’s:
Note that we have disabled machines (VM’s) to not be accessible from the Internet for some of the subnets by ‘enabling’ Private Google Access for those subnets. More information on Private Google Access is available here – https://cloud.google.com/vpc/docs/configure-private-google-access
Add Firewall Rules
- We will create a firewall rule for SSH access into all the VM’s in the VPC from the Internet. From within the VPC Dashboard click on ‘Firewall Rules’:
Then, click on ‘Create Firewall Rule’
Assign this new ‘Firewall Rule’ an appropriate name, ‘Network’ should be auto selected as we initiated the Firewall Rule creation from within the VPC, and change the ‘Target’ to ‘All instance in the network’:
Specify the ‘Source IP Range’, ‘Specified protocols and ports’ and click on ‘Create’:
Similarly, create a ‘Firewall rule’ for all the other VPC’s we created (Leaf1 and Leaf2).
- We will also create firewall rules to allow unfederated access between the Edge1, Leaf1 and Leaf2 VPC’s. These following examples demonstrate creation of firewall rules for the Edge1 VPC only.
Similarly, create firewalls for Leaf1 and Leaf2 VPC’s. Here is a summary of all the firewall rules for all the VPC’s
Edge1:
Leaf1:
Leaf2:
Create VPC Peerings
A VPC Peering connection is a networking connection between two VPCs that enables you to route traffic between them using private IPv4 addresses or IPv6 addresses. Based on our topology, this VPC Peering is mainly for IP reachability between the Infrastructure links, i.e connectivity between 110.2.0.0/24 <> 111.2.0.0/24 and 110.2.0.0/24 <> 112.2.0.0/24. This will ensure VXLAN, BGP and IPSec connectivity between GCP-Edge1a/b CloudEOS Routers and GCP-Leaf1a/b as well as GCP-Leaf2a/b Routers. By default, GCP will enable routing between all the subnets of VPCs that peer with one another. For more information on GCP VPC peering please refer to this link – https://cloud.google.com/vpc/docs/vpc-peering
- From the ‘VPC Network’ dashboard select ‘Create peering connection’:
- Click on ‘Continue’:
- Provide a meaningful name for the VPC peering connection (edge1-to-leaf1), specify the VPC name you want to peer from (edge1), the VPC name you want to peer with (leaf1) and then click on ‘Create’.
Note that we are not exchanging any custom routes hence we will leave everything as default. Think of VPC peering as a route, we just created a route from point A to point B, now we need to create a similar route from Point B to Point A. We will repeat the same steps for all the VPC’s.
‘leaf1-to-edge1’ VPC peering connection:
‘edge1-to-leaf2’ VPC peering connection:
‘leaf2-to-edge1’ VPC peering connection:
Here is a summary of all the VPC peerings we’ve created and are required for our topology:
GCP has a restriction where VPC peers always exchange subnet routes that don’t use privately reused public IP addresses. Networks must explicitly import subnet routes that use privately reused public IP addresses to receive them. Here is the link for more information – https://cloud.google.com/vpc/docs/vpc-peering.
Click on this icon 
as shown in the image below to launch the cloud shell and then execute all these commands for all the VPC peerings we’ve just built. This will explicitly import the non rfc-1918 addresses we are using in our topology.
- gcloud compute networks peerings update edge1-to-leaf1 –network edge1 –import-subnet-routes-with-public-ip
- gcloud compute networks peerings update leaf1-to-edge1 –network leaf1 –import-subnet-routes-with-public-ip
- gcloud compute networks peerings update edge1-to-leaf2 –network edge1 –import-subnet-routes-with-public-ip
- gcloud compute networks peerings update leaf2-to-edge1 –network leaf2 –import-subnet-routes-with-public-ip
Upon completion we can validate that all the subnet routes are exchanged for our VPC peerings:
Arista CloudEOS Instances and its Components
In the following sections we will instantiate Arista CloudEOS Router instances and the linux VM’s as machines.
Create a New SSH Key
We will now create a private SSH key file and a matching public SSH key file to control access to the Arista CloudEOS and Linux instances. From a terminal on your workstation and use the ssh-keygen command to generate a new key. Specify the -C flag to add a comment with your username.
Note the location of the files we just created as we will need to open the public key and copy its contents when we create the Arista CloudEOS Router instances and the linux VM’s.
Instantiate a CloudEOS Router instance
In this section we will go through creation of the CloudEOS Router instances.
Click on the ‘Navigation Menu’ (drop down menu top-left of the screen that looks like this: 
), hover your mouse over ‘Compute Engine’ and then select ‘VM Instances’:
Click on ‘Create Instance’:
Click on ‘Marketplace’ to search the GCP marketplace for Arista’s CloudEOS Router image:
Select the Arista ‘vEOS Router’ (soon to be rebranded as CloudEOS) Virtual Machine:
Click on ‘Launch’
Copy the contents of the public SSH key file we created earlier:
Create the Arista CloudEOS Router instance ‘gcp-edge1a’ as shown below. Paste the contents of the public SSH key file in the ‘ssh key’ section. Click on ‘Deploy’:
Similarly, create gcp-edge1b’, ‘gcp-leaf1a’, ‘gcp-leaf1b’, ‘gcp-leaf2a’ and ‘gcp-leaf2b’ VM’s.
Here is a list of all the CloudEOS Router instances we just created:
Instantiate Linux instances
We will create 4 Ubuntu linux instances as per our topology for hosts shown as gcp-dev1, gcp-prod1, gcp-prod2 and gcp-dev2.
We’ve assigned these VM’s proper network tags based on the VPC and Zone they are in, such as:
- gcp-dev1 has been assigned a network tag of ‘leaf1-zone1’.
- gcp-prod1 has been assigned a network tag of ‘leaf1-zone2’.
- gcp-dev2 has been assigned a network tag of ‘leaf2-zone1’.
- gcp-prod2 has been assigned a network tag of ‘leaf2-zone2’.
Update Routing Tables
Creation of the VPC will create and associate a Routing Table for each subnet within the VPC. We will create a new route for the VM instances with appropriate network tags and add routes for Leaf2 CIDR via Leaf1 CloudEOS Routers and vice-versa. During VM instance instantiation we will tag them with appropriate tags based on which the routes will be applied. We will follow this logic:
- VM instances in the ‘us-east-1b’ zone of us-east1 will get the tag of ‘leaf1-zone1’ and ‘leaf2-zone1’.
- VM instances in the ‘us-east-1c’ zone of us-east1 will get the tag of ‘leaf1-zone2’ and ‘leaf2-zone2’.
Click on the ‘Navigation Menu’ (drop down menu top-left of the screen that looks like this: 
), select ‘VPC Networks’ and then click ‘Create Route’:
Here is an example of route for VM instances in Leaf1 VPC’s Zone1 as per our topology.
Similarly we will create routes for the remaining zones in both the leaf VPC’s. Note that we have added destination IP range of Leaf2 VPC for leaf1-zone1/zone2 routes and destination IP range of Leaf1 VPC for leaf2-zone1/zone2 routes. This will take care of bidirectional routing for both the Leaf1 and Leaf2 VPC’s.
Connect to the CloudEOS Router instances and Linux VM’s
CloudEOS Router instances and the Linux VM’s are accessible via the external IP that gets assigned to them dynamically.
- Here is a list of all the CloudEOS Router instances and Linux VM’s that we’ve instantiated:
Once you determine the external IP of the instance you’d like to connect to, reference the SSH key we created in the Create a New SSH Key section and specify the username associated with that key while trying to SSH to the instance:
CloudEOS Router configuration
We will configure the CloudEOS instances and utilize DPS for the underlay reachability. We will then configure VXLAN with BGP eVPN as the control plane. Please note that due to lack of layer-2 support in the public cloud VXLAN will provide L3VPN functionality only and we will only be exchanging type-5 routes using BGP eVPN.
- Configure Dynamic Path Selection as described in the EOS manual – https://www.arista.com/en/cg-veos-router/veos-router-dynamic-path-selection
Define ‘Ethernet100’ on all the CloudEOS Routers and an associated ARP entry:
interface Ethernet100
mtu 1400
no switchport
ip address 10.10.10.1/24
tcp mss ceiling ipv4 1350
!
arp 10.10.10.254 00:00:10:10:10:54 arpa
-
- Create Loopback interfaces for VTEP IP (Loopback0) for the VXLAN overlay peering. We will also create an additional Loopback1 interface for testing routing in the overlay.
| Edge1a | Edge1b | Leaf1a | Leaf1b | Leaf2a | Leaf2b |
| interface Loopback0
ip address 10.10.1.1/32 ! interface Loopback1 ip address 10.10.2.1/32 |
interface Loopback0
ip address 10.10.1.2/32 ! interface Loopback1 ip address 10.10.2.2/32 |
interface Loopback0
ip address 10.10.1.3/32 ! interface Loopback1 ip address 10.10.2.3/32 |
interface Loopback0
ip address 10.10.1.4/32 ! interface Loopback1 ip address 10.10.2.4/32 |
interface Loopback0
ip address 10.10.1.5/32 ! interface Loopback1 ip address 10.10.2.5/32 |
interface Loopback0
ip address 10.10.1.6/32 ! interface Loopback1 ip address 10.10.2.6/32 |
- Define paths between the CloudEOS Routers and a load balancing policy for the ‘default’ VRF. We will also create a static route(s) for reachability to the Edge/Leaf VPC’s CloudEOS Routers. This static route will provide underlay reachability via the Ethernet100 interface utilizing DPS.
| Edge1a | Edge1b | Leaf1a | Leaf1b | Leaf2a | Leaf2b |
| router path-selection
path-group East-West local interface Ethernet1 ! peer static router-ip 10.10.1.3 ipv4 address 111.2.0.2 ! peer static router-ip 10.10.1.4 ipv4 address 111.2.2.2 ! peer static router-ip 10.10.1.5 ipv4 address 112.2.0.2 ! peer static router-ip 10.10.1.6 ipv4 address 112.2.2.2 ! load-balance policy East-West path-group East-West ! policy East-West default-match load-balance East-West ! vrf default path-selection-policy East-West ! ip route 10.10.1.3/32 10.10.10.254 ip route 10.10.1.4/32 10.10.10.254 ip route 10.10.1.5/32 10.10.10.254 ip route 10.10.1.6/32 10.10.10.254 |
router path-selection
path-group East-West local interface Ethernet1 ! peer static router-ip 10.10.1.3 ipv4 address 111.2.0.2 ! peer static router-ip 10.10.1.4 ipv4 address 111.2.2.2 ! peer static router-ip 10.10.1.5 ipv4 address 112.2.0.2 ! peer static router-ip 10.10.1.6 ipv4 address 112.2.2.2 ! load-balance policy East-West path-group East-West ! policy East-West default-match load-balance East-West ! vrf default path-selection-policy East-West ! ip route 10.10.1.3/32 10.10.10.254 ip route 10.10.1.4/32 10.10.10.254 ip route 10.10.1.5/32 10.10.10.254 ip route 10.10.1.6/32 10.10.10.254 |
router path-selection
path-group East-West local interface Ethernet1 ! peer static router-ip 10.10.1.1 ipv4 address 110.2.0.2 ! peer static router-ip 10.10.1.2 ipv4 address 110.2.2.2 ! load-balance policy East-West path-group East-West ! policy East-West default-match load-balance East-West ! vrf default path-selection-policy East-West ! ip route 10.10.1.1/32 10.10.10.254 ip route 10.10.1.2/32 10.10.10.254 |
router path-selection
path-group East-West local interface Ethernet1 ! peer static router-ip 10.10.1.1 ipv4 address 110.2.0.2 ! peer static router-ip 10.10.1.2 ipv4 address 110.2.2.2 ! load-balance policy East-West path-group East-West ! policy East-West default-match load-balance East-West ! vrf default path-selection-policy East-West ! ip route 10.10.1.1/32 10.10.10.254 ip route 10.10.1.2/32 10.10.10.254 |
router path-selection
path-group East-West local interface Ethernet1 ! peer static router-ip 10.10.1.1 ipv4 address 110.2.0.2 ! peer static router-ip 10.10.1.2 ipv4 address 110.2.2.2 ! load-balance policy East-West path-group East-West ! policy East-West default-match load-balance East-West ! vrf default path-selection-policy East-West ! ip route 10.10.1.1/32 10.10.10.254 ip route 10.10.1.2/32 10.10.10.254 |
router path-selection
path-group East-West local interface Ethernet1 ! peer static router-ip 10.10.1.1 ipv4 address 110.2.0.2 ! peer static router-ip 10.10.1.2 ipv4 address 110.2.2.2 ! load-balance policy East-West path-group East-West ! policy East-West default-match load-balance East-West ! vrf default path-selection-policy East-West ! ip route 10.10.1.1/32 10.10.10.254 ip route 10.10.1.2/32 10.10.10.254 |
- The CloudEOS instances we provisioned only support a single Ethernet interface in the same VPC due to GCP limitation. We will utilize the ‘default’ VRF as the Ethernet1 interface cannot reside in a non-default VRF for DPS. Ethernet1 interfaces on all the CloudEOS instances comes up as a DHCP client with the statically reserved IP that we assigned based on our topology. We will change the IP to static and as a result statically create the default route which would be installed as ‘DHCP client installed default route’.
| Edge1a | Edge1b | Leaf1a | Leaf1b | Leaf2a | Leaf2b |
| interface Ethernet1
mtu 1460 no switchport ip address 110.2.0.2/24 ! ip route 0.0.0.0/0 110.2.0.1 |
interface Ethernet1
mtu 1460 no switchport ip address 110.2.2.2/24 ! ip route 0.0.0.0/0 110.2.2.1 |
interface Ethernet1
mtu 1460 no switchport ip address 111.2.0.2/24 ! ip route 0.0.0.0/0 111.2.0.1 |
interface Ethernet1
mtu 1460 no switchport ip address 111.2.2.2/24 ! ip route 0.0.0.0/0 111.2.2.1 |
interface Ethernet1
mtu 1460 no switchport ip address 112.2.0.2/24 ! ip route 0.0.0.0/0 112.2.0.1 |
interface Ethernet1
mtu 1460 no switchport ip address 112.2.2.2/24 ! ip route 0.0.0.0/0 112.2.2.1 |
- Enable routing protocols model multi-agent for EVPN address-family support with this command:
service routing protocols model multi-agent.
Reload all the CloudEOS Routers.
- Define VXLAN interface, enable routing and configure BGP for the overlay.
| Edge1a | Edge1b | Leaf1a | Leaf1b | Leaf2a | Leaf2b |
| interface Vxlan1
vxlan source-interface Loopback0 vxlan udp-port 4789 vxlan vrf default vni 100 ! ip routing ! ip prefix-list to-be-advertised seq 10 permit 10.10.2.1/32 seq 20 permit 10.10.2.3/32 seq 30 permit 111.2.1.0/24 seq 40 permit 10.10.2.4/32 seq 50 permit 111.2.3.0/24 seq 60 permit 10.10.2.5/32 seq 70 permit 112.2.1.0/24 seq 80 permit 10.10.2.6/32 seq 90 permit 112.2.3.0/24 ! route-map allow-out permit 10 match ip address prefix-list to-be-advertised set community 10:10 ! router bgp 65100 router-id 10.10.1.1 distance bgp 20 200 200 maximum-paths 16 neighbor OverlayLeafs peer group neighbor OverlayLeafs remote-as 65100 neighbor OverlayLeafs update-source Loopback0 neighbor OverlayLeafs bfd neighbor OverlayLeafs send-community extended neighbor OverlayLeafs maximum-routes 12000 neighbor 10.10.1.3 peer group OverlayLeafs neighbor 10.10.1.3 remote-as 65100 neighbor 10.10.1.4 peer group OverlayLeafs neighbor 10.10.1.4 remote-as 65100 neighbor 10.10.1.5 peer group OverlayLeafs neighbor 10.10.1.5 remote-as 65100 neighbor 10.10.1.6 peer group OverlayLeafs neighbor 10.10.1.6 remote-as 65100 ! address-family evpn neighbor OverlayLeafs activate ! address-family ipv4 no neighbor OverlayLeafs activate network 10.10.2.1/32 ! vrf default rd 10.10.1.1:100 route-target import evpn 65100:100 route-target import evpn 65100:200 route-target export evpn 65100:1000 route-target export evpn route-map allow-out route-target export evpn imported-route |
interface Vxlan1
vxlan source-interface Loopback0 vxlan udp-port 4789 vxlan vrf default vni 100 ! ip routing ! ip prefix-list to-be-advertised seq 10 permit 10.10.2.1/32 seq 20 permit 10.10.2.3/32 seq 30 permit 111.2.1.0/24 seq 40 permit 10.10.2.4/32 seq 50 permit 111.2.3.0/24 seq 60 permit 10.10.2.5/32 seq 70 permit 112.2.1.0/24 seq 80 permit 10.10.2.6/32 seq 90 permit 112.2.3.0/24 ! route-map allow-out permit 10 match ip address prefix-list to-be-advertised set community 10:10 ! router bgp 65100 router-id 10.10.1.2 distance bgp 20 200 200 maximum-paths 16 neighbor OverlayLeafs peer group neighbor OverlayLeafs remote-as 65100 neighbor OverlayLeafs update-source Loopback0 neighbor OverlayLeafs bfd neighbor OverlayLeafs send-community extended neighbor OverlayLeafs maximum-routes 12000 neighbor 10.10.1.3 peer group OverlayLeafs neighbor 10.10.1.3 remote-as 65100 neighbor 10.10.1.4 peer group OverlayLeafs neighbor 10.10.1.4 remote-as 65100 neighbor 10.10.1.5 peer group OverlayLeafs neighbor 10.10.1.5 remote-as 65100 neighbor 10.10.1.6 peer group OverlayLeafs neighbor 10.10.1.6 remote-as 65100 ! address-family evpn neighbor OverlayLeafs activate ! address-family ipv4 no neighbor OverlayLeafs activate network 10.10.2.1/32 ! vrf default rd 10.10.1.2:100 route-target import evpn 65100:100 route-target import evpn 65100:200 route-target export evpn 65100:1000 route-target export evpn route-map allow-out route-target export evpn imported-route |
interface Vxlan1
vxlan source-interface Loopback0 vxlan udp-port 4789 vxlan vrf default vni 100 ! ip routing ! ip prefix-list to-be-advertised seq 10 permit 111.2.1.0/24 seq 20 permit 10.10.2.3/32 ! ip route 111.2.1.0/24 111.2.0.1 ! route-map allow-out permit 10 match ip address prefix-list to-be-advertised ! router bgp 65100 router-id 10.10.1.3 distance bgp 20 200 200 maximum-paths 16 neighbor OverlayEdges peer group neighbor OverlayEdges remote-as 65100 neighbor OverlayEdges update-source Loopback0 neighbor OverlayEdges bfd neighbor OverlayEdges send-community extended neighbor OverlayEdges maximum-routes 12000 neighbor 10.10.1.1 peer group OverlayEdges neighbor 10.10.1.2 peer group OverlayEdges ! address-family evpn neighbor OverlayEdges activate ! address-family ipv4 no neighbor OverlayEdges activate network 10.10.2.3/32 network 111.2.1.0/24 ! vrf default rd 10.10.1.3:100 route-target import evpn 65100:1000 route-target export evpn 65100:100 route-target export evpn route-map allow-out |
interface Vxlan1
vxlan source-interface Loopback0 vxlan udp-port 4789 vxlan vrf default vni 100 ! ip routing ! ip prefix-list to-be-advertised seq 10 permit 111.2.3.0/24 seq 20 permit 10.10.2.4/32 ! ip route 111.2.3.0/24 111.2.2.1 ! route-map allow-out permit 10 match ip address prefix-list to-be-advertised ! router bgp 65100 router-id 10.10.1.4 distance bgp 20 200 200 maximum-paths 16 neighbor OverlayEdges peer group neighbor OverlayEdges remote-as 65100 neighbor OverlayEdges update-source Loopback0 neighbor OverlayEdges bfd neighbor OverlayEdges send-community extended neighbor OverlayEdges maximum-routes 12000 neighbor 10.10.1.1 peer group OverlayEdges neighbor 10.10.1.2 peer group OverlayEdges ! address-family evpn neighbor OverlayEdges activate ! address-family ipv4 no neighbor OverlayEdges activate network 10.10.2.4/32 network 111.2.3.0/24 ! vrf default rd 10.10.1.4:100 route-target import evpn 65100:1000 route-target export evpn 65100:100 route-target export evpn route-map allow-out |
interface Vxlan1
vxlan source-interface Loopback0 vxlan udp-port 4789 vxlan vrf default vni 100 ! ip routing ! ip prefix-list to-be-advertised seq 10 permit 112.2.1.0/24 seq 20 permit 10.10.2.5/32 ! ip route 112.2.1.0/24 112.2.0.1 ! route-map allow-out permit 10 match ip address prefix-list to-be-advertised ! router bgp 65100 router-id 10.10.1.5 distance bgp 20 200 200 maximum-paths 16 neighbor OverlayEdges peer group neighbor OverlayEdges remote-as 65100 neighbor OverlayEdges update-source Loopback0 neighbor OverlayEdges bfd neighbor OverlayEdges send-community extended neighbor OverlayEdges maximum-routes 12000 neighbor 10.10.1.1 peer group OverlayEdges neighbor 10.10.1.2 peer group OverlayEdges ! address-family evpn neighbor OverlayEdges activate ! address-family ipv4 no neighbor OverlayEdges activate network 10.10.2.5/32 network 112.2.1.0/24 ! vrf default rd 10.10.1.5:100 route-target import evpn 65100:1000 route-target export evpn 65100:100 route-target export evpn route-map allow-out |
interface Vxlan1
vxlan source-interface Loopback0 vxlan udp-port 4789 vxlan vrf default vni 100 ! ip routing ! ip prefix-list to-be-advertised seq 10 permit 112.2.3.0/24 seq 20 permit 10.10.2.6/32 ! ip route 112.2.3.0/24 112.2.2.1 ! route-map allow-out permit 10 match ip address prefix-list to-be-advertised ! router bgp 65100 router-id 10.10.1.6 distance bgp 20 200 200 maximum-paths 16 neighbor OverlayEdges peer group neighbor OverlayEdges remote-as 65100 neighbor OverlayEdges update-source Loopback0 neighbor OverlayEdges bfd neighbor OverlayEdges send-community extended neighbor OverlayEdges maximum-routes 12000 neighbor 10.10.1.1 peer group OverlayEdges neighbor 10.10.1.2 peer group OverlayEdges ! address-family evpn neighbor OverlayEdges activate ! address-family ipv4 no neighbor OverlayEdges activate network 10.10.2.6/32 network 112.2.3.0/24 ! vrf default rd 10.10.1.36100 route-target import evpn 65100:1000 route-target export evpn 65100:100 route-target export evpn route-map allow-out |
Please note that we’ve had to explicitly accept and advertise the prefixes to / from Leaf CloudEOS instances at the Edge layer only because we are using the ‘default’ VRF. Routes in default VRF are not exported until an explicit route-map allowing routes to get exported is not configured.