|
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 Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/bridge
