Linux Advice on Controlled Bridge based on MAC Address with Delay and Dropout

["Bob O'Neil" <boneil@cinci.rr.com>]

[-- Attachment #1.1: Type: text/plain, Size: 6170 bytes --]

IN SHORT 

How to I leverage what is available on the Linux Communcations Stack, either as part of the kernel itself  (i.e. ebtables, netbridge, tcc, iptables, etc.) and/or an addon module , that
allows me to implement a Linux Bridge, with the additional requirement of dropping out Ethernet frames (not bytes) based on a soft setting, and delaying frames (from 4 ms to 10 ms in 1 ms increments) in ONE direction only of the bridge?    This is for a i386 machine with 2 NICS that will need to be in promiscuous mode.


MORE DETAILS

I am trying to determine the best course of action for an application/script that I need to 
compose for execution under Red Hat Linux AS 4.0, Linux Kernel v2.6.x.
 
I have a 386 based Linux machine with two NICs that acts a bit like a bridge, dispatching frames 
at the Data Link Layer (not IP, Layer 3).   On the ingress of NIC 1 (eth0), there will be certain 
frames which have matching MACs that will be consumed (i.e. passed up the stack).   Other frames, 
with a range of matching MAC addresses, broadcast and multicast need to be bridged to the other 
NIC (call it NIC 2, or eth1).     Broadcast and Multicast also need to be consumed, so may have 
two destinations, bridged between NICs and consumed from the internal stack.   I will need to assign
an IP address to the application so that it may act as an SNMP agent.
 
The converse direction follows a similar pattern based on the MAC address, certain frames 
matching a range of MAC address will be bridged to NIC 1 from NIC 2, ones which match the MAC 
address of NIC 2 will be consumed, broadcast and multicast need to be both consumed and forwarded 
to the egress of NIC 1.

The assignments of the IPs, subnets, and subnet masks is flexible.

Now here is the complication that deviates from standard Linux kernel behavior.   ONLY for frames forwarded/bridged from 
NIC 1 to NIC2, there are two soft settings that dictate the forwarding behavior:
 
1. Delay - this may range from say 4 ms to 15 ms.   Based on this setting, ingress frames on NIC 1 
that will be forwarded on to NIC 2 need to be delayed in the process.   The delay timing needs to 
be fairly precise, to the millisecond if possible, and possibly as low as 4 ms.
 
2. Drop Out Percentage - ranges from 0 to 100%.   Based on this setting, ingress frames on NIC 1 
will be dropped based on the percentage set.   The dropout could be a simple uniform dropout, so that if 
the percentage is set to 25%, 1 in 4 frames will be dropped.

Ethernet frames forwarded in the opposite direction (eth1 to eth0) do not have to be delayed or dropped.

I am trying to come up with a design that is optimum, and that takes maximum advantage of what is 
available in the Linux kernel (via NetFilter/IPTables/EBTables/TCC/bctrl, etc.) via commands.

To slow down outgoing traffic, the Tunnel Bucket Filter (TBF) seems like a possible command line 
solution for the delay requirement.   However, of particular concern is the fact that it is byte based
rather than frame based, and it appears it may not guarantee a uniform pacing of frames to the
user specified delay value with fidelity.   In addition, from the document entitled "Linux Advanced Routing & Traffic Control HOWTO",
is the quote:

"However, due to the default 10ms timer resolution of Unix, with 10.000 bits average packets, we 
are limited to 1mbit/s of peakrate!"
 
This statement seems to suggest that the maximum precision for a delay would come at 10 ms 
increments, and it is not clear if a low value, say 4 ms would be possible.
 
For the dropout requirement, perhaps some form of Random Early Drops, although the dropping needs 
to be percise according to a fixed percentage.   The dropping needs to be based probably on frames rather than bytes.

I am considering solutions composed of scripting of the Linux kernel to do all the work entirely, or hybrid approach
as required to supplement the Linux kernel with user code as required.

I considered using the IPTABLES -j QUEUE method to queue contents matching a MAC address range to 
user land queues, where they would programatically be dropped or delayed.  Perhaps a better fit would be
EPTables that deals with Ethernet frames,  However, it would seem these might be problematic for frames 
which have two destinations,  such as broadcast and multicast, which need to be both left on the internal stack and
forwarded/bridged to the other NIC.

Whereas a pure bridge forwards on all content, I also need to maintain an SMNP agent, which will require that frames
matching the IP assigned to the bridge are allowed to pass up the stack for internal consumption.    Forwarding will
also be limited to a range of MAC addresses.   Both NICs will need to operate in promiscuous mode.

It is not entirely clear whether or not I can do bridging (brctl) in combination with ebtables/netfilter/iptables/tcc.

I may to implement some form of the Spanning Tree Protocol (STP), and perhaps DHCP to establish the IP for
the pseudo-bridge.

The lowest level alternative that I have considered, the one with the highest level of control but possible
the most custom coding, is using the  PCAPS (libpcap) frame sniffer technology based on the low level NDIS driver, 
which allows me to get a callback into user land for each frame received by the NIC in promiscuous mode.   Using 
this approach, I would queue or drop frames in a userland application, and then bridge/forward 
them on to the other NIC based on a custom scheduler thread.   This would require me to queue the 
frames in user land, but provides the highest level of control, and perhaps the fastest
forwarding as I would read from one NIC and bridge to the other.   I would also leave the frame 
on the stack so it could have two destinations.  This technique would allow me to delay frames with a fairly
fine grain of precision, but does not take maximum advantage of the services already provided by the Linux
kernel.
 
Interested in what design approach you think will fulfil my goals.   Any direction you can point 
me in would be most appreciated.
 
Bob O'Neil

[-- Attachment #1.2: Type: text/html, Size: 9858 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Bridge mailing list
Bridge@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/bridge