Newsgroup: it.comp.reti.cisco
Titolo: telnet e backup con float route...

situazione 2 router gemelli  1721 con ADSL e BRI
ios 12.2 ipplus
connessione adsl con ip fisso  (funzionante)
tunnel ip ip fra i due  con eigrp 
configurazione per fare il backup del tunnel con floate route  come
spiegato in 
http://www.cisco.com/warp/public/125/fr_isdn_backup.html
accendo tutto... il tunnel e' ok
isdn se ne sta spenta...
metto in shut il tunnel...
non succede nulla... ok
pingo l'altro router (l'ip di eth.. 192.0.2.254)  isdn si attiva ...
eigrp fa il suo lavoro..  e ottengo ...!!  
e poi se lo rifaccio !!!!!
quindi e' ok..
metto in no shut il tunnel
eigrp riaggiorna le route (avendo un bandw 2048  lo fa quasi subito)
i route continuano a pingarsi...
traceroute dice che stanno usando il tunnel ...  dopo un po' isnd va
giù..  ok
sembra funzionare alla perfezione..
problema..
da uno faccio un telent su due  (sempre ip dell'eth) oppure su una
macchina nella lan di due..  funziona
butto giu' il tunnel...
il telnet siblocca...
isdn si acende..  eigrp si aggiorna... i ping tornano a funzionare...
ma il telnet rimane bloccato...
riattivo il tunnel ...
riaggiornano le route...
e il telnet si sblocca..
e' come se ipacchetti del telnet non usassero le nuove route durante
il backup..
addirittura se faccio in fretta  quando si sblocca il telnet passano
tutti i comandi che erano stati "bufferizzati"...
ovviamente se accendo il telnet con il tunnel in shut tutto funziona
perfettamente...
qualcuno sa cosa sta succedendo?
allego la conf di un router...  l'altro e' uguale con i "parametri"
invertiti..
ps...  il comando telnet lo lancio dal router...  non ho modo di
provare da una macchina in quanto in una delle due reti non ho
macchine accessibili in questo momento...  l'unico sospetto che ho
(pensandoci bene mi pare fondato) e' che il telnet usi come indirizzo
il suo endpoint del tunnel...  quindi si incasini quando va in
shutdown..  c'è un modo per forzare il telnet ad usare come ip di
sorgente l'ip di eth0????  da quello che ho capito usa l'ip piu'
"vicino" alla destinazione...  adesso che ci penso mi pare proprio
sensata come supposizione...  male che vada il mio post servirà solo
come spunto per config. di altri... (io ci ho sudato parecchio per
farla...)
 
ps2... avrei dei vantaggi ad usare un tunnel gre al posto di un ipip
???!
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname uno
!
logging queue-limit 100
enable secret 5 XXXXXXXXXXX
enable password XXXXX
!
username due password 7 XXXXX
aaa new-model
!
!
aaa authentication login default local
aaa authentication ppp default local
aaa session-id common
ip subnet-zero
!
!
!
vpdn enable
!
vpdn-group pppoe
 request-dialin
  protocol pppoe
!
!
isdn switch-type basic-net3
!
!
!
interface Tunnel100
 bandwidth 2048
 ip address 192.168.1.1 255.255.255.252
 no ip route-cache
 no ip mroute-cache
 keepalive 3000 3
 tunnel source Dialer1
 tunnel destination <ip di 2>
 tunnel mode ipip
!
interface ATM0
 no ip address
 no atm ilmi-keepalive
 bundle-enable
 dsl operating-mode auto
!
interface ATM0.1 point-to-point
 pvc 8/35
  pppoe-client dial-pool-number 1
 !
!
interface BRI0
 ip address 192.168.1.6 255.255.255.252
 encapsulation ppp
 no ip route-cache
 no ip mroute-cache
 dialer map ip 192.168.1.5 name due broadcast 1234567
 dialer load-threshold 5 either
 dialer-group 1
 isdn switch-type basic-net3
 ppp authentication chap
 ppp multilink
!
interface FastEthernet0
 ip address 192.0.0.253 255.255.255.0
 ip nat inside
 ip tcp adjust-mss 1452
 speed auto
!
interface Dialer1
 mtu 1492
 ip address negotiated
 ip nat outside
 encapsulation ppp
 ppp chap hostname pippo
 ppp chap password 0 pluto
 ppp pap sent-username pippo password 0 pluto
!
router eigrp 100
 redistribute connected
 redistribute static
 network 192.168.1.0
 no default-information out
 distribute-list 1300 out
 no auto-summary
 no eigrp log-neighbor-changes
!
ip nat inside source list 1 interface Dialer1 overload
ip classless
ip route 0.0.0.0 0.0.0.0 Dialer1
ip route 192.0.2.0 255.255.255.0 192.168.1.5 200
no ip http server
!
!
!
access-list 1 permit 192.0.0.0 0.0.0.255
access-list 1300 permit 192.0.0.0 0.0.0.255
access-list 1300 deny   any
access-list 100 deny   eigrp any any
access-list 100 permit ip any any
dialer-list 1 protocol ip list 100
!
radius-server authorization permit missing Service-Type
!
line con 0
line aux 0
line vty 0 4
 timeout login response 100

  
trovato...
con telnet  due /source-interface fasteth 0   tutto funziona a
meraviglia...

 meraviglia...
per quando ci saranno le macchine: ricorda no ip route-cache sulla eth e
sulla atm :)
un mayhem e come perdere ore per nulla ;P
-- 
 La mia prima misura anticoncezionale e' stata la preghiera.
 Cisco  FAQ: 
http://mayhem.oltrelinux.com/icrc
 SPP  wpage: 
http://www.spippolatori.com
 Key on 
pgp.mit.edu
 ID C7393613

 
questo disabilita il fast switching se non erro....
e lo devo disabilitare per evitare che quando si attiva il back lui continui a 
instradare con la vecchia route?..  o sto dicendo baggianate?
capisco il senso sulla eth  ma perchè sulla atm??
non credo che, vista la lentezza di adsl, mi serva il fast sw ... ma giusto per 
sapere..
a naso lo avrei messo solo su fast eth, tunn e bri... ovvero dove c'è un cambio 
di routing...
ps...  il gre rispetto a ipip che vantaggi mi da?

 ps... il gre rispetto a ipip che vantaggi mi da?
gre e' multiprotocollo, puo' incapsulare anche IPX e Appletalk. Credo che
come rovescio della medaglia aggiunga un leggero overhead.
Ciao
cronenberg
--
Il cielo stellato sopra di te, la legge morale dentro.
--------------------------------
Inviato via 
http://usenet.libero.it

 ps...  il gre rispetto a ipip che vantaggi mi da?
oltre a quel che dice cronemberg, io lo uso quando faccio interagire
vendor diversi. ad esempio, ma parlo di molto tempo fa, ip-ip tra cisco e
linux mi ha dato problemi, mentre gre ha funzionato da subito. non escludo
che fosse un mio errore :)
un mayhem ora vado a pranzo


 
pure io...

 cosi'... magari un giorno (se pagano l'ios criptico) penserň a ipsec...
ah ma una vpn solo gre? mmmhhh almeno autentica il gre con le key :(
un mayhem che pensa a gre sempre e solo come complemento di ipsec ...


 ipsec ...
cut
Penso intendesse ipsec senza gre, non gre senza ipsec. ipsec e' gia' di per
se' un incapsulamento dell'IP, a volte aggiungere ulteriormente il gre
appesantisce solo, soprattutto quando alla fine viene creata una sola o due
security associations. Anche io comunque preferisco ipsec over gre (cioe'
criptare pacchetti gre), l'access-list della security association diventa
banale e facilmente simmetrica tra i peer, e poi c'e' la leggibilita'
dell'interfaccia tunnel. E poi quando le applicazioni e gli utenti sono
tanti si alleggerisce il router, che crea una sola security association.


 tanti si alleggerisce il router, che crea una sola security association.
ma io credo di avere capito che ha un ip base senza ipsec ... ma potrei
sbagliare :)
io gre con ipsec lo uso non tanto per semplificare le acl (la crypto acl
crypta da lan a lan, il traffico ip lo filtro sulla eth, quindi risulta
cmq banale) quanto per fare giochi strani, ad esempio sul backup.
per fare backup devi avere un protocollo di routing e fare girare eigrp in
un tunnel gre autenticato, mentre il traffico vero passa o nel tunnel
ipsec o dai dialer risulta proprio comodo.
un mayhem che poi ognuno fa come vuole, purche' la sicurezza ne sia
preservata. 


 ipsec o dai dialer risulta proprio comodo.
cut
Gia', e' vero, ipsec non supporta multicast, incapsulando prima in gre
diventa unicast e cripta tranquillo. Ma che tu sappia il 3des e' ancora
sicuro...?


 sicuro...?
dipende da cosa devi fare.
il traffico da casa mia all'ufficio va bene 3des.
il traffico con gli scontrini del supermercato verso gli uffici va bene
3des.
trasferimento polizze assicurative e transazioni economiche uso aes.
un mayhem con le labbra secche



Scusa se mi intrometto, ma ho bisogno di una precisazione da parte tua:
il traffico vero lo fai passare nel tunnel ipsec che a sua volta è costruito
su un tunnel gre oppure riesci a fare in modo di evitare l'encapsulation gre
per il traffico dati mantenendo tutte i vantaggi di un eigrp?
Nel primo caso sarebbe veramente interessante, dato che io non sono mai
riuscito ad evitare la doppia encapsulation, tranne che per il traffico non
"ipseccabile".
Tnx,
       Tosh.


esatto... ho un ios  ip plus ma senza ipsec... (ip plus mi serve per
il ppoe client)
il tunnel mi serve che porti il mcast (se non ricordo male eigrp e' in
mcast)...
una chiave la posso anche mettere...  
per la sicurezza...  bhe...  se non pagano ipsec perche dovrebbero
pagare me per diventare matto??
già che ci sono mi viene un altra domanda...
la configurazione che ho (vedere primo post) attiva l'isdn solo quando
muore la route eigrp passata sul tunnel e quando arrriva il primo
pacchetto da trasportare (soerimentano un blocco di circa 3-4
secondi)...
per motivi che ignoro le impiegate dietro al terminale del' as400 (che
sta su ip) si "lamentano" di questo blocco...  (sembra che questo
comporti una disconnessione e loro debbano rimettere user e pass) ..
e' possibile far tirare su l'isdn anche senza traffico (ma solo se il
tunnel non funziona)?
so che non e' una cosa elegantissima.... (quando poi capirò i
parametri dell'as400 sarò contento...)
io pensavo ad un bel ping "continuo" fra 2 linux...  ma c'è un modo
per farlo col golden gate??

 ps...  il gre rispetto a ipip che vantaggi mi da?
oltre a quel che dice cronemberg, io lo uso quando faccio interagire
vendor diversi. ad esempio, ma parlo di molto tempo fa, ip-ip tra cisco e
linux mi ha dato problemi, mentre gre ha funzionato da subito.
non escludo che fosse un mio errore :)
un mayhem ora vado a pranzo


 cosi'... magari un giorno (se pagano l'ios criptico) penserò a ipsec...
ah ma una vpn solo gre? mmmhhh almeno autentica il gre con le key :(
un mayhem che pensa a gre sempre e solo come complemento di ipsec ...


 per farlo col golden gate??
giocherei con i service (tcp-keepalive, telnet-qualcosa etc etc).
inoltre sono da aumentare i timeout del telnet su as400.
come qsecofr cfgtcp e mi sembra opzione 3 per i timeout ip, chgtelna e poi
premi F4 per i parametri del telnet server.
comunque ci arrivi anche da cfgtcp (hint: se l'os400 e' in italiano, usa
F11 per vedere le parole chiavi, almeno capisci qualcosa di piu', inoltre
F1 dice a volte cose utili ;P)
un mayhem debugging



sulle tastiere ibm le perche mettono le vocali se poi non le usano? ;)
provero' a mettere in macchina le modifiche...
grazie.