Cisco IOS aplică o logică internă când acceptă sau procesează ACE-urile standard. Așa cum s-a discutat anterior , ACE-urile sunt procesate secvențial. Prin urmare , ordinea în care sunt introduse ACE-urile este importantă.
De exemplu , în Figura 1 , ACL 3 conține două ACE-uri. Primul ACE utilizează masca wildcard pentru a bloca un interval de adrese , care include toate hosturile din rețeaua 192.168.10.0/24. Al doilea ACE este o declarație de host care examinează un host specific : 192.168.10.10. Acesta este un host din intervalul de hosturi care a fost configurat în declarația anterioară. Cu alte cuvinte , 192.168.10.10 este un host în rețeaua 192.168.10.0/24. Logica internă IOS pentru liste de acces standard respinge a doua declarație și returnează un mesaj de eroare pentru că este subansamblul declarației anterioare. Observați în figură faptul că router-ul atribuie automat secventa num 10 ca secventa numărului atribuit către prima declarație introdusă în acest exemplu. Ieșirea din router include mesajul că regula "parte a regulei existente la secvența num 10" și nu acceptă declarația.
Notă:În prezent , ACL-urile extinse nu produc o eroare similară.
Configurația în Figura 2 pentru ACL 4 are aceleași două declarații dar în ordine inversă. Aceasta este o secvență validă a declarațiilor pentru că prima intrare se referă la un host specific , nu la un interval de hosturi.
În Figura 3 , ACL 5 arată că o declarația de host poate fi configurată după ce o declarație denotă un interval de hosturi. Host-ul nu trebuie să fie în intervalul acoperit de către declarația anterioară. Adresa de host 192.168.11.10 nu este un membru al rețelei 192.168.10.0/24 deci este o declarație validă.
Notă:Ordinea în care ACE-urile standard sunt introduse poate să nu fie ordinea în care ele sunt stocate , afișate sau procesate de către router. Acest lucru va fi discutat în altă secțiune.