LARTC - Apr 2006 - EBTables, iproute, etc.

Good morning,
 
I''m writing to ask for collaboration in finding an improvement to a
particular process.
 
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.  
 
The challenge:  I''d like to be able to do one of the following:
 
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?
 
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?
 
Thanks in advance for offering feedback or suggestions regarding what we
hope to do.
 
Ron


_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

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/