On 28 January 2017 at 23:41, Bjoern A. Zeeb
<[email protected]> wrote:
>> 28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Tx
>> 8021:IPCP 01 00 000A ConfReq 03:IP 06 62.24.191.98  [email protected]
>
>
> You tell CPE your IP address.

Which seems to be a TalkTalk IP?!

> But the CPE never ACKs.
> And the CPE also doesn’t send you a request for its local IP address end.

It does, here I believe:

28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461
PPP Rx FF03 8021:IPCP 01 01 0016 ConfReq 03:IP 06 0.0.0.0 81:DNS1 06
0.0.0.0 83:DNS2 06 0.0.0.0  [email protected]

28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461
PPP Tx 8021:IPCP 03 01 0016 ConfNak 03:IP 06 46.17.214.185 81:DNS1 06
185.23.52.131 83:DNS2 06 185.23.52.132  [email protected]

>> 28 Jan 2017 19:24:22 l2tp-rx T10838-3606-62.24.203.91 S24816-43992 PPP Rx
>> FF03 C021:LCP 08 B1 0040 ProtoRej AAAA 03 00 00 00 08 06 00 13 08 00 00 00
>> 00 08 04 00 00 00 71 q 72 r 73 s 74 t FD 12 A5 AD BA 38 8 8E BD FB 55 U 50 P
>> 18 10 00 F8 E0 00 00 17 03 03 00 50 P D6 07 80 20   81 D2 6F o 57 W B8 CC 9C
>> 2E . 0F
>> 28 Jan 2017 19:24:22 l2tp-rx T10838-3606-62.24.203.91 S43511-28544 PPP Rx
>> FF03 C021:LCP 08 E9 001C ProtoRej AAAA 03 00 00 00 08 06 00 13 08 00 00 00
>> 00 08 04 00 00 00 71 q 72 r 73 s 74 t
>
>
> Whatever those are I am confused about;

That CPE is trying to make some sort of AAAA query I think.


> Seems the state machine on the CPE side is stuck?

Yeah it looks a bit flaky.



On 28 January 2017 at 15:12, Gareth Phillips
<[email protected]> wrote:
> ·         We’ve tried a RADIUS Filter-ID of "l" (lower case L) to stop MRU
> renegotiation and a similar hard coded setting on the L2TP LNS tunnel for
> those particular circuits.
>

Why have you done that? We are an LLU provider but also take wholesale
BT and TalkTalk connectivity to ensure total coverage. We force MRU
renegotiation for those wholesale circuits, particularly for BT where
their BRAS nodes seem to interfere; going through the whole PPP state
machine life cycle (including LCP, NCP, IPCP etc) part of the process
is performed between CPE and BRAS, then the L2TP tunnel is built, and
the later part is performed between CPE and LNS. Due to NOT having
performed the entire process with the BRAS we sometimes see side
effects so we always force MRU renegotiation to start most of the
process again with the CPE talking directly to the LNS.

What happens if you try this?

Also what do you see in your RADIUS log? Does the LNS report to RADIUS
that the authentication has been successful? From your output and
Bjoren's output it looks like auth is OK then negotiation fails near
the end of LCP.

Have you considered upgrading the firmware on you CPE and LNS devices?
Test it in the lab?

Cheers,
James.

Reply via email to