IPv4 Bridging, Proxy ARP and Linux Bridging Julian Anastasov , July-September 2002 CONTENTS: 1. Files 2. Proxy ARP 3. IP Mode for the Linux Bridging 4. Examples 4.1 Proxy ARP 4.2 IP Mode with symmetric routes 4.3 IP Mode with asymmetric routing 5. Usage 6. TODO 1. Files Patches: - Medium ID: medium_id-2.4.18-2.diff (in 2.4.19pre5) medium_id-2.2.20-2.diff - rp_filter_mask: extending rp_filter for mediums rp_filter_mask-2.4.19pre6-1.diff - IP Mode for Linux Bridging: bridge-ipmode-2.4.19-2.diff bridge-utils-0.9.5-ipmode-1.diff Installation: Patch kernel: root@l:/usr/src/linux# cat /tmp/bridge-ipmode-2.4.19-2.diff | patch -p1 Build kernel with Linux Bridging support, the IP Mode does not provide additional configuration options Patch the bridge utils to add option for switching the IP Mode: root@l:/tmp# tar xfz /tmp/bridge-utils-0.9.5.tar.gz root@l:/tmp# cd bridge-utils/ root@l:/tmp/bridge-utils# cat /tmp/bridge-utils-0.9.5-ipmode-1.diff | patch -p1 root@l:/tmp/bridge-utils# make Usage: # Enable IP Mode for bridge and receive IP traffic on the slave ports brctl ipmode br0 yes # Disable IP Mode for bridge (default state for the Bridging) brctl ipmode br0 no References: medium_id.txt - Explains the medium_id flag usage This document explains how to achieve the fun of combining all these features into advanced router. As usually, the things start from something. In this case the basic knowledge is the mediums: we must configure the medium_id values for all devices we want to use for proxy ARP or Bridging. As shown in the title, the Linux Bridging can be another user of the medium_id values. Of course, the medium_id configuration is optional. Read below. 2. Proxy ARP medium_id.txt already explains the usage of medium_id for proxy ARP. The file medium_id.txt is more accurate in explaining the medium_id configuration. We only must note that the knowledge about the mediums does not depend on the proxy ARP feature. 3. IP Mode for the Linux Bridging As we already know, in the default Bridging mode we receive the frames on the master bridging interface. The routes also point to the bridging interfaces. Other hosts on the LAN see only one MAC address, the address configured on the bridging interface. The result is symmetric traffic through the master bridging interfaces although the traffic is in fact received on the slave ports and transmitted again through the slave ports. Part of the received traffic not destined to our box is simply forwarded between the slave ports in each bridge. It means the IP stack can not see this traffic. Sometimes we want to add additional control on what is forwarded between the slave ports. This is the reason the IP Mode was created. The IP Mode can be enabled per bridge (it is disabled by default). If enabled, we achieve the following goals: - the incoming traffic destined to our box is received on the real slave interface, not on the bridging interface as the default mode - to allow asymmetric routing the ARP traffic is also received on the master bridge interface (of course, our replies can be tuned via arp_filter). This is performed for the ARP requests and replies, broadcast or unicast. By this way the neighbouring code can receive the ARP traffic no matter on what interface the remote hosts are resolved (what interface is used for the output traffic). - the slave ports are in promisc mode as usual - the unicast IP traffic destined to another slave port which is usually forwarded at Layer 2 is passed up, i.e. it is received on the slave interface as destined to local hardware address. This allows the IP stack to inspect it and to apply all forwarding rules in the higher layers including firewalling between slave ports, NAT, QoS, i.e. everything we can do with the traffic destined to our hardware address. The IP Stack does not notice that the IP Mode changes the target hardware address of the received frame to a local one. - we are free to use the master bridging interface or the slave ones for the outgoing traffic. There is no restriction to put routes and addresses only on the master bridging interface. - to deal with the reverse path protection in IP Mode we can define a rp_filter_mask of allowed mediums. By this way we can safely configure rp_filter for the slave bridge ports and then to use a route for the used subnet on the master bridge interface. To achieve this we configure unique medium_id value for the master bridge interface and then set its bit in the rp_filter_mask of all its slave interfaces. As result, the asymmetric traffic (input on slave interface and output on master interface) can be secured (even when the slave ports are attached to different mediums) and to protect all other interfaces from spoofed traffic from the configured bridge. 4. Examples 4.1 Proxy ARP The example for proxy ARP can be found in medium_id.txt 4.2 IP Mode with symmetric routes Here is the example mentioned in medium_id.txt this time configured with IP Mode of the Bridging. 10.0.0.1 -----------------------+--------------- hub 1 |eth0 +-------+-------+ | ROUTER | +----+------+---+ 10.0.0.2 eth1| |eth2 192.168.0.2/24 10.0.0.0/24 -----------------+------+----------- hub 2 The difference: - eth0 and eth1 are slave ports for a master bridge interface (the only bridge we use in this example) brctl ipmode br0 yes - we don't need to configure proxy ARP between eth0 and eth1 because our bridge is transparent for the ARP protocol (the proxy ARP is performed from the Bridging, i.e. the ARP traffic is forwarded between the slave ports). - the routes to each host and subnet remain strictly through the slave ports eth0 and eth1, so the routing is symmetric and the reverse path protection can work The benefit of such setup compared to the proxy ARP solution is that it allows broadcast traffic (such as DHCP) to work between the two mediums. Of course, the directed broadcasts should be stopped in the border router. The setup remains secure against spoofing with the exception for the broadcasts. 4.3 IP Mode with asymmetric routing The following example covers a case similar (in settings) to the default Bridging Mode where the routes are configured on the master bridge interface. As result, the outgoing traffic is sent through the master bridge interface. The slave interfaces usually do not have routes configured or more exactly, in our example. We are free to configure any other routes on the slave ports not related to the ones configured on the bridging interface. The only difference from the default mode is that in IP Mode we intercept the traffic forwarded between the slave ports and forward it via the IP Stack. In this case the IP traffic leaves our box with our hardware source address. Many hosts from 10.0.0.0/24: 10.0.0.1, 10.0.0.3, ... ------------------------+--------------- hub 1 |eth0 +-------+-------+ | ROUTER | +----+------+---+ 10.0.0.2 eth1| |eth2 192.168.0.2/24 ---------------------+------+----------- hub 2 Many hosts from 10.0.0.0/24: 10.0.0.4, 10.0.0.5, ... # Enable the IP protocol on all devices ip addr add 0.0.0.0 dev br0 ip addr add 0.0.0.0 dev eth0 ip addr add 0.0.0.0 dev eth1 ip addr add 0.0.0.0 dev eth2 # Define medium_id only for the bridge interface, it is # used only from rp_filter_mask in the slave ports echo 3 > /proc/sys/net/ipv4/conf/br0/medium_id # Enable the reverse path protection echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter # Use reverse path protection for all slave ports echo 1 > /proc/sys/net/ipv4/conf/eth0/rp_filter echo 1 > /proc/sys/net/ipv4/conf/eth1/rp_filter # Restrict ARP according to the routes echo 1 > /proc/sys/net/ipv4/conf/br0/arp_filter echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_filter echo 1 > /proc/sys/net/ipv4/conf/eth1/arp_filter # The slave ports should allow traffic from 10.0.0.0/24, i.e. # when the reverse path points to medium 3 (2^3=8) echo 8 > /proc/sys/net/ipv4/conf/eth0/rp_filter_mask echo 8 > /proc/sys/net/ipv4/conf/eth1/rp_filter_mask # the public subnet on pseudo medium 3 ip addr add 10.0.0.2/24 brd + dev br0 # Internal private subnet ip addr add 192.168.0.2/24 brd + dev eth2 # Enable IP Mode for br0 brctl ipmode br0 yes # Set the link up ip link set br0 up ip link set eth0 up ip link set eth1 up ip link set eth2 up 5. Usage - No Bridging - No problems - Upgrade to symmetric routing and IP Mode of the Linux Bridging if forwarding of broadcasts is needed. Correct routes through slave ports are required. In this case we use the bridging knowledge on what slave port each host is present and avoid Layer 3 forwarding to the sender's slave port. - Upgrade to asymmetric routing and IP Mode of the Linux Bridging if additionally we want the Linux Bridging to select the right slave port for the outgoing packets sent for particular subnet. In this case we place some of our routes on the master interface. - Upgrade to the default Bridging functionality if you do not care about Layer 3 forwarding of the packets or if prefering other Bridging extensions achieving the same goal. 6. TODO Decide where to deliver (on the slave or master interface) the non IP/ARP traffic in IP Mode. Currently, it is delivered on the slave port.