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
_______________________________________________
Bridge mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/bridge
