• Arista CloudEOS MultiCloud – CloudEOS Router in GCP Deployment Guide

 
 
Print Friendly, PDF & Email

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.

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.

Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: