[ITNOG] Problemi con Bitstream ed IWF

[Lukas Tribus]

Ciao Marco,





> Dopo il riavvio di un BRAS ( Cisco con IOS-XE ), la CPE si accorge del

> fermo, resetta il proprio stato e tenta di rinegoziare la sessione PPP.

>

> Inizialmente tutto funziona come previsto: i due apparati attraversano

> tutti i processi tipici del setup di una sessione PPP finchè non

> arrivano a negoziare la parte LCP.

>

> A quel punto le comunicazioni si fermano ed il processo va in timeout



Su quale vendor di DSLAM hai riscontrato questo comportamento?



Ho visto un comportamento simile sui Ericsson EDA2530 (nostri, che TI non

ha), dopo un down del BRAS ci voleva un riavvio dei CPE per resettare

l'IWF sul DSLAM - ma su quelli di TI non ho mai avuto questa condizione

(DOWN/RESET BRAS), quindi non so.



Attenzione 1: nel momento in qui cambi la configurazione del CPE fra PPPoA e

PPPoE o fra VC-MUX e LLC-SNAP (se PPPoA), se non butti giù anche l'ADSL,

non andrà mai su, perché sembra che questa "auto-detection" avviene una volta

sola (dopo l'allineamento ADSL, o con la prima cella ATM). Questo credo su

tutti modelli DSLAM ETH.



Forse stavi beccando due problemi diversi: il fatto che il timeout/down

del BRAS non viene gestito correttamente con IWF, e il fatto che la

riconfigurazione in PPPoE (per escludere l'IWF) non funziona senza flap ADSL.

Servirebbe partire da zero con PPPoE e riprodurre il down del BRAS. Solo

cosi si può escludere l'IWF.





Attenzione 2: l'IWF PPPoA --> PPPoE dei DSLAM (GBE) Siemens ha un gravissimo

baco: se la SESSION_ID (assegnata dal BRAS nel pacchetto PADS) è superiore di

0x7fff (quindi 0x8000 in poi o in altre parole con il primo bit a 1), il DSLAM

non fa partire (mai) LCP e quindi la sessione PPP non sale. Con PPPoE non c'è

questo problema, è evidentemente un baco dell'IWF. Qua spero che riusciamo

a risolvere con Telecom/Siemens perché è proprio grave (non si risolve con un

riavvio del CPE).





lukas