From eb76f3d9a1bd02b8c400768397e7d9d92997759e Mon Sep 17 00:00:00 2001
From: Bart De Schuymer
It is possible to use ebtables without compiling the br-nf
- code into the kernel. The only reason why the ebtables patch
+ code into the kernel; and vice versa. The only reason why the ebtables patch
has to be applied after the br-nf patch is because some files are
- changed by both patches.
+ changed by both patches.
+ The explanations below will use the TCP/IP Network Model.
+ It should be noted that the br-nf patch sometimes violates the TCP/IP Network
+ Model. As will be seen later, it is possible, f.e., to do IP DNAT inside the Link Layer.
+ We want to note that we are perfectly well aware that the word frame is used for the Link Layer,
+ while the word packet is used for the Network Layer. However, when we are talking about IP packets
+ inside the Link Layer, we will refer to these as frames/packets or packets/frames.
@@ -85,8 +91,7 @@ First thing to keep in mind is that we are talking about the Ethernet layer here, so the OSI layer 2 (Data link layer), or layer 1 (Link layer, Network Access layer) by the TCP/IP Network - Model. All samples below will be explained according to the TCP/IP - Network Model. + Model.
A packet destined for the local computer according to the
@@ -125,7 +130,7 @@
process
- Ebtables has three built in tables: + Ebtables has three tables: filter, nat and broute, as shown in Figure 2c.
- When a NIC enslaved to a bridge receives a frame, the frame + When an NIC enslaved to a bridge receives a frame, the frame will first go through the BROUTING chain. In this special chain you can choose whether to route or bridge frames, enabling you to make a brouter. The definitions found on @@ -184,7 +189,7 @@ If the frame passes this chain, the bridging code will decide where the frame should be sent. The bridge does this by looking at the destination MAC address, it doesn't care about the - Network layer addresses (e.g. IP address). + Network Layer addresses (e.g. IP address).
+ Figures 3c and 3d assume the IP packet arrived on a bridge port.
What is obviously "asymmetric" here is that the
iptables PREROUTING chain is traversed before the
ebtables INPUT chain, however this cannot be
@@ -355,7 +361,11 @@
This is at the same place as where the ebtables nat
PREROUTING chain will be traversed (for the same reason).
This should explain the asymmetry encountered in Figures 3c
- and 3d.
+ and 3d.
+ One should also be aware of the fact that frames for which the
+ bridging decision would be the fourth from the above list will
+ be seen in the PREROUTING chains of ebtables and
+ iptables.
@@ -363,7 +373,7 @@
A bridged packet never enters any network code above layer - 1 (Link layer). So, a bridged IP packet/frame will never enter the + 1 (Link Layer). So, a bridged IP packet/frame will never enter the IP code. Therefore all iptables chains will be traversed while the IP packet is in the bridge code. The chain @@ -399,11 +409,11 @@
To make this possible the iptables chains have to be traversed after the bridge code decided where the frame - needs to be sent (eth0, eth1, both or none). This has some + needs to be sent (eth0, eth1 or both). This has some impact on the scheme presented in section 3 (so, we are looking at routed - traffic here). It actually looks like this (in the case of - Figure 3c): + traffic here, entering the box on a bridge port). It actually + looks like this (in the case of Figure 3c):
@@ -442,14 +452,14 @@ iptables nat OUTPUT chain):
- The 'normal' way locally generated packets would go through + The normal way locally generated packets would go through the chains looks like this:
- Figure 6c. The 'normal' way for locally generated
+ Figure 6c. The normal way for locally generated
packets
@@ -460,28 +470,17 @@
- Figure 6d. The 'actual' way for locally generated
+ Figure 6d. The actual way for locally generated
packets
Note that the iptables nat OUTPUT chain is traversed while the - packet is in the IP code, while the iptables filter OUTPUT chain - is traversed when the packet has entered the bridge code. + packet is in the IP code and the iptables filter OUTPUT chain + is traversed when the packet has passed the bridging decision. This makes it possible to do DNAT to another device in the nat OUTPUT chain and lets us use the bridge ports in the filter OUTPUT chain.
-- Note that in Figures 6a and 6d the iptables - POSTROUTING chain is traversed before the ebtables - POSTROUTING chain, while it's the way around for Figure 5. - The rule is as follows: -
-7. Two possible ways for frames/packets to pass through the @@ -516,7 +515,7 @@ More details:
- The idea is that traffic between 172.16.1.4 and 172.16.2 is + The idea is that traffic between 172.16.1.4 and 172.16.1.2 is bridged, while the rest is routed, using masquerading.
@@ -627,7 +626,7 @@ Copyright (c) 2002 Bart De Schuymer <bart.de.schuymer@pandora.be>,
"http://www.gnu.org/licenses/fdl.txt">"GNU Free Documentation License".
- Last updated July 9, 2002. + Last updated July 21, 2002.