Translated from Indonesian to English - www.onlinedoctranslator.

com

Aruba SD-WAN LAB

By Dimas Rudi Saputra

DIMAS RUDI SAPUTRA 1

 List of contents
Lab Topology A .................................................. ................................................................ ................................................3

vSwith settings in ESXi ............................................ ................................................................ ............................3

Port Group Settings in ESXi ............................................ ................................................................ .....................3

VM Orchestrator Settings................................................ ................................................................ .........................4

ECV-1 VM Settings............................................ ................................................................ .........................................4

ECV-2 and ECV-3 VM Settings ......................................... ................................................................ ....................4

ECV-4 and ECV-5 VM Settings.................................................. ................................................................ ....................5

K1-MPLS VM Settings ................................................. ................................................................ ................................5

K2-Internet VM Settings ............................................ ................................................................ ..........................5

K3-LTE VM Settings.................................................. ................................................................ ...................................6

TG-1011 VM Settings ............................................ ................................................................ ...................................6

TG-2011 VM Settings ................................................. ................................................................ ...................................6

TG-3511 VM Settings ................................................. ................................................................ ...................................6

TG-11411 VM Settings.................................................. ................................................................ ...................................7

LAB 1 Orchestrator Configuration ................................................ ................................................................ ...................8

LAB 2 Configuring Groups, Group Templates and Interface Labels in Orchestrator........................... 11

LAB 3 Deployment Profile Configuration ................................................. ................................................................ .....14

LAB 4 Adding EdgeConnect to Orchestrator............................................ ................................ 15

LAB 5 Discover EdgeConnect to Orchestrator ............................................ ......................................... 17

LAB 6 HA EdgeConnect configuration between ECV-2 and ECV-3 ..................................... ...................29

LAB 7 EdgeConnect ECV-2 VRRP Configuration............................................ ................................................ 31

LAB 8 Configure master VRRP metric to be preferred route ......................................... ....... 32

LAB 9 Configure default gateway in TG-2011 to VRRP IP ...................................... ........................ 34

LAB 10 Traditional HA Configuration............................................ ................................................................ ............ 36

LAB 11 Default gateway configuration for TG-3511 ......................................... ................................... 38

LAB 12 Schedule Report Configuration.................................................. ................................................................ ........ 39

Lab B Topology .................................................. ................................................................ ................................................ 41

LAB 13 Zero Touch Appliance Configuration ............................................ ................................................ 42

LAB 14 Loopback Orchestrator Interface Configuration ............................................ .......................... 44

LAB 15 Local Internet Breakout Configuration............................................ ................................................ 46

LAB 16 OSPF Configuration.............................................. ................................................................ ............................. 54

LAB 17 BGP Configuration.............................................. ................................................................ ................................. 57

LAB 18 Route Map Configuration .................................................. ................................................................ ................... 64

DIMAS RUDI SAPUTRA 2

 Topology Lab A

vSwith settings in ESXi

Port Group Settings in ESXi

DIMAS RUDI SAPUTRA 3

 VM Orchestrator settings

ECV-1 VM Setup

ECV-2 and ECV-3 VM settings

DIMAS RUDI SAPUTRA 4

ECV-4 and ECV-5 VM settings

K1-MPLS VM Settings

K2-Internet VM Settings

DIMAS RUDI SAPUTRA 5

K3-LTE VM Settings

TG-1011 VM Setup

TG-2011 VM Setup

TG-3511 VM Setup

DIMAS RUDI SAPUTRA 6

TG-11411 VM Setup

DIMAS RUDI SAPUTRA 7

 LAB 1
Orchestrator Configuration

• Console to VM Orchestrator, then loginadmin/admin

• Fill in the parameters below

• Run command./gms/orch-setup -c,enter the root passwordSpeak-123, then fill in the

parameters as follows:
a. Timezone: n
b. NTP server: y
c. NTP server (IP/name): 192.168.1.151 (optional)
d. Change network configuration and hostname via GUI: n
e. Change Orchestrator hostname: n lower case
f. Change IP address: y
g. IP address: 192.168.1.254 (optional)
h. Netmask: 255.255.255.0 (optional)
i. Gateway: 192.168.1.253 (optional)
j. Change DNS servers: y
k. DNS Server 1: 8.8.8.8 (optional)
l. DNS Server 2: Leave blank. Press the Enter key.

DIMAS RUDI SAPUTRA 8

 Then access the orchestrator via browser, inputadmin/admin

• Generate Account name and Account Key for orchestrator and EdgeConnect Appliance, which
are used to register Orchestrator EdgeConnect Appliance with Cloud Portal using the same
account name and key

• When you first log in to the orchestrator, a configuration dialog box appears which must be filled in
according to the specified parameters, Select ProductEdgeConnect – Go to the License and
Registration menu, then enterAccount name and Account Keywhich was generated earlier.
• After enteringAccount name and Account Keyclick next, then fill in the parameters as
follows:
a. Enable SSL: Not selected
b. Enable Authentication: Selected
c. SMTP Server: 192.168.1.200 (optional)
d. SMTP Users:[email protected] (optional)
e. Email Sender:[email protected] (optional)
f. SMTP Password: Speak-123 (optional)
g. Server Ports: 25
h. Require Email Verification: Not selected
i. Send a Test Email to: [email protected] (optional)
j. Email Alarms to:[email protected] (optional)
• Clicknext, then fill in the next parameters as follows:
a. Protocol: FTP
b. Hostname: 192.168.1.200
c. Username: anonymous
d. Password: Speak-123
e. Directory: /GMS
f. Ports: 21
g. Max backups to retain: 3

DIMAS RUDI SAPUTRA 9

• Clicknext, then fill in the next parameters as follows:
a. Frequency: Weekly
b. Day: Saturday
c. Time: 08:00
d. Date: Current date
• After everything is filled in, then apply and close
• Turn off software release
Orchestrator – Software & Setup – Setup – Advanced Properties

• Verify orchestrator registration status

Orchestrator – Orchestrator Server – Licensing – Cloud Portal

DIMAS RUDI SAPUTRA 10

 LAB 2
Configuring Groups, Group Templates and Interface Labels in Orchestrator

• To configure the group, right click the appliance then enter the group name, here we fill in the group according to
the site name.

• After configuring the group, then configure the label, to create a new label, clicknew label
then fill in the parametersWANorLANby fillinglabel name and topology.

DIMAS RUDI SAPUTRA 11

• After configuring the Group and Interface labels, next configure the group template. Group
Templates are the mechanism we use to configure multiple settings for an EdgeConnect
appliance, and then apply those settings simultaneously to multiple appliances. Each
template containsactive templateswhich you can choose from the listavailable templates.

• Drag and drop the input template toavailable templatesfor the following parameters:
a. SNMP
b. Admin Distance
c. Routes
d. Shaper
• Drag and drop the input template toactive templatesfor the following parameters:
a. DNS
b. Date/Time
c. User Management
d. Management Services
e. Session Management
• In active template configData/Time, input timezone information, NTP Server etc

• In active template configUser Management,fill in the passwordSpeak-123

DIMAS RUDI SAPUTRA 12

• In active template configSession Management, change autologout to 60 minutes

• Once everything has been configured, clickSave

DIMAS RUDI SAPUTRA 13

 LAB 3
Configure Deployment Profile

• Without a deployment profile it might take a lot of time when you first start discovering
EdgeConnect, because we have to create interface configuration parameters from the start

• Referring to the topology, here we will create a deployment profile as follows:

• Branch Office EdgeHA – MPLS

• Branch Office EdgeHA – Internet-LTE

• Datacenter – HA
 LAB 4
Added EdgeConnect to Orchestrator

• Before adding EdgeConnect to the orchestrator, the first thing we have to do is map
the MAC address settings of each connected interface to wan0, wan1, lan etc.

• The following are the MAC address interface settings for each EdgeConnect.

DIMAS RUDI SAPUTRA 15

• Add ECV-2 to the orchestrator, this method is the same for ECV-1 to ECV-5.
User inputadmin/adminby using ip mgmt, then enter the menuconfiguration
– Initial Config Wizard

• After entering the appropriate MAC address of each interface, thenEnter Account Name
and Account Key, then clickSave, then ECV will automatically reboot
• Do the same with ECV-3 to ECV-5
• Make sure that after rebooting, the VM status is normal and all ECVs can be accessed again

DIMAS RUDI SAPUTRA 16

 LAB 5
Discover EdgeConnect to Orchestrator

• To discover all ECVs that we have previously configured, clickAppliance Discovered

• We can see all the ECVs that we previously configured.

• Next, we do Approve for each ECV, then we have to enter several parameters. For other
ECVs, the method is the same, only the IP address and label parameters may be
different at each site.
Select the deployment profile according to the topology we have, and fill in the IP address, label, etc. information.

8
• Continue approving ECV-3, do the same with ECV-2

DIMAS RUDI SAPUTRA 19

DIMAS RUDI SAPUTRA 20
• Continue to approve ECV-4

DIMAS RUDI SAPUTRA 21

• Continue to approve ECV-5

DIMAS RUDI SAPUTRA 23

DIMAS RUDI SAPUTRA 24
• ECV status after approval from the orchestrator

• Tunnel status for each

ECV-1 site

DIMAS RUDI SAPUTRA 25

ECV-2

ECV-3

DIMAS RUDI SAPUTRA 26

ECV-4

ECV-5

DIMAS RUDI SAPUTRA 27

• Test link integration between ECV-5 to ECV-1

DIMAS RUDI SAPUTRA 28

 LAB 6
Configure HA EdgeConnect between ECV-2 and ECV-3

• Right click ECV-2 thenclick Deployment.

• Then select EdgeConnect HA, and select itHA Peernamely ECV-3 and appropriate interfacesHA
linkin the unused ECV-3.

• Then clickCacl link,so that the total inbound and outbound will be updated, then clicksave

DIMAS RUDI SAPUTRA 29

• An alert will appear after HA configuration, wait a few minutes until the alert disappears

• Change the site name for ECV-2 and ECV-3, To prevent unnecessary tunnels from being created
between two devices in EdgeConnect HA, you must create the same site name for each
appliance. This prevents Orchestrator from building an underlay tunnel between them. To
change the site name, each is configured in ECV2 and ECV3.

DIMAS RUDI SAPUTRA 30

 LAB 7
EdgeConnect ECV-2 VRRP configuration

• VRRP is configured when the HA and site name configuration has been done.
• Click the Mumbai group, so ECV-2 and ECV-3 are automaticblocked.
• ChooseConfiguration – Networking – VRRP

• On ECV-2 clickedit, fill in the parameters likegroup id, virtual-ipAndpriorities. In the VRRP
configuration, we make ECV-2 the Master by changing the priority to 254.

• Check the status of ECV-2 and ECV-3, there you will see the status of the HA interface and VLANs 100,101
and 102 will automatically be formed on ECV-2 and ECV-3 which will automatically be formed on the HA
interface (wan1.100, wan1.101 etc.) , the IP address will also be automatically configured with the subnet
169.254.1.x/30
• Both the ECV-2 and ECV-3 show interfaces labeled MPLS, LTE and Internet, one making
use of physical wan0 and wan1 connections, and the other using HA connections
(wan2.102, wan1.101, and wan1.100)

DIMAS RUDI SAPUTRA 31

• For incoming traffic to Site-2, we want the VRRP Master (ECV-2) to advertise the best metric for the
LAN subnet - 10.110.20.0/24. This can be done by configuring the metric on ECV-3 to 60, on ECV-2 it
will remain at the default of 50 and therefore will be the preferred route to the advertised LAN subnet.
ClickECV-3 – Configuration – Routing – Route–EditECV-3 section and change the value to 60

DIMAS RUDI SAPUTRA 32

• Verification after changing the metric in ECV-3, we can check from ECV-1 for prefix
10.110.20.0/24 which way to site-2, we can see from ECV-1 to go to prefix 10.110.20.0/24 via
ECV-2 which is has a metric of 50.

DIMAS RUDI SAPUTRA 33

 LAB 9
Configure the default gateway in TG-2011 to VRRP IP

• Because previously we configured VRRP on ECV-2 and ECV-3 towards the LAN, namely to TG-2011, we have
to change the TG-2011 gateway to VRRP IP, namely 10.110.20.100.
• We test ping toTG-1011AndTG-3511the results are ok, while we trace traffic via ECV-2

• Test failover by disabling the lan port on ECV-2, we can check the results when the lan interface on ECV-2 is
disabled, traffic passes via 10.110.20.102, namely ECV-3

DIMAS RUDI SAPUTRA 34

• Now we enable it again and test the results after we enable the LAN interface, the results we can
see is that traffic returns via ECV-2, namely 10.110.20.101

DIMAS RUDI SAPUTRA 35

 LAB 10
Traditional HA Configuration

• Site 3 - Santa Clara is a data center with ECV-4 and ECV-5 for traditional HA architecture.
Both applications have MPLS and WAN internet links. In this lab, we configure VRRP and
other settings that enable Traditional HA.
• We configuresite namefor ECV-4 and ECV—5 to be insite namethe same one

DIMAS RUDI SAPUTRA 36

• VRRP configuration on ECV-4 and ECV-5, on ECV-5preemptdisabled.

• As before, we make the ECV-5 metric 60 so that the preferred route from the LAN will go through
the VRRP Master, namely ECV-4.

• Verify ECV-1 and ECV-2 to prefix 10.110.35.0/24 via ECV-4

DIMAS RUDI SAPUTRA 37

 LAB 11
Default gateway configuration for TG-3511

• Change the default gateway on the TG-3511 to 10.110.35.100, namely the IP of the VRRP IP

• Verify ping and traceroute to TG-1011 and TG-2011 results are ok and traffic via ECV-4

DIMAS RUDI SAPUTRA 38

 LAB 12
Schedule Report configuration

• ClickAppliance tree, then searchSchedule & Run Reports.Then create a new report by clicking
New Report

• After that, fill in several parameters such as:

• Appliances in Report
• Email Recipients
• Traffic Type
• Application Chart
• Tunnel Chart
• Appliance Charts
• ClickSave

DIMAS RUDI SAPUTRA 39

• To run automatic or manual reports, you can useRun Scheduled Report orRun
Single Report with Customer Range

DIMAS RUDI SAPUTRA 40

Topology Lab B

DIMAS RUDI SAPUTRA 41

 LAB 13
Zero Touch Appliance Configuration

• Enter the menuPreconfigure Appliance – Click New – Fill in the Name – Checklist Auto Approve – Fill in the
Tag – Paste the YAML config – Click Validate – Click Save

• Double Click the batch fileASD Setupand wait until the process is complete

UTRA 42
• Once finished, check the progress in Preconfigure Appliance and clickRefresh.It takes 10-15
minutes for preconfiguration to complete.

• Verify that the orchestrator can communicate with the cloud portal and is registered

DIMAS RUDI SAPUTRA 43

 LAB 14
Configure the Loopback Orchestrator Interface

• The loopback interface in the orchestrator is the same as other loopback interfaces that
use /32 or others. Enter menuConfiguration – Networking – Loopback Orchestrator

Note : By default, subnet 10.0.0.0/24 is added to be allocated by Orchestrator for the loopback interface. So we have to
change it manually

• ClickLoopback pool – Edit IP Subnet – Click Update – Click Save

DIMAS RUDI SAPUTRA 44

• Verify loopback interface,Configuration – Networking – Loopback Interface

Note: Orchestrator automatically creates loopback interfaces on all appliances with /32, the results may or may not be sequential.
And lo20000 is automatically created by the orchestrator on each appliance along with the loopback IP address. Cannot edit loopback ip address

• Test the connection between the loopback interfaces, here is an example of a ping from ECV-1 to ECV-5

DIMAS RUDI SAPUTRA 45

 LAB 15
Local Internet Breakout Configuration

• When we have several types of traffic used towards the internet, and we don't want to
backhaul all the traffic to the site-3 data center, because this can increase latency and
use unnecessary bandwidth on our WAN link back to the data center.
• The solution is to configure a local internet breakout for service via a passthrough tunnel using
an interface that connects to the internet.
• Some traffic that matches DefaultOverlay will be backhauled to Site-3, where it can be
checked by the firewall if necessary.
• For example, LAB uses a UBU-1 host with network 10.110.xx which is isolated and not
connected to the internet
• The purpose of this lab is to configure Business Intent Overlay to break up traffic that does not match
the internet subnet on our network.
• Before configuring, we test the loopback connection between sites and see the traffic flow

DIMAS RUDI SAPUTRA 46

• Now we will try a ping test to the UBU-1 host, and see the results in the traffic flow

DIMAS RUDI SAPUTRA 47

• Now we check internet traffic
Enter menuConfiguration – Overlay&Security – Click Internet Traffic

Noted: internet subnet where the subnets listed in the table above are included in the internal subnet that will be sent via
overlay tunnel, while subnets that are not yet listed in the table will go to the external subnet and be considered external traffic
Internet

• From the table list above, the prefix 11.1.1.0 is not included in the list, but why is it not sent from one
of the WAN interfaces as a local internet breakout?
• Now we go intoBusiness Intent Overlay
EnterConfiguration – Overlay&Security – Business Intent Overlay

SAPUTRA 48
• If we look at the DefaultOverlay breakout overlay configuration, the preferred policy order column
only contains Backhaup via Overlay, while Internet Breakout (Break Out Locally) is not entered in
the column, it is still in the available column.
• So traffic to 11.1.1.11 drops because of this, if the backhaul fail policy will drop
• In this lab we will perform direct internet breakout from branches for traffic that matches the
RealTimes, CriticalApps and BulkApps overlays
• However, for DefaultOverlay we want to backhaul traffic from Site-1 and Site-2 by
going to the internet to our data center (which has a firewall on the internet
connection). If the connection to the data center is lost we want to allow Site-1 and
Site-2 to Breakout Locally uses their own local internet connection for
DefaultOverlay traffic
• Configure RealTimes Overlay, Critical Apps and BulkApps as follows:
• Enter the tableBusiness Intent Overlay
• ClickBackhaul Policyin columnBreakout Traffic to Internet & Cloud Services
• DragBrakout Locallyto the columnPreferred Policy Order, put it at the top
• Drag interfaceINET1toPrimary Column
• Do the same steps for the CriticalApps and BulkApps Overlays

DIMAS RUDI SAPUTRA 49

• If the RealTimes, CriticalApps and BulkApps Overlays have been configured, now configure the
DefaultOverlay Overlay. And if everything is finished with the configuration, clickSave and Apply Changes
to Overlays

DIMAS RUDI SAPUTRA 50

• Verify ping from TG-1011 to 11.1.1.11, then check traffic flow for prefix 11.1.1.11

Noted : Flow will go through the passthrough tunnel associated with the previous Overlay DefaultOverlay to the next-hop router WAN1 10.110.104.1.
And what needs to be understood in this case is that no route to the destination is required, because the next-hop router knows how
how to reach the source subnet

• When we check the route table on ECV-1 there is no prefix 11.1.1.11 or even a default route for
communication with that subnet.

DIMAS RUDI SAPUTRA 51

• Because there is no route to the destination then:
• Local Internet Breakout works well
• ECV-1 will take the second option and perform a breakout locally and will use the
INET1 interface to breakout the DefaultOverlay
• As a result, traffic will be sent to the next-hop router on WAN1 which knows how to reach the
destination subnet
• Now we will try to configure the default route on Site-3, so that traffic can be backhauled
according to what we want, we add the default route on ECV-5

• The results of the flow are as follows:

• From ECV-1 via DefaultOverlay tunnel to ECV-5

• Then the ECV-5 breakout flow exits using the DefaultOverlay Passtrough tunnel
• Traffic re-enters through the passthrough tunnel on ECV-5
• Then returned to ECV-1 via overlay tunnel (top 2 flows)

DIMAS RUDI SAPUTRA 52

• We will try adding a default route to ECV-4 with a metric of 50, and see the results that traffic
from ECV-1 will go through ECV-4 because the ECV-4 metric is better.

• We have tried the internet traffic lab that matches DefaultOverlay. When the ping echo request from
TG-1011 to UBU-1 is backhauled before being broken down by the device at Site-3
• Now we will try something else, namely we make sure that traffic that matches with different
overlays is split by the local machine rather than being backhauled first, by doing an FTP from the
TG-1011

• We can see that FTP traffic does not pass through ECV-4 or ECV-5 because the BulkApps Policy is
set to Breakout Locally in the first set and backhaul in the second set, and the overlay and tunnel
used are BulkApps not DefaultOverlay

DIMAS RUDI SAPUTRA 53

 LAB 16
OSPF configuration

• The appliance will advertise the learned subnet through subnet sharing between appliances to the ARUBA
AOS-CX switch and become the preferred path to optimize traffic.
• If the appliance is down, then routes will not be advertised to the ARUBA AOS-CX switches
and they will use their route tables to forward traffic accordingly.
• We will configure OSPF on ECV-2 and ECV-3
Click Site Mumbai (ECV-2 and ECV-3) blocked – Configuration – Networking – Routing – OSPF

DIMAS RUDI SAPUTRA 54

• Verify OSPF on ECV-2 and ECV-3

Note: EdgeConnect currently only supports one area, and we can see that the OSPF connection between ECV and AOS-CX neighbor status is Full

• Check the route on ECV-2 and ECV-3 to ensure that it receives route 10.110.20.0 from AOS-CX, if we
see cost 101, it is because the default link cost from the appliance is 1 while from AOS-CX it is 100

DIMAS RUDI SAPUTRA 55

• Check the route on the AOS-CX side, if we look at the OSPF neighbor status Full and there are 6 routes
learned from ECV-2 and ECV-3, with the default AD OSPF which is 110 and the default Subnet sharing metric
which is 50. You can also see the route from loopback interface

Note: Default route 0.0.0.0/0 is received from ECV-2 and ECV-3, and receives prefix 10.110.10.0/24 from Site-1 Singapore, which is Site-1
not OSPF configuration. Prefix received from Subnet Sharing, subnet shares are redistributed to OSPF by default

DIMAS RUDI SAPUTRA 56

 LAB 17
BGP configuration

• The appliance will advertise the subnet learned from subnet sharing between appliances to the router and
become the preferred path for traffic originating from the TG-3511 and TG-11411
• If the appliance is down, routes will not be advertised to the AOS-CX-3
• ECV-4 and ECV-5 use iBGP peering with AOS-CX-3
• Currently there are no appliances that have a route to the 10.110.35.0/24 subnet, only the AOS-
CX-3 has a route to 10.110.35.0/24
• We will configure BGP Peering on ECV-4 and ECV-5
Click Site Santa Clara (ECV-4 and ECV-5) blocked – Configuration – Networking – Routing – BGP

DIMAS RUDI SAPUTRA 57

• Check the BGP peer status on ECV-4 and ECV-5, if we check the peer details ECV-4 and ECV-5 receive
routes from AOS-CX-3 as many as 1 and from ECV to AOS-CX-3 advertise 9

DIMAS RUDI SAPUTRA 58

• We test ping from ECV-5 to TG-3511 to subnet 10.110.35.11

Note: Pings from ECV-5 to TG-3511 can now go directly via LAN0

DIMAS RUDI SAPUTRA 59

• Because subnet 10.110.35.0/24 is still in Site – 3 and has not been advertised to Site – 1 and Site
– 2, we will try to redistribute route 10.110.35.0/24 into the sharing subnet on the SD-WAN
Fabric, byedit redistribute route to SD-WAN fabricAndallow source Protocol BGPin
ECV04 and ECV-5

DIMAS RUDI SAPUTRA 60

Note: ECV-1, ECV-2 and ECV-3 receive update 10.110.35.0/24 from ECV-4 and ECV-5, at the same cost via SD-WAN Fabric

DIMAS RUDI SAPUTRA 61

• We will add AS-PATH information in ECV-1, ECV-2 and ECV-3 where the BGP route originates
after redistributing it to the sharing subnet.

• Verify on the AOS-CX-3 side

Noted : AOS-CX-3 advertises network 10.11.35.0/24 to ECV4 and ECV-5

DIMAS RUDI SAPUTRA 62

Note : AOS-CX-3 learns default route from SCV-4 and ECV-5 but prefers ECV-4 due to lower metrics

DIMAS RUDI SAPUTRA 63

 LAB 18
Route Map Configuration

• Route Maps controls the redistribution of routes between different routing protocols, in
EdgeConnect it means Subnet sharing (SD-WAN Fabric), BGP and OSPF
• Inbound Route Map controls what can potentially be distributed into SD-WAN and become
subnet sharing between EdgeConnect
• Outbound Route Map which controls what is being redistributed by EdgeConnect, for example
ECV-2 to other routing protocols such as OSPF or BGP by EdgeConnect
• Route maps that control distribution to other protocols can be found on the configuration page for
each protocol, both OSPF and BGP
• BGP is slightly different from OSPF because it contains inbound and outbound route maps per peer
• Metric configuration of subnet sharing into BGP, so that AOS-CX-3 is preferred over
ECV-5, by default BGP will allow all sources into BGP without any changes

DIMAS RUDI SAPUTRA 64

Note: From the configuration above, this means that all prefixes originating from the SD-WAN Fabric (local/static) and from local/static direct will be set
metric 70 towards BGP AOS-CX-3

DIMAS RUDI SAPUTRA 65

• Verify the BGP route on AOS-CX-3, make sure the best route changes only via ECV-5
10.110.114.102. And if we look at the routes on AOS-CX-3, there is only 1 route, namely
ECV-5, because the metric to ECV-4 has changed to 70 so it is not displayed in the routing
table.

• If we look at the routing table on AOS-CX-3, there is no route from TG-2011, namely 10.110.20.0/24.
In the ECV-4 and ECV-5 routing tables there is also no prefix 10.110.20.0/24, whereas when we check
the BGP route map it already allows OSPF.

DIMAS RUDI SAPUTRA 66

• Permit redistribution of OSPF into subnet sharing in ECV-2, this is done so that the prefix learned
from ospf in ECV-2 can be accepted by Site-3 which uses BGP
• If we check the ECV-2 route map for the default route map to subnet sharing for OSPF and
BGP statusdeny, so we have to change it toallow/permit.

DIMAS RUDI SAPUTRA 67

DIMAS RUDI SAPUTRA 68
• Verify all EdgeConnects, ensuring they have received prefix 10.110.20.0/24 from OSPF
Site-2

DIMAS RUDI SAPUTRA 69

• Verify ping from TG-1011 to TG-14111

Note: Because it has the same cost, traffic towards TG-14111 is load balanced and will exit randomly via the ECV-4 tunnel
and ECV-5 tunnels

Note: If we look at ECV-1 it has routes from all ECVs for the prefix 10.110.114.0/24, but ECV-1 only forwards traffic to ECV-4 and
ECV-5, this is because even though ECV-1 has all metrics of 50, the AD for the original subnet sharing is 10 which is better than
The AD of OSPF is 15

DIMAS RUDI SAPUTRA 70

• Next we provide a sharing subnet tag which is redistributed into OSPF by ECV-2, in this
way we can filter based on tags.

DIMAS RUDI SAPUTRA 71

• Now we verify at Site-3 by filtering all routes from OSPF, if we see there is a prefix 28/60
with route tag 999. This is a route originating from OSPF which has been shared by ECV-2
and ECV-3 via SDWAN via subnet sharing (10.110.10.0, 10.110.35.0, 10.110.114.0 and
loopb

DIMAS RUDI SAPUTRA 72

• Now we will configure the Route Map for the filter on OSPF tag 999 on ECV-2 and will
create a filter to prevent the route from being redistributed into the sharing subnet.

DIMAS RUDI SAPUTRA 73

DIMAS RUDI SAPUTRA 74
• Verify again at Site-3 – Santa Clara, if we look at the results, all prefixes with route tag 999
are no longer advertised

• Some scenarios that we have done:

• ECV-2 adds a 999 tag to subnet shares that are redistributed to OSPF domains
• AOS-CX-2 learns routes from ECV-2 and adds them to the routing table
• ECV-3 also learns routes from ECV-2 and adds them to the routing table
• ECV-3 processes routes learned from ECV-2 marked with tag 999 (originally learned
from ECV-4 and ECV-5) because it has learned them directly from AOS-CX-2
• Routes marked with the 999 tag will not be shared with other EdgeConnects via subnet
sharing
• ECV-3 allows routes learned from AOS-CX-2 as unsigned and advertises them into
the SD-WAN fabric via subnet sharing

• From the route results at Site-3, it can be concluded that the prefixes learned for subnets at
Site-3 are only learned from devices that are directly connected to that subnet.
- 10.110.107.0 learned via subnet sharing of ECV02 and ECV-3
- 10.110.20.35.0 learned via BGP from AOS-CX-3
- 10.110.20.0 learned via subnet sharing of ECV-2 and ECV-3
- Since ECV-2 and ECV-3 allow distributing to SD-WAN fabric, the prefix of AOS-CX-2 will
not be marked with tag 999
- 10.110.10.0 learned via subnet sharing from ECV-1
- AOS-CX-2 applies metric 100 on Gigabit interfaces for OSPF, and ECV uses metric 1 for
Gigabit interfaces

DIMAS RUDI SAPUTRA 75