On Mon, 28 Oct 1996 11:42:50 +0100 (MET), you wrote:
>Does anyone know what the Link-Disc-for-BACP stuff is ?
I can tell you more than I know in a couple of sentences...
I think BACP (Bandwidth Allocation Control Protocol) is the new,
open from the ground up, proposal for how to do add/drop
of links in an MP bundle. It is designed to support what folks
sometimes loosely refer to as "bandwidth on demand"; analagous
to Ascend's MP+. I don't think the PM supports it yet.
As an experiment, you might want to see if there is a way to
tell the Planet card/software to only use a single channel.
Re the debug output: Is that all there is?
What is here looks a little suspicious, but I don't have enough
experience to say for sure:
>Received LCP_CONFIGURE_REQUEST on port S29 of 31 bytes containing:
>01 02 00 23 01 04 05 dc 11 04 05 dc 13 13 01 6c=20
>4b 91 98 11 8a 66 ff cd bd 17 f3 7b e3 52 58 17=20
>04 00 00=20
>Fixed #bytes to match #found...
>Recvd from port S29: 37 bytes LCP Request-2=20
> Max-Recieve-Unit =3D 1500
> MP-MRRU =3D 1500
> MP-Endpoint-Disc =3D 0x016c4b9198118a66ffcdbd17f37be35258
> Link-Disc-for-BACP =3D 0x0000=20
Remote requests MP stuff and BACP. Not sure why this is request #2,
maybe the PM missed its first one?
>Sending LCP_CONFIGURE_REQUEST to port S29 of 29 bytes containing:
>01 02 00 1d 05 06 24 0d e9 a9 03 04 c0 23 11 04=20
>06 1c 12 02 13 09 03 00 c0 05 01 4a 51=20
>Sent to port S29: 31 bytes LCP Request-2=20
> Magic-Number =3D 0x240de9a9
> Authentication-Protocol =3D PAP
> MP-MRRU =3D 1564
> MP-Short-Seq-Num-Header
> MP-Endpoint-Disc =3D 0x0300c005014a51=20
PM requests the usual MP stuff. Again, not sure why this is req #2.
Is this perhaps just a partial listing of the debug output?
>Sending LCP_CONFIGURE_REJECT to port S29 of 8 bytes containing:
>04 02 00 08 17 04 00 00=20
>Sent to port S29: 10 bytes LCP Reject-2=20
> Link-Disc-for-BACP =3D 0x0000=20
PM says: I don't understand BACP. This is ok for it to do.
>Received LCP_CONFIGURE_REQUEST on port S29 of 31 bytes containing:
>01 02 00 23 01 04 05 dc 11 04 05 dc 13 13 01 6c=20
>4b 91 98 11 8a 66 ff cd bd 17 f3 7b e3 52 58 17=20
>04 00 00=20
>Fixed #bytes to match #found...
>Recvd from port S29: 37 bytes LCP Request-2=20
> Max-Recieve-Unit =3D 1500
> MP-MRRU =3D 1500
> MP-Endpoint-Disc =3D 0x016c4b9198118a66ffcdbd17f37be35258
> Link-Disc-for-BACP =3D 0x0000=20
This is where things look suspicious. Notice that this is also tagged as
LCP req #2. I'm not sure if it is illegal, but usually the remote =
increments
the request # with each new request.
Also, after receiving a reject of an option (BACP), I believe the remote
is supposed to drop it from further requests. It could be that the
reject and this last request "crossed in the mail", but eventually,
the remote should have sent a new request without the BACP option.
Not sure why the log would stop here.
Hope this helps,
Bill