[c-nsp] CRB over Multilink

[Andre Beck]

Hi,

after replacing an old E1 leased line setup (using two 1603 and
external CSU/DSU) with a shiny new 2811 having VWIC2-2MFT-T1/E1
installed and adding another E1 leased line, I configured the
two serials as MP and run the connection over Multilink1. Now this
old setup involves CRB where IP is beeing routed, while everything
else (in this case, MOP and LAT) is bridged. Consequently I moved
bridging over to the Mu1 as well, and all seemed perfect.

Now the customer cannot boot a terminal server behind that link. The
MOP request comes in at the central site and is replied, however the
download times out. This has worked before using the 1603s and the
single link. The only obvious problem that I could find using show
and debug commands is that at the central site, I see:

rz-gate#sh bridge 1 group 

Concurrent routing and bridging is enabled.

Bridge Group 1 is running the IEEE compatible Spanning Tree protocol

   Port 2 (FastEthernet0/0) of bridge group 1 is forwarding
   Port 8 (Multilink1) of bridge group 1 is forwarding
      LAT compression is set
      Packets too large for translational bridging: 0 input, 197959 output
                                                             ^^^^^^^^^^^^^
This counter is increasing. If these would be the MOP frames and they
would fail bridging, it would explain the failing download. BUT why
is it talking of translational bridging? This is a trivial transparent
bridging setup. Of course it is remote bridging, but does bridging
using BCP constitute translational bridging? And even if so, why would
there be frames too large to be bridged? Both ends are straight Ethernet
and all relevant frames are the typical size for this medium, so if it
works at all it should as well work with those MOP frames.

I've even forced both sides Mu1 to a MP-MRRU of 2000 and set their MTU
to 2000 as well. Now the link has an MTU large enough to accomodate any
possible translational bridging bloated frame, but it doesn't make any
difference, the counter is still bumping. I didn't find any debug
statement that would emit more information for what bumps the counter,
though, so I'm still poking in the dark.

This is 12.4(1a) BTW.

Anyone with insight in what might be broken here?

TIA,
Andre.
-- 
                  The _S_anta _C_laus _O_peration
  or "how to turn a complete illusion into a neverending money source"

-> Andre Beck    +++ ABP-RIPE +++    IBH Prof. Dr. Horn GmbH, Dresden <-