Put in remaining pages and wiki contents.
[ikiwiki.git] / docs / handbook / handbook-network-bridging.mdwn
1 \r
2 \r
3 ## 19.5 Bridging \r
4 \r
5 ***Written by Steve Peterson. ***\r
6 \r
7 ### 19.5.1 Introduction \r
8 \r
9 It is sometimes useful to divide one physical network (such as an Ethernet segment) into two separate network segments without having to create IP subnets and use a router to connect the segments together. A device that connects two networks together in this fashion is called a ***bridge***. A DragonFly system with two network interface cards can act as a bridge.\r
10 \r
11 The bridge works by learning the MAC layer addresses (Ethernet addresses) of the devices on each of its network interfaces. It forwards traffic between two networks only when its source and destination are on different networks.\r
12 \r
13 In many respects, a bridge is like an Ethernet switch with very few ports.\r
14 \r
15 ### 19.5.2 Situations Where Bridging Is Appropriate \r
16 \r
17 There are two common situations in which a bridge is used today.\r
18 \r
19 #### 19.5.2.1 High Traffic on a Segment \r
20 \r
21 Situation one is where your physical network segment is overloaded with traffic, but you do not want for whatever reason to subnet the network and interconnect the subnets with a router.\r
22 \r
23 Let us consider an example of a newspaper where the Editorial and Production departments are on the same subnetwork. The Editorial users all use server `A` for file service, and the Production users are on server `B`. An Ethernet network is used to connect all users together, and high loads on the network are slowing things down.\r
24 \r
25 If the Editorial users could be segregated on one network segment and the Production users on another, the two network segments could be connected with a bridge. Only the network traffic destined for interfaces on the ***other*** side of the bridge would be sent to the other network, reducing congestion on each network segment.\r
26 \r
27 #### 19.5.2.2 Filtering/Traffic Shaping Firewall \r
28 \r
29 The second common situation is where firewall functionality is needed without network address translation (NAT).\r
30 \r
31 An example is a small company that is connected via DSL or ISDN to their ISP. They have a 13 globally-accessible IP addresses from their ISP and have 10 PCs on their network. In this situation, using a router-based firewall is difficult because of subnetting issues.\r
32 \r
33 A bridge-based firewall can be configured and dropped into the path just downstream of their DSL/ISDN router without any IP numbering issues.\r
34 \r
35 ### 19.5.3 Configuring a Bridge \r
36 \r
37 #### 19.5.3.1 Network Interface Card Selection \r
38 \r
39 A bridge requires at least two network cards to function. Unfortunately, not all network interface cards support bridging. Read [bridge(4)](http://leaf.dragonflybsd.org/cgi/web-man?command#bridge&section4) for details on the cards that are supported.\r
40 \r
41 Install and test the two network cards before continuing.\r
42 \r
43 #### 19.5.3.2 Kernel Configuration Changes \r
44 \r
45 To enable kernel support for bridging, add the:\r
46 \r
47     \r
48     options BRIDGE\r
49 \r
50 \r
51 statement to your kernel configuration file, and rebuild your kernel.\r
52 \r
53 #### 19.5.3.3 Firewall Support \r
54 \r
55 If you are planning to use the bridge as a firewall, you will need to add the `IPFIREWALL` option as well. Read [firewalls.html Section 10.7] for general information on configuring the bridge as a firewall.\r
56 \r
57 If you need to allow non-IP packets (such as ARP) to flow through the bridge, there is a firewall option that must be set. This option is `IPFIREWALL_DEFAULT_TO_ACCEPT`. Note that this changes the default rule for the firewall to accept any packet. Make sure you know how this changes the meaning of your ruleset before you set it.\r
58 \r
59 #### 19.5.3.4 Traffic Shaping Support \r
60 \r
61 If you want to use the bridge as a traffic shaper, you will need to add the `DUMMYNET` option to your kernel configuration. Read [dummynet(4)](http://leaf.dragonflybsd.org/cgi/web-man?command#dummynet&section4) for further information.\r
62 \r
63 ### 19.5.4 Enabling the Bridge \r
64 \r
65 Add the line:\r
66 \r
67     \r
68     net.link.ether.bridge=1\r
69 \r
70 \r
71 to `/etc/sysctl.conf` to enable the bridge at runtime, and the line:\r
72 \r
73     \r
74     net.link.ether.bridge_cfg=`***if1***`,`***if2***`\r
75 \r
76 \r
77 to enable bridging on the specified interfaces (replace `***if1***` and `***if2***` with the names of your two network interfaces). If you want the bridged packets to be filtered by [ipfw(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#ipfw&section8), you should add:\r
78 \r
79     \r
80     net.link.ether.bridge_ipfw=1\r
81 \r
82 \r
83 as well.\r
84 \r
85 ### 19.5.5 Other Information \r
86 \r
87 If you want to be able to [telnet(1)](http://leaf.dragonflybsd.org/cgi/web-man?command#telnet&section1) into the bridge from the network, it is correct to assign one of the network cards an IP address. The consensus is that assigning both cards an address is a bad idea.\r
88 \r
89 If you have multiple bridges on your network, there cannot be more than one path between any two workstations. Technically, this means that there is no support for spanning tree link management.\r
90 \r
91 A bridge can add latency to your [ping(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#ping&section8) times, especially for traffic from one segment to another.\r
92 \r
93 \r
94 \r
95 CategoryHandbook\r
96 CategoryHandbook-advancednetworking\r