MAC Layer Bridging via PPP

Problem

How to configure a Columbus Client (former ix1-connect/WS) for Media Access Control Layer Bridging (MLB)?

Solution

The current version of the Columbus Client not only supports the "normal " PPP operating modes IP and IPX but is also able to handle the so called Media Access Control Layer Bridging (MLB). This mode can be activated by setting the value for MLB to enabled (MLB = ENABLED) in the partner configuration. This leads to connections with a remote bridge (also called half bridge) or with a router with bridge functionality by means of PPP MLB.

All packets on the MAC level are forwarded transparently. A connection between a workstation and a bridge is thus independent of the implementation of the layers higher than the MAC-layer. This offers the user the option of using any protocol, thus ensuring that non routable protocols such as DECnet, AppleTalk, NetBIOS or NetBEUI can be used on an ISDN - WAN line without any problems whatsoever.

A concrete and popular illustrative example is binding a workstation into a Windows for Workgroups-Network. A connected Columbus Client is seen by the remote bridge as if it were in the local network. The bridge forwards all such data packets to the ISDN workstation which

are directly addressed to the workstation involved,

have an unknown destination which is not within the LAN in which the bridge resides,

are sent as ethernet broadcasts or multicasts.

Many remote bridges and/or routers (e. g. products by Cisco, 3Com, Retix, Wellfleet) can function as a mixture of router and bridge. Such solutions are often called "brouter" (bridge router), "routing bridge" or "bridging router". The routeable protocols (e.g. IP and IPX ) are routed. The remaining non routeable protocols are handled by the integrated bridging. The MLB functionality in the Columbus Client is consequently a very profitable and unique feature which offers almost unlimited interoperability with regard to network protocols.

Attention: When using PPP MAC layer bridging make sure to take into consideration that the protocol overhead will grow. This can easily be explained by the fact that the described transparency of the data transmission can only be realised by transferring complete ethernet packets. Aside from this fact the actual efficiency of the short hold is directly subject to the specific nature of the used protocols.