[SOLVED] modify routing behaviour (multi-NIC) for testing external switch

abdeb · 01-15-2015, 04:04 AM

I currently try to set up my debian box to test external switch capabilities.
For this reason I've added a 4-port NIC and configured the corresponding interfaces as 192.168.1.[1..4]. All these ports are connected to the external switch to be tested.

I've managed successfully to install the combination xinetd and vsftpd to have the ftp server listen to 192.168.1.1 only.
As client I utilised

Code:

> wget --bind-address=192.168.1.2 ftp://192.168.1.1/bigdata

With this setup I successfully could transfer the corresponding file, but without meeting my goal to push the data through the external switch.

The kernel routing obviously is intelligent enough to bypass the NIC.

Making use of virtual machines (virtualbox) won't improve the situation since I could not find a way to isolate a network interface for direct access by a dedicated vm.

Any suggestions what else I could/should give a try?

Thanks,

Alexander

business_kid · 01-15-2015, 05:13 AM

I would follow the research motto:

"If at first you don't succeed, give up!"

The box will use the shortest path. You need a second box. Light up a tablet, smartphone, ps2 or raspberry pi and transfer that way. Have you reason to suspect the switch??

abdeb · 01-15-2015, 06:03 AM

Hello business_kid,

sorry, but I'd like not to give up that fast ;-)

No, I don't suspect the switch, I just want to test/compare switch capabilities (throughput, response times and such) and therefore I'll increase the number of used switch ports once the "routing" problem is solved in the simple 2-ports-only case.

I could utilise a second hardware, yes, but then I'd need to buy a set of say raspberrys (see above), so why not try with what is there already?

Thanks,

Alexander

business_kid · 01-15-2015, 10:00 AM

I understand. I have that streak, too.

If the switch has intelligence, program the ips of the switch, so as to get

Code:

192.168.0.1------------------192.168.110.1
192.168.0.2------------------192.168.110.2

Then you can use point to point networks, and stick a route 1921.168.0.1<------->192.168.110.2, and vice versa. Then you could send to 192.168.110.2 via 192.168.0.1 and fetch via 192.168.0.2 but that gets messy in the extreme.

If the switch doesn't have that much intelligence, I believe you are snookered without a second box.

abdeb · 01-16-2015, 05:20 AM

Hello business_kid!

Quote:

I understand. I have that streak, too.

Sometimes laborious though...

Quote:

If the switch doesn't have that much intelligence, I believe you are snookered without a second box.

No, it's a dumb one.

I've just thought about setting up chroot environments, but I am not sure wether it is possible to fire up interfaces exclusively within a chroot environment: Routing is a kernel task and the kernel is the same for all chroot environments - at least that's my current understanding.

Do you have additional ideas where to look at?

Thanks,

Alexander

business_kid · 01-16-2015, 07:15 AM

get another piece of intelligence. Linux will take the shortest path via 127.0.0.1.

A raspberry pi is €25. If you can't get another box, even on loan, you don't need a switch!

wildwizard · 01-16-2015, 07:30 AM

One of the answers here might work.

http://serverfault.com/questions/127...rnal-interface

Talk about a hack to get it going though.

abdeb · 01-20-2015, 09:06 AM

Hello wildwizard,

thanks, that was quiet a good link!

I've tried the 2nd answer (pure NAT), this (2 port) solution works fine for me. Not such a hack IMHO, really doable and understandable.

I'll extend it to all 4 NIC ports and post my final implementation here.

Thanks,

Alexander

abdeb · 01-23-2015, 02:38 AM

Hello wildwizard,

I've been struggeling a bit when "scaling" from a simple point-to-point to the more complex n-to-n scenario that I had in mind.
In general each pairing needs it's own ruleset, but my fault was to introduce virtual interfaces with dedicated IPs for each pairing.

Finally I kicked out the virtual interfaces and simplified the rule sets.

Here is what I do now:

Code:

# give each NIC its own subnet
ifconfig eth<i> 10.50.<i>.1/24

# rewrite each pairing's source ip to the external "dummy" subnet (outgoing, after routing has been done)
# don't forget to swap <s> and <t> to make the return pairing visible
iptables -t nat -A POSTROUTING -s 10.50.<s>.1 -d 10.60.<s><t>.1 -j SNAT --to-source 10.60.<t><s>.1

# rewrite each pairing's destination (external "dummy" subnet) ip to the "real" NIC ip (incoming, before routing is beeing done)
# the <s> portion is no longer needed
iptables -t nat -A PREROUTING -d 10.60.<s><t>.1 -j DNAT --to-destination 10.50.<t>.1

# tell the kernel how to reach the external "dummy" subnet for each pairing
ip route add 10.60.<s><t>.1 dev eth<s>

# pre-populate arp table with the corresponding NIC's MAC adresses
arp -i eth<s> -s 10.60.<s><t>.1 <MAC of target>

By using placeholders in the above "code" the rule how to scale this becomes easier to see:
<i>, <s> (source) and <t> (target) are the interface numbers (eth1 -> "1") that are to be included. The numbers must be in the range of [1..9], otherwise the 3rd triple could explode ;-) (If required one could perhaps split the <s> and <t> portions into the 2nd and 3rd triple.)

Thanks again for the good link. Maybe someone will find my upscaled version helpful.

Best Regards,
Alexander