Bob O'Neil
2009-Feb-10 12:51 UTC
[Bridge] Linux Advice on Controlled Bridge based on MAC Address with Delay and Dropout
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/bridge/attachments/20090210/a79a5a77/attachment-0001.htm