[Bro] Software frontend
sstattla at gmail.com
Thu Dec 9 11:03:56 PST 2010
Good news is that I got it to work for a simple case- 1 Frontend node
and 1 Worker node. So the job is use Click to simply relay all traffic
entering Frontend to a Worker node. Here are the steps-
1. Enterprise traffic comes in at Frontend's interface eth0
2. Source MAC Address of the packet is changed to Frontend's eth3's MAC
3. Destination MAC Address of packet is changed to Worker's eth3's MAC
4. Packet is sent to Frontend's eth3 for delivery.
The Click script looks like-
FromDevice(eth0, PROMISC true) -> StoreEtherAddress(an:on:ny:mi:ze:d1,
OFFSET src) -> StoreEtherAddress(an:on:ny:mi:ze:d2, OFFSET dst) -> Queue
To debug, I simply used tcpdump to check at interfaces eth0 and eth3 on
Frontend, and interface eth3 (with -e flag for displaying MAC address)
to check if the packets were reaching.
For multiple workers, one can use a Hash function (as described earlier
in this thread) to calculate the destination Worker MAC address.
On 10-12-07 2:20 PM, Tyler T. Schoenke wrote:
> Hi Sunjeet,
> I have hardly worked with Click, and don't have experience with
> troubleshooting it. Your best bet is to sign up with their mailing
> list at the bottom of the page on the following link.
> If you get it working, please follow up with the working configuration.
> On 12/7/10 2:50 PM, Sunjeet Singh wrote:
>> Hi Tyler,
>> Can you please help me troubleshoot here? I did what you said (on Linux
>> so some function option-parameters are gone), and here's what my click
>> script looks like (currently testing with one frontend machine and one
>> worker machine)-
>> AddressInfo(mymac<IP add. of frontend/8> <mac add of eth0>);
>> AddressInfo(worker1<IP add. of worker1/8> <mac add of worker eth0>);
>> AddressInfo(worker2<IP add. of worker1/8> <mac add of eth1>);
>> AddressInfo(worker3<IP add. of worker1/8> <mac add of eth2>);
>> my_switch :: HashSwitch(26, 8);
>> FromDevice(eth4, PROMISC true) -> my_switch;
>> todevice1 :: ToDevice(eth0);
>> todevice2 :: ToDevice(eth1);
>> todevice3 :: ToDevice(eth2);
>> my_switch -> EtherEncap(0x0800, mymac, worker1) -> Queue ->
>> my_switch -> EtherEncap(0x0800, mymac, worker2) -> Queue ->
>> my_switch -> EtherEncap(0x0800, mymac, worker3) -> Queue ->
>> When I run the script with the command "sudo click try.click", it starts
>> executing and gives no messages. To test it,
>> I used tcpdump to first see if any of the interfaces on worker1 is
>> receiving any traffic -> No.
>> Then I checked if any traffic is going out of eth0, eth1 or eth2 on
>> frontend -> No.
>> Checked if eth4 is receiving the packets I sent through tcpreplay ->
>> How can I go about debugging this?
>> On 10-12-07 12:34 PM, Tyler T. Schoenke wrote:
>>>> Even if this does forward the packet to the eth1 interface (sending
>>>> of eth1 I assume), we haven't done the part where the packet goes from
>>>> the interface to the right worker machine (which is done by rewriting
>>>> the MAC address on the packet I suppose).
>>> I had written a config to do that, but never tested it. Here are the
>>> AddressInfo(mymac 10.0.0.1/8 1:1:1:1:1:1);
>>> AddressInfo(worker1 10.0.0.2/8 2:2:2:2:2:2);
>>> AddressInfo(worker2 10.0.0.3/8 3:3:3:3:3:3);
>>> my_switch :: HashSwitch(26, 8);
>>> FromDevice(eth1, PROMISC true, BURST 8 ) -> my_switch;
>>> todevice1::ToDevice(eth2, ALLOW_NONEXISTENT true);
>>> todevice2::ToDevice(eth3, ALLOW_NONEXISTENT true);
>>> //example: my_switch -> EtherEncap(0x0800, 1:1:1:1:1:1,
>>> 2:2:2:2:2:2) -> Queue -> ToDevice(eth2, ALLOW_NONEXISTENT true);
>>> my_switch -> EtherEncap(0x0800, mymac, worker1) -> Queue ->
>>> my_switch -> EtherEncap(0x0800, mymac, worker2) -> Queue ->
>>> or if you just want to bypass the MAC rewrite to test that traffic is
>>> being load balanced:
>>> my_switch -> Queue -> todevice1;
>>> mymac would be the MAC of the interface receiving the traffic, worker1
>>> and worker2 need to be set to the MAC of the worker machines. I was
>>> hoping this would take in the traffic, load-balance, rewrite the MAC
>>> and send it out to several interfaces. I think this is where I was
>>> getting a kernel crash and didn't have time to upgrade the kernel. I
>>> think it was on CentOS 5.3, and I saw patch references to the kernel
>>> error I was getting.
More information about the Bro