There are two types of access lists in Cisco SD-WAN. As seen in the previous lesson, transport interfaces have implicit access lists applied by default, called services. The access lists that we configure using localized data policy are referred to as explicit access lists. We apply an explicit ACL per interface on a vEdge router in either inbound or outbound direction. Explicit access lists are just like regular ACLs that network engineers have seen and used extensively in traditional IOS routing.

Explicit ACL
Figure 1. Explicit ACL

Configuring an Explicit ACL

In this lab lesson, we are going to deny TELNET traffic coming inbound on vEdge-1’s interface ge0/5. To achieve this objective, we will create a new ACL that matches TELNET traffic and denies it, as illustrated in figure 1 above. All other IP traffic will be permitted.

The Initial State

The lab topology that we are going to use in this lesson is as follows:

Denying TELNET originating from CORE-SW1
Figure 2. Denying TELNET originating from CORE-SW1

Before we begin, let’s first verify that TELNET is successful from CORE-SW1 to SITE-3 Router-1 (

CORE-SW1# telnet
Trying ... Open

User Access Verification

Username: cisco

Configuring a Localized Data Policy

OK, now let’s configure a new ACL named DENY-TELNET that matched destination port 23 and sets an action “drop”.

 access-list DENY-TELNET
  sequence 11
    destination-port 23
   action drop
  default-action accept

Once the ACL is configured, we apply it on vEdge-1’s interface ge0/5 in the inbound direction.

vpn 5
 interface ge0/5
  ip address
  no shutdown
  access-list DENY-TELNET in

Now if we try to telnet from CORE-SW1 to SITE3-R1, we will see that it is not successful because the traffic is dropped by the explicit ACL applied on vEdge-1’s interface ge0/5.

CORE-SW1# telnet
Trying ... 
% Destination unreachable; gateway or host down

Explicit ACL alongside Implicit ACL

Exclicit ACLs are a very straightforward concept that should be very easy to understand for experienced network engineers. However, a more interesting use case arises when data traffic matches both an implicit and an explicit ACL, as illustrated in figure 3 below. 

Explicit ACL alongside Implicit one
Figure 3. Explicit ACL alongside Implicit one

How the vEdge router would handle the data traffic depends primarily on whether the traffic matches an explicit ACL sequence or an explicit ACL default-action:

  • If the data traffic matches an explicit ACL sequence - the specified action is applied irrespective of the implicit ACL;
  • If the data traffic doesn’t match an explicit ACL sequence  - the implicit ACL’s action is applied irrespective of the explicit ACL default-action.

If we have both implicit and explicit ACL on a transport interface, the easiest way is to think about them as one combined access list. Allowing a service in the implicit ACL is analogous to specifying a match-action rule at the bottom of the explicit ACL just before the default action (highlighted in yellow). Then if data traffic doesn’t match any sequence in the explicit ACL but matches the implicit ACL, the explicit ACL’s default action is never triggered.

Full Content Access is for Registered Users Only (it's FREE)...

  • Learn any CCNA, DevNet or Network Automation topic with animated explanation.
  • We focus on simplicity. Networking tutorials and examples written in simple, understandable language for beginners.