Difference between revisions of "Bering-uClibc 4.x - User Guide - Advanced Topics - Setting Up a Bridge"

Latest revision as of 13:23, 9 April 2011

Objectives

We assume here that you want to implement a Bering-uClibc 4.x machine as an Ethernet "Bridge" which connects together two Ethernet network segments at Layer 2 of the OSI model. This can be desirable for a number of reasons:

• To overcome the physical limitations of Ethernet installations (such as maximum cable lengths).
• In order to implement some sort of processing or filtering of traffic passing through the bridge:
  • Emulation of WAN characteristics on a LAN link.
  • Quality of Service or Bandwidth Management.

Note: This procedure configures Bering-uClibc 4.x as a Bridge rather than a Router and hence firewalling cannot be done with Shorewall. Bridge supports only filtering on the FORWARD Chain. Shorewall defines rules on input, output, forward and its own tables. If the custom built tables get packets redirected from the FORWARD table, filtering would work. If Shorewall based firewalling is also needed, then the bridge should be replaced by a ARP Proxy set-up for which a quick and dirty setup document is available from Rick Onanian. This setup is, however, simpler to configure and manage.

Importance of such a configuration: If we were to plug a LEAF box in as a bandwidth manager or a firewall and can do so in a transparent fashion - meaning none of the computers need to be reconfigured in any form for IP gateways or subnets. This makes it easy to plug this in and out of a production network without users realizing except for maybe throttling of bandwidth. This also improves the capability to provide greater uptimes.

Step 1: Declare the bridge.lrp Package

The bridge.lrp Package implements the brctl command and also if-up and if-down hooks.

Add the bridge Package to the LRP list in leaf.cfg as described in the LEAF Packages Chapter.

Step 2: Install the kernel Modules

In order to have the bridge working, you need to have bridging support enabled through the appropriate kernel Modules.

You also need to load the driver Module of the network cards assigned to your "External" and "Internal" network links. With Bering-uClibc 4.x this is most easily accomplished by using the automatic hardware detection facility described in the Basic System Configuration Chapter.

The extra kernel Modules which implement the bridging functionality need to be installed into directory /lib/modules/. Once present in this directory they will be loaded automatically when required. Note that this is rather different from the behaviour with Bering-uClibc 3.x where the Modules also had to be explicitly declared in file /etc/modules.

Extract the following Module files from modules.tgz and copy them to directory /lib/modules/. Take care to remove the directory structure levels - the .ko files need to be located directly in /lib/modules/ and not in a sub-directory of that.

• kernel/net/bridge/bridge.ko
• kernel/net/llc/llc.ko
• kernel/net/802/stp.ko

Once these files have been copied to directory /lib/modules/ they need to be registered with the module loading system. This can be done manually by running the following command:

depmod

Note that this is done automatically at boot time.

Step 3: Configure the bridge system

Invoke lrcfg and choose 1) Network configuration and then 1) Network Interfaces. In the interface file, comment out all lines except those for the bridge (also leave the "loopback" lines un-commented):

(...)
 #Step 4 (optional): configure a bridge
 auto br0
 iface br0 inet static
        address 192.168.1.254
        netmask 255.255.255.0
        broadcast 192.168.1.255
        bridge_ports all
 

The address is not mandatory for the system to work as a bridge but will be necessary if you want to log into the system and manage / configure / monitor the system over the network.

Note: Please remember that all other auto configuration and address configurations for all other interfaces should be commented out as they become slaves to the bridge and do not have an individual identity.

Step 4: Check if the bridge is working properly

Save the configuration (through the LEAF backup menu entry - remember to save the Modules as well as the Configuration). Physically connect the bridge machine into the network.

Reboot, the system should show a message similar to:

Configuring network interfaces: Waiting for br0 to get ready (MAXWAIT is 30 seconds).

In logfile /var/log/messages you should see messages similar to the following:

Bridge firewalling registered
NET: Registered protocol family 10
device eth0 entered promiscuous mode
e100 0000:00:0a.0: eth0: NIC Link is Up 100 Mbps Full Duplex
ADDRCONF(NETDEV_UP): eth0: link is not ready
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
device eth1 entered promiscuous mode
eth1: DSPCFG accepted after 0 usec.
eth1: link up.
eth1: Setting full-duplex based on negotiated link capability.
br0: port 2(eth1) entering learning state
br0: port 2(eth1) entering learning state
br0: port 1(eth0) entering learning state
br0: port 1(eth0) entering learning state
br0: port 2(eth1) entering forwarding state
br0: port 1(eth0) entering forwarding state

Try to ping the gateway from any system. If the ping goes through well, the bridge is working properly. If not, check the cables and the type of cable used. If a straight cable is used between the Bering box and the router, switch it for a crossed cable and re-try the ping.

Try the following command:

ip addr show dev br0

A device called br0 should show up with the IP address details configured.

Note: The bridge to router cable would need to be a straight CAT5 cable as switch to router would normally be a crossed cable. It would do good to have a straight and a crossed cable handy so that both can be tried out.

Step 5: Using the utilities

bridge.lrp, when installed, provides if-up and if-down files for the bridge to enable custom scripts to run - one good example may be sending mails out to indicate up and down status of the interface.

brctl is the bridge control utility. brctl show shows all bridges with enslaved interfaces. Since this is most likely the only bridge, you can switch the Spanning Tree Protocol off by giving:

brctl br0 stp off