CiscoForums.it

Ciao a tutti,

l'altro giorno ho postato una richiesta di aiuto per quanto riguarda la sincronizzazione di un router SOHO 97 via sntp

Mi e' stato fatto osservare che forse c'erano problemi con le mie access lists...
...ho lasciato perdere un attimo la cosa, avendo altre faccende piu' urgenti da sistemare, ma ora che l'ho ripresa in mano mi sono sorti dei dubbi appunto sul tema access lists che e' meglio dipanare dato che influenzano ANCHE di sicuro in discorso sincro ntp

Premessa, il router in questione, se non ricordo male aveva delle access lists preimpostate che pero' non esistono piu' in quanto eliminate...

Incertezza 1)

A parte quelle che ho inserito per abilitare la connessione via telnet solo da 1 host e soltanto su una vty (negando quindi altre connessioni sulle vty 1-4) non ce ne sono altre. Qualcuno di voi sa dirmi cosa permettono di fare (e non fare) quelle preimpostate dal produttore? (sempre ammesso che ce ne fossero - ripeto, non ne sono molto sicuro)

Incertezza 2)

L'acl viene pensata come un set di regole da applicare con un ordine tale che il meccanismo "acl match=true", interrompe il proseguimento dei confronti nella specifica catena delle acl; in base a questo mi chiedo, avere un gruppo di acl (o al limite una) specificate nella configurazione originale e' indispensabile per la navigazione; sbaglio? Ho notato che non specificando/applicando alcuna acl, semplicemente dopo aver configurato il minimo indispensabile per navigare, si riesce tranquillamente a uscire... E qui mi chiedo: e' realmente cosi'? (Cmq allego la mia running conf attuale x riscontro)

Incertezza 3)

Durante i miei esperimenti ho notato che dopo aver applicato un'acl specifica per ntp, la risoluzione dns dei singoli host aveva dei problemi.... ergo, succede qualcosa a livello pacchetti udp nel router, cosa che prima non succedeva! Cosa potrebbe essere? Di fatto, se elimino l'acl list x la sinconizz ntp tutto torna a funzionare correttamente...

Incertezza 4)

Pensavo di non avere dubbi, e invece eccoli qua, sull'assegnazione numerica delle acl: io posso numerare un acl in un range tra 100 e 199 per formare regole relative a quali servizi? E' indifferente che io voglia impostare una regola x il telnet come una x l'ssh o una x il dns o ancora 25,110,80 etc... ? Per esempio ho creato delle acl con numeraz 105 x fare esperimenti con ntp... Sbagliavo? Avrei potuto usare le stesse numeraz pure x specificare regole x connessioni telnet? E in quali casi la numerazione dovrebbe rientrare nel range 1-99?

Incertezza 5)

Voglio che il mio router sincronizzi con 1 ntp server:

configuro la parte relativa all'sntp (sntp server x.x.x.x etc...) e poi creo 1 acl cosi':

access-list 105 permit udp host "ntpserver" eq ntp any
poi applico:

interface ATM0.35
(a proposito, l'acl va applicata all'ATM a all'ATM p2p? - io la metterei sulla p2p - sbaglio? )

ip access-group 105 in (perche' le risposte devono poter entrare nell'interfaccia)

Basta cosi' o bisogna tener conto che i dati devono passare anche per altre interf?

Cito questo esempio perche' e' quello con cui ho lavorato e che mi ha fatto venire tutti questi dubbi... Voglio assolutamente togliermeli!!

Confido nel vostro aiuto - TheIrish, MrCisco, please... Mi sento "menomato" con questi dubbioni....

Allegata mia running-conf

Ciao

P.s. Graditisssssime tutte le critiche/suggerim all'attuale running conf
P.s.1 Mi tocca inserire qua di seguito la running-conf - scusate!
---------------------------------------------------------------------------------------------------------
xxxxxxxx#show conf
Using 1397 out of 131072 bytes
!
version 12.3
no service pad
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname xxxxxxxxx
!
enable secret 5 $xxxxxxxxxxxxxxxxxxxxxxxxx
!
username xxxxx
clock timezone CET 1
clock summer-time CEST recurring last Sun Mar 1:00 last Sun Oct 1:00
ip subnet-zero
!
!
no aaa new-model
!
!
!
!
!
!
!
interface Ethernet0
ip address xxxxxxxxxx 255.255.255.248
no cdp enable
hold-queue 100 out
!
interface ATM0
no ip address
no ip mroute-cache
atm ilmi-keepalive
dsl operating-mode auto
!
interface ATM0.35 point-to-point
ip address xxxxxxxxxxxxx 255.255.255.252
pvc 8/35
encapsulation aal5snap
!
!
ip classless
ip route 0.0.0.0 0.0.0.0 ATM0.35
no ip http server
no ip http secure-server
!
access-list 10 permit xxxxxxxxxxxxxxx
access-list 11 deny any
no cdp run
!
line con 0
exec-timeout 120 0
password 7 xxxxxxxxxxxxxx
login
no modem enable
stopbits 1
line aux 0
password 7 xxxxxxxxxxxxxx
login
line vty 0
access-class 10 in
exec-timeout 120 0
password 7 xxxxxxxxxxxxxxx
login
length 0
line vty 1 4
access-class 11 in
exec-timeout 120 0
password 7 xxxxxxxxxxxxxxxx
no login
length 0
!
scheduler max-task-time 5000
sntp server 193.204.114.232
sntp server 193.204.114.233
sntp server 129.24.32.4
sntp server 125.52.73.55
sntp server 133.46.3.66
sntp broadcast client
!
end

Incertezza 1)
A parte quelle che ho inserito per abilitare la connessione via telnet solo da 1 host e soltanto su una vty (negando quindi altre connessioni sulle vty 1-4) non ce ne sono altre. Qualcuno di voi sa dirmi cosa permettono di fare (e non fare) quelle preimpostate dal produttore? (sempre ammesso che ce ne fossero - ripeto, non ne sono molto sicuro)

non esistono acl fornite dal produttore.

L'acl viene pensata come un set di regole da applicare con un ordine tale che il meccanismo "acl match=true", interrompe il proseguimento dei confronti nella specifica catena delle acl; in base a questo mi chiedo, avere un gruppo di acl (o al limite una) specificate nella configurazione originale e' indispensabile per la navigazione; sbaglio? Ho notato che non specificando/applicando alcuna acl, semplicemente dopo aver configurato il minimo indispensabile per navigare, si riesce tranquillamente a uscire... E qui mi chiedo: e' realmente cosi'? (Cmq allego la mia running conf attuale x riscontro)

una interfaccia senza acl assegnate, viene vista come "permit ip any any"

Durante i miei esperimenti ho notato che dopo aver applicato un'acl specifica per ntp, la risoluzione dns dei singoli host aveva dei problemi.... ergo, succede qualcosa a livello pacchetti udp nel router, cosa che prima non succedeva! Cosa potrebbe essere? Di fatto, se elimino l'acl list x la sinconizz ntp tutto torna a funzionare correttamente...

attenzione però. alla fine di ogni ACL c'è un implicito deny ip any any (o deny any, a seconda che sia standard o estesa).

Pensavo di non avere dubbi, e invece eccoli qua, sull'assegnazione numerica delle acl: io posso numerare un acl in un range tra 100 e 199 per formare regole relative a quali servizi? E' indifferente che io voglia impostare una regola x il telnet come una x l'ssh o una x il dns o ancora 25,110,80 etc... ? Per esempio ho creato delle acl con numeraz 105 x fare esperimenti con ntp... Sbagliavo? Avrei potuto usare le stesse numeraz pure x specificare regole x connessioni telnet? E in quali casi la numerazione dovrebbe rientrare nel range 1-99?

cambia solo il livello di espressività. da 1 a 99 sono standard e ti permettono solo di distinguere la sorgente della comunicazione. Ormai sono utili solo per assegnare ip permessi a servizi ecc. Per esempio, una access-group per un telnet, come dicevi tu, si può facilmente fare usando quelle da 1 a 99, tipo:
access-list 5 permit host 192.168.0.11
quelle da 100 a 199 invece sono + espressive e ti permettono di distinguere sorgente, destinazione, porte, flag dei pacchetti ecc.
Comunque sia, tra una acl 100 e una acl 199 non cambia nulla, sintatticamente.

il problema comunque sia, adesso lo vedo, è un altro ed è legato al servizio.
Ovveero, il tuo provider è telecom? se sì, allora abbiamo un problema.
il problema è questo: quando il tuo servizio sntp vuole chiedere l'ora, lo fa uscendo con l'ip dell'atm0.1 point-to-point, il famoso ip ptp...
problema: i pacchetti provenienti da quell'indirizzo vengono scartati in cerntrale telecom. Non puoi uscire con quell'indirizzo, ammeno che non siano cambiate le cose nel frattempo.

Grazie!!

Come al solito, sempre chiarissimo!
Dubbi dipanati!!

Come potrei fare x sincronizzare l'oa secondo te?
Ho capito cosa intendi, penso sia lo stesso motivo x cui vengono scartati anche i pacchetti icmp provenienti dal p2p, se non sbaglio.

Sto pensandoci anch'io...
Se ti viene in mente 1 sistema... Grazie!!!

Ciao

Re:

Ciao,

solo con NTP puoi cambiare la sorgente del pacchetto di richiesta ntp

c7206-VXR2-AMSLAB8(config)#ntp source ?
Async Async interface
BVI Bridge-Group Virtual Interface
CDMA-Ix CDMA Ix interface
CTunnel CTunnel interface
Dialer Dialer interface
FastEthernet FastEthernet IEEE 802.3
Lex Lex interface
Loopback Loopback interface
MFR Multilink Frame Relay bundle interface
Multilink Multilink-group interface
Null Null interface
Serial Serial
Tunnel Tunnel interface
Vif PGM Multicast Host interface
Virtual-PPP Virtual PPP interface
Virtual-Template Virtual Template interface
Virtual-TokenRing Virtual TokenRing

ma con SNTP non c'è cmd per questa funzione l'unica è avere un Clock server interno che a sua volta si aggiorna con uno esterno...ci sta un soft per windows gratuito che fa sta cosa...oppure se usi *NIX metti su un NTPD demon.

By Marckalex