[ITNOG] Problemi con Bitstream ed IWF

[Marco Marzetti]

On 23/12/2014 15:38, Lukas Tribus wrote:
> 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.
>


Ciao,

Purtroppo per "macro problemi" di questo tipo non tracciamo univocamente 
le linee e, quindi, non posso risalire ai modelli di DLSAM.

Mi rendo conto che sia un dato importante, ma non è un'informazione che ho.

>
>
> 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.
>
>


Questo spiega perché il cambio di configurazione sia inutile.
Grazie dell'informazione.


>
>
>
> 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).
>
>


Qui forse posso aiutarti io.

Ho risolto un caso simile configurando "ppp lcp predictive" all'interno 
della Virtual-Template del BRAS.

Non ho potuto eseguire test approfonditi perché avrei impattato 
ulteriormente le CPE in produzione, ma nel mio caso ha funzionato come 
una sorta di "reset" che ha permesso a tutti i clienti di 
ri-autenticarsi dopo ore di down e numerosi riavvii.

Cisco dice che questo comando "reduces negotiation time by predicting 
responses from peers and sending expected reply and request packets in 
advance".

Purtroppo non ci sono altri dettagli e non so dirti cosa cambi nella 
segnalazione.

Grazie