Table des matières

Introduction

Conditions préalables

Exigences

Composants utilisés

Q. Pouvez-vous bloquer le trafic lié au CPU (tel qu’ICMP) destiné à une interface de bouclage via une liste de contrôle d’accès (ACL) ?

R. Non. Les listes de contrôle d’accès appliquées aux interfaces de bouclage ne bloquent pas le trafic destiné au plan de contrôle du routeur, c’est-à-dire le trafic ponté.

Introduction

Ce document décrit une limitation dans le blocage du trafic lié au CPU via une ACL application sur une Loopback interface.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

- Réseau étendu défini par logiciel (SD-WAN) Cisco

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

- C8000V version17.12.2

- vManage version 20.12.2

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Q. Pouvez-vous bloquer le trafic lié au processeur (tel que ICMP ) destiné à une Loopback interface via un Access Control List (ACL) ?

Remarque : Cette réponse s'applique aux routeurs Cisco IOS® en mode contrôleur, autonome et routage SD. Pour les périphériques en mode contrôleur, cette réponse s'applique aux listes de contrôle d'accès explicites dans la stratégie ou la configuration Cisco IOS.

R. Non. ACLs Appliqué aux Loopback interfaces, il ne bloque pas le trafic destiné au plan de contrôle du routeur, c’est-à-dire le trafic ponté.

En effet, le routeur, réalisant que tout trafic destiné à l'LoopbackIP est destiné au plan de contrôle, programme le matériel pour envoyer le trafic directement au processeur et contourner l'Loopbackinterface pour une efficacité optimale. Cela signifie que tout ce qui est appliqué à l'entrée de l'Loopbackinterface (par exemple, ACLs ) n'est pas déclenché puisque le trafic n'entre jamais techniquement dans l'Loopbackinterface. Vous pouvez vérifier la programmation matérielle à l'aide d'une Cisco Express Forwarding® (CEF) commande.

Edge#show ip route 10.0.0.1

Routing entry for 10.0.0.1/32

Known via "connected", distance 0, metric 0 (connected)

Routing Descriptor Blocks:

* directly connected, via Loopback1

Route metric is 0, traffic share count is 1

Edge#show ip cef exact-route 172.16.0.1 10.0.0.1 protocol 1

172.16.0.1 -> 10.0.0.1 =>receive <<< no mention of Loopback1

Si nous prenons une trace FIA sur un paquet ping, nous voyons que le trafic est envoyé au CPU et que la liste de contrôle d'accès n'est même pas touchée.

Edge#show platform packet-trace packet 0 decode

Packet: 0           CBUG ID: 570

Summary

Input     : GigabitEthernet1

Output    : internal0/0/rp:0

State     : PUNT 11  (For-us data)

Timestamp

Start   : 1042490936823469 ns (11/26/2024 16:41:12.259675 UTC)

Stop    : 1042490936851807 ns (11/26/2024 16:41:12.259703 UTC)

Path Trace

Feature: IPV4(Input)

Input       : GigabitEthernet1

Output      :

Source      : 172.16.0.1

Destination : 10.0.0.1

Protocol    : 1 (ICMP)

<... output omitted ...>

Feature: SDWAN Implicit ACL

Action : ALLOW

Reason : SDWAN_SERV_ALL

<... output omitted ...>

Feature: IPV4_INPUT_LOOKUP_PROCESS_EXT

Entry       : Input - 0x814f8e80

Input       : GigabitEthernet1

Output      : internal0/0/rp:0

Lapsed time : 2135 ns

<... output omitted ...>

Feature: INTERNAL_TRANSMIT_PKT_EXT

Entry       : Output - 0x814cb454

Input       : GigabitEthernet1

Output      : internal0/0/rp:0

Lapsed time : 5339 ns

IOSd Path Flow: Packet: 0    CBUG ID: 570

Feature: INFRA

Pkt Direction: IN

Packet Rcvd From DATAPLANE

Feature: IP

Pkt Direction: IN

Packet Enqueued in IP layer

Source      : 172.16.0.1

Destination : 10.0.0.1

Interface   : GigabitEthernet1

Feature: IP

Pkt Direction: IN

FORWARDED To transport layer

Source        : 172.16.0.1

Destination   : 10.0.0.1

Interface     : GigabitEthernet1

Edge#show platform packet-trace packet 0 decode | in ACL   <<<<< ACL feature never hit

Feature: SDWAN Implicit ACL

Feature: IPV4_SDWAN_IMPLICIT_ACL_EXT

Edge#show platform packet-trace packet 0 decode | in Lo <<<< Loopback1 never mentioned

Edge#

Afin de bloquer le trafic lié au CPU, vous devez appliquer la liste de contrôle d'accès à l'interface à laquelle le paquet entre en premier, par exemple, l'interface physique ou port channel . Ici, nous pouvons voir le résultat de l'application de la ACL  sur l'interface physique.

Edge1#show platform packet-trace packet 0

Packet: 0           CBUG ID: 24

Summary

Input     : GigabitEthernet1

Output    : GigabitEthernet1

State     : DROP 8   (Ipv4Acl)

Timestamp

Start   : 5149395094183 ns (11/27/2024 19:48:55.202545 UTC)

Stop    : 5149395114474 ns (11/27/2024 19:48:55.202565 UTC)

Path Trace

Feature: IPV4(Input)

Input       : GigabitEthernet1

Output      :

Source      : 172.16.0.1

Destination : 10.0.0.1

Protocol    : 1 (ICMP)

<... output omitted ...>

Feature: IPV4_INPUT_ACL    <<<<

Entry       : Input - 0x814cc220

Input       : GigabitEthernet1

Output      :

Lapsed time : 15500 ns