Re: Retain QoS values on a pass-through node

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Tue, Dec 01, 2015 at 07:10:25AM -0800, Martin A. Brown wrote:
> 
> Hello Danushka,
> 
> >I am trying to use a Linux box as a pass-through node using rinetd 
> >as a port forwarding mechanism. I see that TOS is always zero on 
> >the egress path so that my receiver does not receive the TOS values 
> >I set on the sender.
> 
> Do you need the TCP session to be terminated in userspace (and 
> re-initiated)?  That's what's happening with rinetd.  You are using 
> it as a TCP proxy.  The Linux box is acting as a (TCP) receiver on 
> one side, and initiating a brand new TCP connection outbound.  
> That's why the ToS value is changing.
> 
> Next question:  When you say 'pass-through' node, I am not certain 
> what you mean.  Do you want your Linux box to act like a router?
> If so, then, that's very easy:
> 
>   sysctl -w net.ipv4.ip_forward=1
> 
> Now, you have a router.  Send packets to the ultimate destination 
> from your sender node.  Make sure that you configure your routes 
> properly (maybe that's already done).
> 
> >Is there a way to solve this issue?. Maybe rinetd does not copy the
> >values properly?.
> 
> I do not know rinetd.  Perhaps somebody else does.
> 
> >Probably there is a better/smarter way to do port forwarding (getting
> >my Linux box to work just as a pass-through node). Please let me know
> >if there is any other way to do that.
> 
> How many values are you changing in the packet?  Just the 
> destination port?  Also the destination address?
> 
> I'm thinking that iptables NAT may provide you a solution.  Assuming 
> you are just messing with the destination address and port, you 
> should be able to use iptables DNAT.  I'd suggest reading these:
> 
>   http://linux-ip.net/html/nat-dnat.html
>   https://www.frozentux.net/iptables-tutorial/chunkyhtml/x4033.html

I am using the above ideas for TCP port forwarding, it is basically:

- Destination NAT in the PREROUTING chain for packets going through the
  box (ip forwarding needs to be enabled)
- Destination NAT in the OUTPUT chain for local testing of the port
  forwarding
- Masquerading to have symmetric traffic flow and easier firewalling for
  the systems the ports are forwarded to

I use this to forward console server sessions to a bunch of individual
console servers. Clients connect to the IP of the port forwarder. There a
numbering scheme is used to easily identify the machine to connect to, and
the TCP session is forwarded to the correct physical console server.

You can leave out any parts you do not need for you use case. ;-)

Anyway, for testing routing performance, I'd go with a setup using two
interfaces on the "router" which are in different subnets, and connect one
of those to the "receiver", the other to the "sender". IP connections from
sender to receiver need to use the router.

For testing network stuff on one machine, network namespaces come in handy.
You can experiment with the "ip netns" command set to create virtual
interfaces in different network namespaces that cannot communicate directly
with each other. You can then add a router in the global namespace to
connect them (or use VLANs and a bridge to get them to an externam router).
No need for full VMs. ;-)

HTH,
Erik
-- 
Thanks to the virtue of me personally not caring one whit about
virtualization, I can stand back and just watch the fireworks.
                        -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux