Login

Benvenuto, Ospite
Nome utente: Password: Ricordami
  • Pagina:
  • 1

ARGOMENTO:

ACL estese e campo protocollo: problema di packet tracer? 9 Anni 1 Mese fa #1

  • roberto ulisse
  • Autore della discussione
  • Offline
  • Platinum Member
  • Platinum Member
  • Messaggi: 289
  • Ringraziamenti ricevuti 35
Buongiorno a tutti,
nella configurazione delle acl estese c'e la possibilita' di definire la singola aces in modo che questa possa far "matchare" con il campo protocollo presente del pacchetto IP nei bit 72->79 dell'intestazione dello stesso.
I valori attribuibili al campo protocollo sono definiti nella RFC 790 che prevede molti valori differenti, qui un piccolo estratto della RFC 790:

Decimal Octal Protocol Numbers References



0 0 Reserved [JBP]
1 1 ICMP [53,JBP]
2 2 Unassigned [JBP]
3 3 Gateway-to-Gateway [48,49,VMS]
4 4 CMCC Gateway Monitoring Message [18,19,DFP]
5 5 ST [20,JWF]
6 6 TCP [34,JBP]
7 7 UCL [PK]
8 10 Unassigned [JBP]
9 11 Secure [VGC]
10 12 BBN RCC Monitoring [VMS]
11 13 NVP [12,DC]
12 14 PUP [4,EAT3]
13 15 Pluribus [RDB2]
14 16 Telenet [RDB2]
15 17 XNET [25,JFH2]
16 20 Chaos [MOON]
17 21 User Datagram [42,JBP]
..........
notare che il protocollo identificato col numero 17 e' il famoso UDP.

Mi chiedo: come mai IOS nella definizione delle ACES in tale campo consente solo immissione di valori proposti in formato testo quali sono quelli proposti:

R1(config)#access-list 101 permit ?
ahp Authentication Header Protocol
eigrp Cisco's EIGRP routing protocol
esp Encapsulation Security Payload
gre Cisco's GRE tunneling
icmp Internet Control Message Protocol
ip Any Internet Protocol
ospf OSPF routing protocol
tcp Transmission Control Protocol
udp User Datagram Protocol

e non consenta anche l'immissione di un numero tra 0 e 255, tra le altre cose l'immissione pura di un numero rappresentante un protocollo dovrebbe essere il modo naturale per definire le cose e solo un ulteriore aiuto dovrebbe consentire di ricorrere all'aiuto del valore testo mnemonico del protocollo, per dirla in altri termini se si volesse permettere traffico solo per il protocollo numero 4 = CMCC Gateway Monitoring Message come si potrebbe fare visto che non esiste possibilita' di scelta in quelle proposte?

Si prega Accedi a partecipare alla conversazione.

Ultima Modifica: da roberto ulisse. Motivo: chiarimento

ACL estese e campo protocollo: problema di packet tracer? 9 Anni 1 Mese fa #2

  • jpalombi
  • Avatar di jpalombi
  • Offline
  • Administrator
  • Administrator
  • Messaggi: 2646
  • Ringraziamenti ricevuti 1112
Ciao Roberto,
quando dici:

come mai IOS nella definizione delle ACE [...] non consenta anche l'immissione di un numero tra 0 e 255, tra le altre cose l'immissione pura di un numero rappresentante un protocollo dovrebbe essere il modo naturale per definire le cose e solo un ulteriore aiuto dovrebbe consentire di ricorrere all'aiuto del valore testo mnemonico

non potrei essere più daccordo, tant'è che:

Router(config)#access-list 101 permit ?
<0-255> An IP protocol number
ahp Authentication Header Protocol
eigrp Cisco's EIGRP routing protocol
esp Encapsulation Security Payload
gre Cisco's GRE tunneling
icmp Internet Control Message Protocol
igmp Internet Gateway Message Protocol
ip Any Internet Protocol
ipinip IP in IP tunneling
nos KA9Q NOS compatible IP over IP tunneling
ospf OSPF routing protocol
pcp Payload Compression Protocol
tcp Transmission Control Protocol
udp User Datagram Protocol


Limite del PT ;)
IpCert Instructor
CCENT - CCNA - CCNA CyberOps - CCNP Enterprise - CCNP Collaboration - CCNP Service Provider
CCS - Enterprise Core, Ent. Advanced Infrastructure, SP Core, SP Advanced Routing, SP VPN Services, Collaboration Core, Coll. Applications
Ringraziano per il messaggio: roberto ulisse

Si prega Accedi a partecipare alla conversazione.

Ultima Modifica: da jpalombi.

ACL estese e campo protocollo: problema di packet tracer? 9 Anni 1 Mese fa #3

  • roberto ulisse
  • Autore della discussione
  • Offline
  • Platinum Member
  • Platinum Member
  • Messaggi: 289
  • Ringraziamenti ricevuti 35
Sincramente la mia considerazione sulpacket tracer sta diventando veramente molto negativa, pare che il packet tracer siauno strumento per mandare fuori strada la gente che vuole capire come stanno le cose. E' veramente quasi una indecenza, che addirittuta il packet tracer non rispecchi non dico il comportameto degli apparatiin rete ma neanche la sintassi dei comandi.
Sinceramente posso solo dire che e' meno di un giocattolo rotto.

Si prega Accedi a partecipare alla conversazione.

ACL estese e campo protocollo: problema di packet tracer? 9 Anni 1 Mese fa #4

  • jpalombi
  • Avatar di jpalombi
  • Offline
  • Administrator
  • Administrator
  • Messaggi: 2646
  • Ringraziamenti ricevuti 1112
Credo che qui tu stia sottovalutando l'efficacia didattica di uno strumento molto valido per approcciare il networking, che a più riprese si è definito non esaustivo e non possibile fonte di verifica dei comportamenti e della comandistica dell'IOS.

Il PT fa molto più di quello che serve per la CCNA, e quello che fa lo fa allo scopo di insegnare (vedi ad es. simulation-mode, domande challenge etc). Ovvio che testarlo su tutta una serie di comportamenti specifici (o comandi), proprio perchè è un simulatore, espone il fianco ad errori ed imprecisioni a vari livelli. Ciò però non vuol dire mandare fuori strada di per sè: semplicemente, rispetto a cose avanzate (e non implementate) come il protocol number, andrebbero fatte delle verifiche sugli apparati reali (li mettiamo a disposizione proprio perchè il PT non può assolutamente sostituirsi alle macchine reali). Non giudicherei il PT per assenza di comandi, e non lo utilizzerei (l'ho detto più volte) per fare verifiche approfondite. Ma va benissimo per iniziare a prendere confidenza con sintassi, protocolli etc.
IpCert Instructor
CCENT - CCNA - CCNA CyberOps - CCNP Enterprise - CCNP Collaboration - CCNP Service Provider
CCS - Enterprise Core, Ent. Advanced Infrastructure, SP Core, SP Advanced Routing, SP VPN Services, Collaboration Core, Coll. Applications

Si prega Accedi a partecipare alla conversazione.

  • Pagina:
  • 1
Moderatori: jpalombi