ARGOMENTO:

Ciao Virgilio,
per l'argomento Port-Based Authentication nel caso in cui l'autenticazione avvenga tramite Server Radius, credo che utenti e password ammessi sono configurati direttamente sul server; nel caso invece in cui l'autenticazione avviene in locale sullo switch, devono essere configurati in locale.

Ma i comandi per la configurazione di utenti e pwd (se autenticazione in locale) sono gli stessi per switch e hosts?

dot1x credentials PIPPO
user paolo
password paolo

non riesco a trovare nella registrazione la parte in cui parli di
dot1x pae supplicant
a cosa serve questo comando?

Un'altra domanda:

i comandi per l'attivazione del new-model, del port-security, del dhp snooping, etc
si devono dare i comandi
aaa new-model (GLOBAL)
switchport port-security (IF)
ip dhcp snooping (GLOBAL)

ma per disabilitare queste funzionalità si devono dare gli stessi comandi con il [no] davanti?

Inoltre, per il DHCP snooping si considera TRUSTED un'interfaccia verso un HOST o verso un altro SWITCH?

Paolo_Tesse ha scritto: Ma i comandi per la configurazione di utenti e pwd (se autenticazione in locale) sono gli stessi per switch e hosts?
dot1x credentials PIPPO
user paolo
password paolo
dot1x pae supplicant
a cosa serve questo comando?

Dunque, se l'autenticazione è in locale, sull'authenticator, nel nostro caso lo switch,
aaa new-model
aaa authentication dot1x default local
username USERNAME
password PASSWORD

I comandi
dot1x pae supplicant e dot1x credentials servono invece per configurare una macchina, ad esempio un router come se fosse un client dot1x, tutta questa parte è al momento fuori dal blueprint dell'esame CCNP Switch

Paolo_Tesse ha scritto: ma per disabilitare queste funzionalità si devono dare gli stessi comandi con il [no] davanti?

Esattamente

Paolo_Tesse ha scritto: Inoltre, per il DHCP snooping si considera TRUSTED un'interfaccia verso un HOST o verso un altro SWITCH?

Di default le interfacce sono in stato untrusted, per una corretta configurazione è necessario configurare trusted le interfacce che vengono attraversate in ingresso dalle risposte del server DHCP, queste interfacce potranno essere quindi interfacce a cui è collegato un DHCP Server, Trunk verso altri switch, Trunk verso router al di là dei quali si trova un DHCP server.

Virgilio,
ha senso configurare ed abilitare l'autenticazione solo su switch di livello access o anche su quelli distribution?

Paolo_Tesse ha scritto: Virgilio,
ha senso configurare ed abilitare l'autenticazione solo su switch di livello access o anche su quelli distribution?

Se parli di autenticazione 802.1x devi configurare la porta in auto mode solo sulle porte di accesso che vuoi autenticare, che tipicamente sono sugli switch di access.

Se per qualche ragione dovessi avere host che vuoi autenticare su uno switch di distribution potresti volere abilitarla anche su queste, ma sinceramente non credo che un'architettura del genere venga proposta nell'esame SWITCH CCNP

il comando ip source binding mac-address vlan vlan-id ip-address interface
type mod/num deve riportare il MAC, la VLAN e l'IP di un host che colloquia nella rete
tramite quella porta (direttamente o dietro un HUB), e si tratta di configurazione
statica; il comando di IF ip verify source [port-security] abilita l'IP Source Guard
per controllare le entry statiche (ip source binding) o quelle 'imparate' dinamicamente
tramite il DHCP Snooping; è tutto corretto?

Paolo_Tesse ha scritto: il comando ip source binding mac-address vlan vlan-id ip-address interface
type mod/num deve riportare il MAC, la VLAN e l'IP di un host che colloquia nella rete
tramite quella porta (direttamente o dietro un HUB), e si tratta di configurazione
statica; il comando di IF ip verify source [port-security] abilita l'IP Source Guard
per controllare le entry statiche (ip source binding) o quelle 'imparate' dinamicamente
tramite il DHCP Snooping; è tutto corretto?

Tutto corretto

LAB capitolo 16: ho configurato DLS1 e DLS2 così
DLS1
interface Vlan1
ip address 172.16.1.3 255.255.255.0
standby 1 ip 172.16.1.1
standby 1 priority 150
standby 1 preempt
!
interface Vlan100
ip address 172.16.100.3 255.255.255.0
standby 1 ip 172.16.100.1
standby 1 priority 150
standby 1 preempt
!
interface Vlan200
ip address 172.16.200.3 255.255.255.0
standby 1 ip 172.16.200.1
standby 1 preempt

DLS2
interface Vlan1
ip address 172.16.1.4 255.255.255.0
standby 1 ip 172.16.1.1
standby 1 preempt
!
interface Vlan100
ip address 172.16.100.4 255.255.255.0
standby 1 ip 172.16.100.1
standby 1 preempt
!
interface Vlan200
ip address 172.16.200.4 255.255.255.0
standby 1 ip 172.16.200.1
standby 1 priority 150
standby 1 preempt

sh ip route (su entrambi)
172.16.0.0/24 is subnetted, 3 subnets
C 172.16.200.0 is directly connected, Vlan200
C 172.16.1.0 is directly connected, Vlan1
C 172.16.100.0 is directly connected, Vlan100

ip routing è configurato su entrambi.

DLS1 è ROOT per STP su VLAN1 e VLAN100, DLS2 è ROOT per STP su VLAN200.

HSRP sembra ben configurato, ma dai MSG di DEBUG si vede che i due si scambiano i msg solo per VLAN1 e non per VLAN100 e VLAN200, per cui si ha

DLS1#sh standby brief
P indicates configured to preempt.
|
Interface Grp Pri P State Active Standby Virtual IP
Vl1 1 150 P Active local 172.16.1.4 172.16.1.1
Vl100 1 150 P Active local unknown 172.16.100.1
Vl200 1 100 P Active local unknown 172.16.200.1

DLS2#sh standby brief
P indicates configured to preempt.
|
Interface Grp Pri P State Active Standby Virtual IP
Vl1 1 100 P Standby 172.16.1.3 local 172.16.1.1
Vl100 1 100 P Active local unknown 172.16.100.1
Vl200 1 150 P Active local unknown 172.16.200.1

Se abilito il DEBUG dei msg di error non viene visualizzato nulla.
Quale verifica mi sto dimenticando?

L'unico controllo che farei è verificare che il trunk tra i due funzioni, il livello 3 funziona, meglio concentrarsi sul livello 2

vspaziani ha scritto: L'unico controllo che farei è verificare che il trunk tra i due funzioni, il livello 3 funziona, meglio concentrarsi sul livello 2

Ho spento tutte le macchine, riconfigurato tutto ed ha funzionato...
Meglio così, non avevo commesso nessun errore...