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.

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:

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

CORE-SW1# telnet 10.3.5.5
Trying 10.3.5.5 ... Open

User Access Verification

Username: cisco
Password: 
SITE3-R1>

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”.

policy
 access-list DENY-TELNET
  sequence 11
   match
    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 172.16.1.1/24
  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 10.3.5.5
Trying 10.3.5.5 ... 
% 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. 

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.