ebtables for the rescue! ;-)

Before delving into ebtable tool, I would like to give a short introduction.
ebtables is part of the netfilter framework. it's a mechanism for inspecting packets in L2 (Data-link Layer).
The inspection is done by entering rules into the tables,
Those tables are divided according to theirs functionality, which holds different sets of rules.
The ebtables supports 3 built-in tables: FILTER, NAT and  BROUTE.

comment: In case you haven't specified the table's name in the rule , the rule would be added by default to the FILTER table.


Chain is set of ordered list of rules that can match a L2 frame.
In case a rule matches a frame it would take an appropriate action defined by the user, the action is usually called TARGET.

A Target can be one of the following values: DROP, ACCEPT, CONTINUE, RETURN or user's extension for jumping to user defined chain. The meaning of each value is simple :

DROP - The frame should be dropped in the current chain (expect for the broute table, which means the packet should be routed)
ACCEPT - The frame should be passed away (expect for the broute table, which means the packet should be bridged)

CONTINUE - The following rule should be checked on the current frame
RETURN - Exiting from the current chain and returning to the calling chain, and checking the next rule from the previous chain.


Here I'll be talking about each table, and it's properties.

So probably you are asking yourself what are the differences between those tables? and what are their usage?

• The NAT table is used mostly for MAC-NAT, which means for modifying the mac addresses , either the source mac or destination mac or both. It consists three built-in chains, I have illustrated in the sketch below those chains: PREROUTING, POSTROUTING, OUTPUT.

Comment: A more precise name would be PREFORWARDING instead of  PREROUTING since we are talking about L2 which no routing takes part. The reason for this convention was since the ebtables is the ancestor of iptables.
                  

• The FILTER table consists three built-in chains, I have illustrated in the sketch below, those chains are: FORWARD, INPUT, OUTPUT.

• The broute table is for deciding which traffic to route between two interfaces, and which traffic to bridge between two interfaces so it has a single chain. 

In case according to user's rule the traffic should be route between two interfaces, it means the bridge code won't touch the frame and it would be sent up to the higher network layers.


The hooks are in specific places in the network code on which software can attach itself to process the packets/frames passing that place. For example, the kernel module responsible for the ebtables FORWARD chain is attached onto the bridge FORWARD hook. This is done when the module is loaded into the kernel or at bootup. 

Those seven hooks defined in the Linux bridging code, can be seen in the sketch #3:

As we can see the Broute chain is traversed very early.


The ebtable tool also provides the ability to mark frames via an unsigned numbers, those numbers is embedded into the frame.
Those marks are meaningful and later can be easily observed, via those marks the correct actions can be taken later on.


In case you are curious where those marks are stored, you can easily find it in the sk_buff struct (\include\linux\skbuff.h), there is a field called mark which saves the marks for each frame in the skb.


In this post I haven't referred to the commands syntax, since it is written clear on the man pages of ebtables, I suggest you to read those pages :-)

Oh I stumble upon Jan Engelhardt's illustration which demonstrates very well the frame's flow in the network stack, it can be seen here:

Netfilter packet flow

As we can see in the image there are much more chains since iptables' chains are
mentioned too. In the future posts to come, I'll be talking about iptables.