Enterprise Networks TAC Workshop, 17-19 September 2019, Krakow

- Poland

Day 1, SD-WAN practical workshop

Workbook with some solutions

Based on dCloud Cisco SD-WAN (Viptela) troubleshooting lab v1.0

Workbook presented by EMEAR SD-WAN CX/TAC team:

Waqas Daar
Eugene Khabarov
Igor Omelyanyuk
and others
Table of Contents
Introduction ....................................................................................................................... 3
1. Control connections faults .............................................................................................. 5
1.1 Multiple certificates issues on BR3-CEDGE1 router. ......................................................... 5
Detailed steps to diagnose and recover............................................................................................................. 5
1.2 Control connections issue on DC2-VEDGE2 ................................................................... 19
1.3 Control connections issue on BR1-CEDGE2 ................................................................... 19
1.4 DC1-VEDGE1 can’t establish control connections........................................................... 19
2. Data plane tunnels connectivity issues ......................................................................... 20
2.1 DC2-VEDGE1 has no data place connections to any sites. ............................................... 20
Detailed solution with explanations.................................................................................................................20
2.2 BR2-VEDGE1 connectivity issues................................................................................. 25
2.3 No data plane tunnels over “mpls” color ...................................................................... 25
3. Centralized control policy faults ................................................................................... 26
3.1 Dangerous error in the control policy........................................................................... 26
3.2 Service insertion is not working .................................................................................. 26
3.3 Redundancy problems. .............................................................................................. 27
4. Data policy issues ......................................................................................................... 28
4.1 BR2-VEDGE1 can’t establish OSPF neighborship ............................................................ 28
5 Bonus. Other troubles. .................................................................................................. 29
5.1 BR3-CEDGE1 users complain about some applications. .................................................. 29
Introduction
This content includes preconfigured SD-WAN topology that contains numerous of faults.
Please note that each task should be completed in about 15 minutes on average.
Most components are fully configurable with predefined administrative user accounts. You
can see the IP address and user account credentials to use to access a component by
clicking the component icon in the Topology menu of your active session and in the scenario
steps that require their use.

The topology includes two Datacenters and two Remote Branches. The topology has three
different VPN/VRF Segments.
• Corporate VPN (VPN 10) Requires full mesh connectivity across ALL sites.
• IOT/PCI Segment (VPN 20) Requires Hub-n-Spoke between the DC and the Branches.
• GuestWifi (VPN 40) Not needed in the DCs. From the branches require DIA. No Site -
to-Site communications.

Note: OSPF is running in the DCs and Branch 2 in VPN 10. All other segments are using static
routing/VRRP.
Table 1. Device Addresses

Table 2. Host IPs for testing data plane connectivity

For best performance, connect to the workstation with Cisco AnyConnect VPN and the local
RDP client on your laptop.

Workstation 1: 198.18.133.36, Username: dcloud\administrator, Password: C1sco12345

vManage management address: https://198.18.1.10

Username:admin
Password:admin

Note: You can also connect to the workstation using the Cisco dCloud Remote Desktop
HTML5 client. The dCloud Remote Desktop client works best for accessing an active session
with minimal interaction. However, many users experience connection and performance
issues with this method.
1. Control connections faults
Please use “Troubleshooting Control Connections” article as a general help for this section.

1.1 Multiple certificates issues on BR3-CEDGE1 router.

Symptoms: BR3-CEDGE1 can’t establish control connections.

This is example of the complex misconfiguration consisting of multiple failures and will be
guided step by step.

Detailed steps to diagnose and recover

1. Check control connections history and observe that cEdge is even not trying to
establish control connections:
BR3-CEDGE1#show sdwan control connections

BR3-CEDGE1#show sdwan control connection-history

BR3-CEDGE1#

Even “debug platform software sdwan vdaemon misc high” won’t give any debugging
output. Usually it indicates that some mandatory parameters/configuration are/is missing
from the cEdge device.
 2. Check local-properties:
BR3-CEDGE1#show sdwan control local-properties
personality vedge
sp-organization-name Cisco Sy1 - 19968
organization-name
root-ca-chain-status Installed

certificate-status Not-Installed
certificate-validity Not Applicable
certificate-not-valid-before Not Applicable
certificate-not-valid-after Not Applicable

dns-name vbond.cisco.com
site-id 500
domain-id 1
protocol dtls
tls-port 0
system-ip 10.5.0.1
chassis-num/unique-id CSR-3299b46e-90cd-4c5b-bebb-b6babfd8e0b1
serial-num No certificate installed
keygen-interval 1:00:00:00
retry-interval 0:00:00:18
no-activity-exp-interval 0:00:00:12
dns-cache-ttl 0:00:02:00
port-hopped FALSE
time-since-last-port-hop 0:00:00:00
number-vbond-peers 0
number-active-wan-interfaces 3

Please note that “organization-name” is missing from the configuration, set it and check
control connections again:
BR3-CEDGE1#config-transaction

admin connected from 127.0.0.1 using console on BR3-CEDGE1

BR3-CEDGE1(config)# system
BR3-CEDGE1(config-system)# organization-name "Cisco Sy1 - 19968"
BR3-CEDGE1(config-system)# commit
The following warnings were generated:
'system is-vmanaged': This device is being managed by the vManage. Any
configuration
changes to this device will be overwritten by the vManage after the control
connection to
the vManage comes back up.
Proceed? [yes,no] yes
Commit complete.
BR3-CEDGE1(config-system)#
 3. Make sure that root-chain is installed on SDWAN-router and If you see that ‘root-ca-
chain-status’ set to ‘Not-Installed’, like on the screenshot below:
BR3-CEDGE1#show sdwan control local-properties
personality vedge
sp-organization-name Cisco Sy1 - 19968
organization-name
root-ca-chain-status Not-Installed

certificate-status Not-Installed
certificate-validity Not Applicable
certificate-not-valid-before Not Applicable
certificate-not-valid-after Not Applicable

dns-name vbond.cisco.com
site-id 500
domain-id 1
protocol dtls
tls-port 0
system-ip 10.5.0.1
chassis-num/unique-id CSR-3299b46e-90cd-4c5b-bebb-b6babfd8e0b1
serial-num No certificate installed
keygen-interval 1:00:00:00
retry-interval 0:00:00:18
no-activity-exp-interval 0:00:00:12
dns-cache-ttl 0:00:02:00
port-hopped FALSE
time-since-last-port-hop 0:00:00:00
number-vbond-peers 0
number-active-wan-interfaces 3

Then, we need to install the root-cert-chain first.

Note: root certificate chain can be found in ‘bootflash:/vmanage-admin/master_root.crt’

on SDWAN-Router (BR3-CEDGE1)

BR3-CEDGE1#request platform software sdwan root-cert-chain install

bootflash:/vmanage-admin/master_root.crt
Uploading root-ca-cert-chain via VPN 0
Copying ... /bootflash//vmanage-admin/master_root.crt via VPN 0
Successfully installed the root certificate chain

4. If you check control connections again now, you’ll notice that situation has not
improved, and we are still seen same as on STEP 1 – cEdge is not trying to initiate any
control connections.
 Let’s make sure that we have root-cert-chain is installed and certificate of the device
is installed, based on the below output from the cEdge (BR3-CEDGE1) we can see that
device certificate is not installed. We need to install the device certificate in order to
make control connection established.
BR3-CEDGE1#show sdwan control local-properties
personality vedge
sp-organization-name Cisco Sy1 - 19968
organization-name
root-ca-chain-status Installed

certificate-status Not-Installed
certificate-validity Not Applicable
certificate-not-valid-before Not Applicable
certificate-not-valid-after Not Applicable

dns-name vbond.cisco.com
site-id 500
domain-id 1
protocol dtls
tls-port 0
system-ip 10.5.0.1
chassis-num/unique-id CSR-3299b46e-90cd-4c5b-bebb-b6babfd8e0b1
serial-num No certificate installed
keygen-interval 1:00:00:00
retry-interval 0:00:00:18
no-activity-exp-interval 0:00:00:12
dns-cache-ttl 0:00:02:00
port-hopped FALSE
time-since-last-port-hop 0:00:00:00
number-vbond-peers 0
number-active-wan-interfaces 3

Note: Since we don’t have spare license on vManage for vEdge -cloud device, we need to
decommission existing device. By doing so, we will lose all template variables values, so it’s
good idea to backup them first.
Go to the vManage https://198.18.1.10 admin/admin

To save template variables values, follow vManage Path: Configuration -> Devices
For corresponding chassis number click on “…” and choose “Change Device Values”
BR3-CEDGE1#show sdwan control local-properties
...
chassis-num/unique-id CSR-3299b46e-90cd-4c5b-bebb-b6babfd8e0b1
...

Click arrow down button to export device template variables, also remember the template
name while saving values.
If you forget to save the template, there is a copy located in Downloads folder you can use to
return device into vManage mode from CLI mode:

Once you exported device template values, navigate to “Devices” page of vManage, find
corresponding chassis number and click “Decommission WAN Edge”:

Once the device is decommissioned vManage will prompt the message like below:
5. We need to generate the Bootstrap configuration again after the cEdge device is
decommissioned. We can click “…” and there is an option “Generate Bootstrap
Configuration” and after that select “Cloud-Init” format this will generate One Time
Password (OTP) for that chassis number like below:

6. Now we need to reactivate cEdge using chassis number and token received on
previous step using command “request platform software sdwan vedge_cloud
 activate chassis-number <uuid> token <otp>”. cEdge will finally establish control
connections:

*Sep 8 16:09:39.352: %Cisco-SDWAN-Router-OMPD-6-INFO-400002: R0/0: OMPD:

vSmart peer 12.12.12.12 state changed to Handsh ake
*Sep 8 16:09:39.352: %Cisco-SDWAN-Router-OMPD-6-INFO-400002: R0/0: OMPD:
vSmart peer 22.22.22.22 state changed to Handsh ake
*Sep 8 16:09:39.354: %Cisco-SDWAN-Router-OMPD-5-NTCE-400002: R0/0: OMPD:
vSmart peer 22.22.22.22 state changed to Up
*Sep 8 16:09:39.354: %Cisco-SDWAN-Router-OMPD-6-INFO-400005: R0/0: OMPD:
Number of vSmarts connected : 1
*Sep 8 16:09:39.354: %Cisco-SDWAN-Router-OMPD-5-NTCE-400002: R0/0: OMPD:
vSmart peer 12.12.12.12 state changed to Up
*Sep 8 16:09:39.354: %Cisco-SDWAN-Router-OMPD-6-INFO-400005: R0/0: OMPD:
Number of vSmarts connected : 2
*Sep 8 16:09:43.352: %Cisco-SDWAN-Router-OMPD-6-INFO-400007: R0/0: OMPD:
Using policy from peer 12.12.12.12

BR3-CEDGE1#show sdwan control connections

PEER PEER
CONTROLLER
PEER PEER PEER SITE DOMAIN PEER
PRIV PEER PUB
GROUP
TYPE PROT SYSTEM IP ID ID PRIVATE IP
PORT PUBLIC IP PORT LOCAL C OLOR PROXY
STATE UPTIME ID
---------------------------------------------------------------------------
---------------------------------------------- ----------------------------
-----------------------------------
vsmart dtls 12.12.12.12 10 1 198.18.1.12
12446 198.18.1.12 12446 biz -internet
up 0:00:01:15 0
vsmart dtls 22.22.22.22 20 1 198.18.1.22
12446 198.18.1.22 12446 biz -internet
up 0:00:01:15 0
vmanage dtls 10.10.10.10 10 0 198.18.1.10
12446 198.18.1.10 12446 biz -internet
up 0:00:01:15 0
7. Reattach the template “BranchType3Template-CSR” to the device and import device
variables from the CSV file saved in Step 2.
Navigate to “Templates” page find “BranchType3Template” click “…” and choose
“Attach Devices”:

Choose device from the list and click arrow “Right”:

Click “Attach”:

Now we need to choose CSV file, click arrow “UP”

“Choose File”:
When you choose the file click “Open” and then “Upload”:

Status is now green and we can click next:

If you choose device from this screen you will see configuration you are going to
apply:

“Config Diff” button to see difference from current config. Now you can click
“Configure Device”:
Now you will go through Config Validation->Updating Config and when it is finished
status will change to “Success”:
1.2 Control connections issue on DC2-VEDGE2
DC2-VEDGE2 can’t establish control place connectivity with controllers due to some issues
with certificate.

This task is not guided as contrast to previous one, try to find fault yourself and fix the
problem. If you experience difficulties and spent more than 15 minutes on this task, please
refer to solutions.

1.3 Control connections issue on BR1-CEDGE2

cEdge2 in the Branch1 can’t establish control connections.

Try to fix the issue using same techniques as described in 1.1. There are two problems. If
you spot difficulties, refer to the solution.

1.4 DC1-VEDGE1 can’t establish control connections

DC1-VEDGE1 can’t establish control connections due to some connectivity issues. Try to
resolve this problem on your own, if you stuck, refer to the soluti on in the solutions
workbook.
2. Data plane tunnels connectivity issues
Please use “Troubleshoot Bidirectional Forwarding Detection and Data Plane Connections
Issues” article as a general help for troubleshooting this section.

2.1 DC2-VEDGE1 has no data place connections to any sites.

DC2-VEDGE1 can’t establish data plane tunnels with any other sites/routers. Despite the fact
that control connections are established, we can’t establish any data plane tunnels.
DC2-VEDGE1# show control connections | tab

LOCAL
CFG V
PEER SITE DOMAIN LOCAL PRIVATE PUBLIC
REMOTE PRIVATE CONTROLLER SYSTEM ORG
BEHIND
INSTANCE TYPE ID ID PRIVATE IP PORT PUBLIC IP PORT
SYSTEM IP PROTOCOL LOCAL COLOR COLOR PRIVATE IP PORT STATE
UPTIME GROUP ID IP NAME PROXY
---------------------------------------------------------------------------
---------------------------------------------------------------------------
-------------------------------------------------
0 vsmart 10 1 10.2.254.2 12366 198.18.1.12 12446
12.12.12.12 dtls biz-internet default 198.18.1.12 12446 up
1:01:38:48 0 - - No
0 vsmart 20 1 10.2.254.2 12366 198.18.1.22 12446
22.22.22.22 dtls biz-internet default 198.18.1.22 12446 up
1:01:38:48 0 - - No
0 vbond 0 0 100.64.0.10 12426 198.18.1.11 12346
0.0.0.0 dtls mpls mpls 198.18.1.11 12346 connect
- 0 - - -
0 vmanage 10 0 10.2.254.2 12366 198.18.1.10 12446
10.10.10.10 dtls biz-internet default 198.18.1.10 12446 up
1:01:38:48 0 - - No

DC2-VEDGE1# show bfd sessions

DC2-VEDGE1#

Try to figure out the reason for that behavior yourself, but this lab task is guided.

Detailed solution with explanations

1. To be able to establish data place tunnel, Edge router should comply some
conditions. One of the most important is to have appropriate TLOCs announced and
received from the vSmart controller(s).
 2. From the output below we can see that we have OMP sessions established with both
the vSmarts:
DC2-VEDGE1# show omp peers
R -> routes received
I -> routes installed
S -> routes sent

DOMAIN OVERLAY SITE

PEER TYPE ID ID ID STATE UPTIME
R/I/S
---------------------------------------------------------------------------
---------------
12.12.12.12 vsmart 1 1 10 up 0:19:16:51
0/0/4
22.22.22.22 vsmart 1 1 20 up 0:19:16:51
0/0/4

DC2-VEDGE1#

3. If we check the TLOCs information which we received from the vSmart, we can see
that we only have local TLOC information available and we did not install remote
TLOCs and service routes in SD-WAN router.
DC2-VEDGE1# show omp tlocs
Code:
C -> chosen
I -> installed
Red -> redistributed
Rej -> rejected
L -> looped
R -> resolved
S -> stale
Ext -> extranet
Stg -> staged
Inv -> invalid

PUBLIC PRIVATE
PSEUDO
PUBLIC PRIVATE PUBLIC IPV6 PRIVATE IPV6 BFD
TLOC IP COLOR ENCAP FROM PEER STATUS KEY
PUBLIC IP PORT PRIVATE IP PORT IPV6 PORT IPV6
PORT STATUS
---------------------------------------------------------------------------
---------------------------------------------------------------------------
-------------------
10.2.0.1 biz-internet ipsec 0.0.0.0 C,Red,R 1
100.64.2.14 12366 10.2.254.2 12366 :: 0 ::
0 up

DC2-VEDGE1# show omp summary

oper-state UP
admin-state UP
personality vedge
omp-uptime 0:19:17:22
routes-received 4
routes-installed 0
routes-sent 8
tlocs-received 1
tlocs-installed 0
tlocs-sent 2
services-received 3
services-installed 0
services-sent 6
mcast-routes-received 0
mcast-routes-installed 0
mcast-routes-sent 0
hello-sent 6937
hello-received 6932
handshake-sent 2
handshake-received 2
alert-sent 0
alert-received 0
inform-sent 14
inform-received 14
update-sent 10
update-received 0
policy-sent 0
policy-received 0
total-packets-sent 6963
total-packets-received 6948
vsmart-peers 2
DC2-VEDGE1#

As we can see above, only locally originated TLOC is seen and we don’t see any TLOCs from
remote sites.

One of the possible reasons is the device certificate in the “Staging” state. As we know that
when a SD-WAN router is in staging state, the vSmart controller learns about the router and
learns routes from the router, but it does not advertise these routes to any other WAN Edge
router in the network. During the staging state, OMP does not send any routes, data policies,
or TLOCs to the WAN Edge router, hence no BFD tunnels are established.

So, let’s verify that if device is in staging stage or not.

And after moving certificate to “Valid”, we need to make sure that we Click “Send to
Controllers” button to update all the controllers.

Now, we can see TLOCs received and data plane tunnels established:

DC2-VEDGE1# show omp summary

oper-state UP
admin-state UP
personality vedge
omp-uptime 0:19:26:40
routes-received 112
routes-installed 16
routes-sent 8
tlocs-received 19
tlocs-installed 9
tlocs-sent 2
services-received 3
services-installed 0
services-sent 6
mcast-routes-received 0
mcast-routes-installed 0
mcast-routes-sent 0
hello-sent 6997
hello-received 6986
handshake-sent 4
handshake-received 4
alert-sent 0
alert-received 0
inform-sent 20
inform-received 20
update-sent 24
update-received 68
policy-sent 0
policy-received 0
total-packets-sent 7045
total-packets-received 7078
vsmart-peers 2

DC2-VEDGE1# show omp tlocs received | tab

C -> chosen
I -> installed
Red -> redistributed
Rej -> rejected
L -> looped
R -> resolved
S -> stale
Ext -> extranet
Stg -> staged
Inv -> invalid

PUBLIC PRIVATE
ADDRESS PSEUDO
PUBLIC PRIVATE PUBLIC IPV6 PRIVATE IPV6 BFD
FAMILY TLOC IP COLOR ENCAP FROM PEER STATUS KEY PUBLIC
IP PORT PRIVATE IP PORT IPV6 PORT IPV6 PORT STATUS
---------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------
ipv4 10.1.0.1 biz-internet ipsec 12.12.12.12 C,I,R 1
100.64.2.26 12346 100.64.2.26 12346 :: 0 :: 0 up
22.22.22.22 C,R 1
100.64.2.26 12346 100.64.2.26 12346 :: 0 :: 0 up
10.1.0.2 biz-internet ipsec 12.12.12.12 C,I,R 1
100.64.2.30 12406 100.64.2.30 12406 :: 0 :: 0 up
22.22.22.22 C,R 1
100.64.2.30 12406 100.64.2.30 12406 :: 0 :: 0 up
10.2.0.1 biz-internet ipsec 0.0.0.0 C,Red,R 1
100.64.2.14 12366 10.2.254.2 12366 :: 0 :: 0 up
10.2.0.2 biz-internet ipsec 12.12.12.12 C,I,R 1
100.64.2.14 18628 10.2.254.6 12366 :: 0 :: 0 down
22.22.22.22 C,R 1
100.64.2.14 18628 10.2.254.6 12366 :: 0 :: 0 down
10.3.0.1 biz-internet ipsec 12.12.12.12 C,I,R 1
100.64.2.2 5062 100.64.2.38 12386 :: 0 :: 0 down
22.22.22.22 C,R 1
100.64.2.2 5062 100.64.2.38 12386 :: 0 :: 0 down
10.3.0.2 biz-internet ipsec 12.12.12.12 C,I,R 1
100.64.2.2 12346 100.64.2.2 12346 :: 0 :: 0 down
22.22.22.22 C,R 1
100.64.2.2 12346 100.64.2.2 12346 :: 0 :: 0 down
10.4.0.1 biz-internet ipsec 12.12.12.12 C,I,R 1
100.64.2.6 12366 100.64.2.6 Aborted: by user
DC2-VEDGE1#

DC2-VEDGE1# show bfd sessions

SOURCE TLOC REMOTE TLOC
DST PUBLIC DST PUBLIC DETECT TX
SYSTEM IP SITE ID STATE COLOR COLOR
SOURCE IP IP PORT
ENCAP MULTIPLIER INTERVAL(msec) UPTIME TRANSITIONS
---------------------------------------------------------------------------
---------------------------------------------------------------------------
-------------------------------------------------------
10.1.0.1 100 up biz-internet biz-internet
10.2.254.2 100.64.2.26 12346
ipsec 7 1000 0:00:03:08 0
10.1.0.2 100 up biz-internet biz-internet
10.2.254.2 100.64.2.30 12406
ipsec 7 1000 0:00:03:08 0
10.3.0.1 300 down biz-internet biz-internet
10.2.254.2 100.64.2.2 5062
ipsec 7 1000 NA 0
10.3.0.2 300 down biz-internet biz-internet
10.2.254.2 100.64.2.2 12346
ipsec 7 1000 NA 0
10.4.0.1 400 down biz-internet biz-internet
10.2.254.2 100.64.2.6 12366
ipsec 7 1000 NA 0
10.5.0.1 500 down biz-internet biz-internet
10.2.254.2 100.64.2.10 12346
ipsec 7 1000 NA 0
DC2-VEDGE1#
But still plenty of tunnels are in down state, which is expected and will be fixed in later section.

N.B. From here it might be good idea to jump to Section 3.1 and fix it, so all the data tunnels
are established.

2.2 BR2-VEDGE1 connectivity issues

BR2-VEDGE1 has no data plane tunnels established from ge0/5 interface with any other
routers except routers having “lte” color, although technically “lte” TLOC interface provides
full Internet connectivity.

Try to figure out what’s the problem and make sure BR2-VEDGE1 can establish data plane
tunnels with other routers having TLOC “biz-internet”.

2.3 No data plane tunnels over “mpls” color

All routers have no data plane tunnels established over “mpls” color. Please note that in this
scenario MPLS cloud has no internet connectivity. To be more precise, our MPLS L3 VPN
provider does not provide centralized internet breakout service .

Note: On MPLS-PE router you can find BGP neighbor is shut downed. You don’t need to fix
this!

Try to figure out what’s the reason yourself. Refer to solutions workbook if needed.
3. Centralized control policy faults

3.1 Dangerous error in the control policy

In section 2.1 we saw that some of the data tunnels are not established between sites on SD-
WAN routers ( DC2-VEDGE1, BR2-VEDGE1).

Hint: This may be caused by the centralized control policy.

Try to figure out what is the reason and refer to solutions workbook if needed.

3.2 Service insertion is not working

Firewalls are deployed in DC1 and DC2 for corporate VPN 10, so administrator configured
service insertion, but apparently it does not work.

Hint: The problem is caused by some mistakes in addressing. If issue is fixed, you should be
able to run traceroute from vManage:

With the following result:

Note: During attempt to get access to the Troubleshooting dashboard, you might see error
message regarding Data Stream activation requirement. Go to Administration -> Settings ->
Data Stream -> Enable. As hostname use System IP of vManage: 10.10.10.10, as VPN – 0.
3.3 Redundancy problems.
All Branches have requirement to redirect PCI VPN traffic to DC and have MPLS circuit as a
preferred path. It was reported that problem with connectivity from PCI VPN exists when
branches can't reach to DC1-VEDGE1 via MPLS color as was discovered during last
maintenance window when DC1-VEDGE1 was down for upgrade.

Hint: This problem is caused by control policy issues with “set tloc-list” action.
4. Data policy issues

4.1 BR2-VEDGE1 can’t establish OSPF neighborship

BR2-VEDGE1 OSPF neighborship on the service side is stuck in "Init"state.

Hint: from the section title we can guess that the problem is caused by some data policy
issues. Try to figure out what’s the problem.
5 Bonus. Other troubles.

5.1 BR3-CEDGE1 users complain about some applications.

This is one of real cases from the TAC life as well as most of the failures on the previous
sections, certainly. Users of Branch 3 report that SAP application times out if user is idle
longer than 2 minutes. If users performing any actions within the application requiring
network communication, SAP application works well and no problems observed.
Administrator suspects it caused by DIA configuration in this branch. Unfortunately, it’s late
in the night at the moment for Branch 3, so no users are using SAP application and live
troubleshooting is possible. Try to guess that’s the problem.