Ron,
: Today: To get traffic for our IDS sensors and a billing system,
: we collect everything at our core switches (2) by connecting a
: SPAN port from each switch to a server (so, 2 interfaces
: collecting traffic). That server changes the destination MAC
: address on all traffic to that of another server running iproute
: and sends it out a third interface. The server running iproute
: collects the traffic on one interface, and sends traffic to
: different sub interfaces depending on the network; a switch
: connected to the outgoing traffic allows connection of the IDS
: sensors, billing system, etc.
This, right? --- two SPAN ports
/
+----------+ / +----------+ +----------+
| switch |-----| | | |
+==========+ | eth_rewr |-----| p_router |----- other systems
| switch |-----| | | |
+----------+ +----------+ +----------+
So, you essentially want to conflate the eth_rewr box and the
p_router box, correct?
: 1. Just run iproute, having it take the traffic from the SPAN
: ports and policy route without having to have the first server
: change destination MAC addresses.
: a. Can iproute do policy routing on traffic not destined for it in
: the first place (i.e. by having the interfaces in
: promiscuous mode)?
: b. If not, then does iproute contain functionality that would allow
: it to sense all traffic and change the destination MAC
: address or IP address?
Strictly speaking, the problem here doesn't have anything at all to
do with iproute. The switch is transmitting frames with ethernet
headers bound for their real destinations. The eth_rewr box simply
rewrites the ethernet frame headers so that they have the MAC
address of the p_router interface.
I can't see how this proposed solution will be viable for you.
: 2. Have EBTables and iproute running on the same box if #1 above isn't
: possible.
:
: a. Can we do this without having to have more interfaces in the
: box, connected to each other with crossover cables?
I think this approach is much more likely to yield fruit. Although
I have not yet done anything like this. Consider using the ebtables
broute/BROUTING table/chain. You may find this documentation [0]
helpful in looking at the problem again. In particular, Joshua
Snyder's diagram [1] should be able to illustrate to you a possible
solution where ebtables and iproute are running on the same box.
To quote from the ebtables manpage:
The targets DROP and ACCEPT have special meaning in the broute
table. DROP actually means the frame has to be routed, while
ACCEPT means the frame has to be bridged.
Thus, you should be able to do something like the following on the
policy router (assume your MAC on eth1/br0 is 00:80:c8:e8:1e:fc):
ebtables --table broute \
--append BROUTING \
--in-if eth1 \
--dst ! 00:80:c8:e8:1e:fc \
--jump redirect --redirect-target DROP
So, now you have frames leaping happily up to the IP stack and your
policy router. I don't know what the performance implications are
of running both ebtables and policy routing on the same machine.
Good luck,
-Martin
[0] http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html
[1] http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png
--
Martin A. Brown
http://linux-ip.net/
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
