<commit_before>---
published: true
date: '2018-07-12 16:34 +0200'
title: Security ACL on NCS5500 (Part1)
author: <NAME>
excerpt: First part of a series of posts on NCS5500 Access-lists
Top: null
position: top
---
{% include toc icon="table" title="NCS5500 Security Access-lists - Part1" %} 

You can find more content related to NCS5500 including routing in routing memory management, VRF, URPF, Netflow following this [link](https://xrdocs.io/cloud-scale-networking/tutorials/).

## Introduction

Let's talk about the "traditional" Security Access-List implementation on the NCS5500 series. In the near future, we will dedicate a separate post on the Hybrid-ACL (also known as Scale-ACL or Object-Based-ACL). 

While compressed / scaled-ACL are only supported on -SE systems (with external TCAM), the traditional security ACL can be configured on all systems and line cards of the NCS5500 portfolio. They are available in ingress, egress, for IPv4, IPv6 and L2.

Please note: won’t cover access-list used for route-filtering in this document, nor we will talk about Access-list Based Forwarding or SPAN (packet capture / replication) based on ACL either. We only intend to present security ACL used for packets filtering.


## Basic notions on ACLs

Security Access-Lists are used to protect the router or the infrastructure by matching the fields in the packets headers and applying filters.

An access-list is configured under on interface statement. It contains an protocol-type, an ACL identifier (or name) and a direction.

![acl-format2.png]({{site.baseurl}}/images/acl-format2.png)

An access-list is composed of one or multiple access-list entries (ACEs). 

When defining an ACL, the first line if made of a protocol-type (L2, v4 or v6) and of the name used to call it under the inferfaces. The following lines are representing the Access-list Entries (ACEs).

![ACE-ACL3.png]({{site.baseurl}}/images/ACE-ACL3.png)<commit_msg>Update security-acl-on-ncs5500-part1.md<commit_after>---
published: true
date: '2018-07-12 16:34 +0200'
title: Security ACL on NCS5500 (Part1)
author: <NAME>
excerpt: First part of a series of posts on NCS5500 Access-lists
Top: null
position: top
---
{% include toc icon="table" title="NCS5500 Security Access-lists - Part1" %} 

You can find more content related to NCS5500 including routing memory management, VRF, URPF, Netflow following this [link](https://xrdocs.io/cloud-scale-networking/tutorials/).

## Introduction

Let's talk about the "traditional" Security Access-List implementation on the NCS5500 series. In the near future, we will dedicate a separate post on the Hybrid-ACL (also known as Scale-ACL or Object-Based-ACL). 

While compressed / scaled-ACL are only supported on -SE systems (with external TCAM), the traditional security ACL can be configured on all systems and line cards of the NCS5500 portfolio. They are available in ingress, egress, for IPv4, IPv6 and L2.

Please note: won’t cover access-list used for route-filtering in this document, nor we will talk about Access-list Based Forwarding or SPAN (packet capture / replication) based on ACL either. We only intend to present security ACL used for packets filtering.


## Basic notions on ACLs

Security Access-Lists are used to protect the router or the infrastructure by matching the fields in the packets headers and applying filters.

An access-list is configured under on interface statement. It contains an protocol-type, an ACL identifier (or name) and a direction.

![acl-format2.png]({{site.baseurl}}/images/acl-format2.png)

An access-list is composed of one or multiple access-list entries (ACEs). 

When defining an ACL, the first line if made of a protocol-type (L2, v4 or v6) and of the name used to call it under the inferfaces. The following lines are representing the Access-list Entries (ACEs).

![ACE-ACL3.png]({{site.baseurl}}/images/ACE-ACL3.png)
{'fraction_non_alphanumeric': 0.07902187902187902, 'fraction_numerical': 0.028056628056628057, 'mean_word_length': 4.496463932107496, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 5, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4928405', 'n_tokens_mistral': 1193, 'n_tokens_neox': 1072, 'n_words': 524}