[LARTC] Routing NDAS ?
Hi, I believe ndas devices (http://www.ximeta.com/web/technology/) use raw Ethernet frames, as they require no tcp/ip configuration, the client finds and authenticates with a code that is different for each device sold, like a network mac address. My pc is on a different segment to the ndas devices that we have, the two segments are linked by a linux box that is doing routing and proxy arp, can anybody suggest a way that I could access the ndas devices, I can connect to a share on a server that is connected to one of the devices, but that isn't very efficient :( Andy */ Ignore: JOSEDV001TAG /* ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] equalize / ecmp not working as expected in 2.6 vs 2.4
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 11 April 2007 09:01 To: lartc@mailman.ds9a.nl Subject: Re: [LARTC] equalize / ecmp not working as expected in 2.6 vs 2.4 Andy Furniss [EMAIL PROTECTED] wrote on 10/04/2007 21:29:33: [EMAIL PROTECTED] wrote: thanks for the info. First of all, in order to use the nth match you need to patch your kernel using patch-o-matic. I think nth is in kernel now as part of the statistic match. Andy. I was searching this yesterday afternoon and could not verify it. Today I found it in the 2.6.18 kernel's changelog: [NETFILTER]: x_tables: add statistic match Add statistic match which is a combination of the nth and random matches. Signed-off-by: Patrick McHardy ... Signed-off-by: David S. Miller ... commit 62b7743483b402f8fb73545d5d487ca714e82766 Author: Patrick McHardy ... Date: Mon May 29 18:20:32 2006 -0700 ¿ Does this match help you to solve the problem ? Regards, Eric-- ADVERTENCIA LEGAL El contenido de este correo es confidencial y dirigido unicamente a su destinatario. Para acceder a su clausula de privacidad consulte http://www.barceloviajes.com/privacy LEGAL ADVISORY This message is confidential and intended only for the person or entity to which it is addressed. In order to read its privacy policy consult it at http://www.barceloviajes.com/privacy Your suggestion pointed me in the right direction, it is now working with the following setup: Kernel 2.6.20-gentoo-r4 x86_64 Iptables 1.3.7 Iptables rules: iptables -t mangle -A OUTPUT -s localip2 -m statistic --mode nth --every 2 --packet 0 -j MARK --set-mark 111 iptables -t mangle -A OUTPUT -s localip2 -m statistic --mode nth --every 2 --packet 1 -j MARK --set-mark 222 localip2 is one of the ip addresses from the /28 range that is routed to both of our lines, in your example you said to add to PREROUTING, but the packets are from the box itself so I changed to OUTPUT, so far that has not caused any problems... any comments on that? We only want to do per-packet load balanced for some local and some routed ips, not all of them, some services cannot cope with the out of order packets that arise from sending outgoing traffic through two different links. IP Rules: ip rule add prio 111 fwmark 111 table ADSLLink1 ip rule add prio 222 fwmark 222 table ADSLLink2 Both ADSLLink1 and ADSLLink2 already existed and contain a default route via the router for line 1 or line 2, they also have routes for other subnets so that for example I can ping our routers from my workstation which has a private IP address, I wont show all the routes as the box has some 10 eth interfaces and it is very long and confusing, but the important bit is: ip route show table ADSLLink1 | grep default default via router1 dev inet0 ip route show table ADSLLink2 | grep default default via router2 dev inet0 This is currently working in combination with the ecmp routes that were already in place, and that is working very well for us, services that suffer when there are lots of OOOP's still get per-flow/cached route load balanced over the two lines, and services that can handle a few OOOP's are getting the full benefit of 2 x upload speed. Iptables also gives me much more fine grained control of the setup, when I have more time I will be making more improvements. A final note, I got very confused for a while last night because whenever I used iptables with -t mangle I got a error like this: iptables --list -t mangle Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination FATAL: Module ip_tables not found. snip It turns out that this is a issue with having ip_tables compiled into the kernel, /sbin/iptables tries to modprobe it regardless of that and then fails because it is not a module, I believe a fix was posted to netfilter mailing list, I got rid of the error by making a dummy kernel module with the name ip_tables, not a nice solution but it does suppress the error. Many thanks for your help Andy JOSEDV001TAG ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] equalize / ecmp not working as expected in 2.6 vs 2.4
Hi, With kernel 2.4 I was able to use equalize to send our outgoing packets to two different routers (our isp supports this setup), like this: ip route add default src ip.a.dd.rr equalize nexthop via router1 weight 1 nexthop via router2 weight 1 The two routes were used equally on a per packet basis, not per flow or per cached route, but per packet, each line has 800k upload and with that route we could upload to a single remote host at 1.6mbit. We replaced the server with a newer one and changed to 2.6 (2.6.20) kernel, I found that equalize no longer works as expected, it does choose a router at random but once a single packet has been sent to a remote host the same route/router is used for all packets going to that remote host. Once the cached route expires a random route is chosen again, but that is not what we want. I had made no changes to the ip route commands, but then I realised that kernel 2.6.20 has options for multipath (IP: equal cost multipath with caching support), I enabled that and now our kernel options are: CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_MULTIPATH_CACHED=y CONFIG_IP_ROUTE_MULTIPATH_RR=m CONFIG_IP_ROUTE_MULTIPATH_RANDOM=m CONFIG_IP_ROUTE_MULTIPATH_WRANDOM=m CONFIG_IP_ROUTE_MULTIPATH_DRR=m But even with these options, and default route set as follows: ip route add default src ip.a.dd.rr mpath rr nexthop via router1 weight 1 nexthop via router2 weight 1 The result is the same, a single upload to a remote host only uses 800k bandwidth on one of the lines, it does not send packets to both lines, although two uploads to two different hosts will usually make use of both lines. It seems to me that the multipath with caching support is broken in 2.6.20? The exact kernel we use is 2.6.20.4, with that kernel how would you specify a remote route such that packets going to a remote host are sent 50/50 ratio to two different routers? Thanks Andy JOSEDV001TAG ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] equalize / ecmp not working as expected in 2.6 vs 2.4
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 10 April 2007 15:17 To: lartc@mailman.ds9a.nl Subject: Re: [LARTC] equalize / ecmp not working as expected in 2.6 vs 2.4 Hi Andrew, I would use a combination with iptables. You should mark the packets, for example using average or n-th, and then use ip rules to send half of the packets vía one router and the rest to the other router according to the marks you set with iptables. Just a question ¿ dont you have problems with your source IP and the returning responses when you are sending packets from one connection over multiple routers ? ¿ do you have something like an AS ? Best regards, Eric Janz Andrew Lyon [EMAIL PROTECTED] Enviado por: [EMAIL PROTECTED] 10/04/2007 14:36 Para 'lartc@mailman.ds9a.nl' lartc@mailman.ds9a.nl cc Asunto [LARTC] equalize / ecmp not working as expected in 2.6 vs 2.4 Eric, Could you give me a example of how to do that? With nth if possible... It is not common for a ISP to support that sort of setup, but they do http://aaisp.net.uk/aa/aaisp/multiline.html Each line has two ips, one for the router and another for the interface on a linux box or other device, the isp routes a larger /28 down both lines, and allows packets with source address in the /28 range to be sent through both lines. On my linux server I have a routing table for each line with the necessary routes to make each router ip reachable, and a default route that equalizes over both router ips, it worked with 2.4 but with 2.6 it seems to be per-flow instead of per packet. I can login to a control page app on the ISP website and configure which lines a given block is routed down, and they also do really good traffic monitoring etc http://www.aaisp.net.uk/cqm.html PS. Please reply below original posting, not above! http://en.wikipedia.org/wiki/Top-posting Andy JOSEDV001TAG ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Routing / NAT for Multi Subnet Router
Hi, I have a linux system which is router between several subnets (each also a different segment), in total 3 different lans, 2 dmz, and 4 internet connections, my default FORWARD policy is DROP, here is a simplified example of my config with only two lan segments and internet connection: Allow forwarding between lans -A FORWARD -s lan1/mask -j ACCEPT -A FORWARD -d lan1/mask -j ACCEPT -A FORWARD -s lan2/mask -j ACCEPT -A FORWARD -d lan2/mask -j ACCEPT Are some of those redundant? Then I want to nat anything that is not to one of the local subnets (i.e. is going to internet), but the only way I can find to do that is to setup rules to avoid natting between subnets: -t nat -A POSTROUTING -s lan1/mask -d lan2/mask -j RETURN -t nat -A POSTROUTING -s lan2/mask -d lan1/mask -j RETURN And then a final rule to nat: -t nat -A POSTROUTING -s lan1/mask -j SNAT --to-source lan.one.nat.ip I used to have a rule like: -t nat -A POSTROUTING -s lan1/mask -o internet-eth -j MASQUERADE, and that worked because it only natted packets that were going to the internet, but now I am using Equal Cost MultiPath and when that doesn't work well with MASQUERADE, but it does work with SNAT, but with SNAT I cannot use a rule like that. Is there a better way to achieve what I desire? Thanks Andy JOSEDV001TAG ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] Unequal Multipath Routing?
Luciano Ruete wrote: On Wednesday 28 June 2006 12:01, Andrew Lyon wrote: That's probably an equalize bug, that does not take in account 'weight' for packet balance. Equalize is unmaintained software AFAIK. Perhaps not so much a bug as a lack of functionality.. Back to my original question then, is there anything in 2.6 or a patch for 2.4 that could be used to do that? (4:3 ratio split of outgoing packets over two interfaces/gateways). Why you need the balance in a packet basis? If you use a vanilla kernel and simple multipath, then the radio 4:3 should work ok. Simple.. we use apps that need more bandwidth than a single line can provide. Andy /*JOSEDV001TAG/* ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] Unequal Multipath Routing?
Torsten Luettgert wrote: On Mi, 2006-06-28 at 16:35 +0100, Andrew Lyon wrote: Back to my original question then, is there anything in 2.6 or a patch for 2.4 that could be used to do that? (4:3 ratio split of outgoing packets over two interfaces/gateways). If you aren't afraid of patching compiling kernels, there is one solution. It's a bit ugly, but works (we sell bundled DSL lines using this method). bundled dsl is exactly what this is. The basic idea is to use the iptables ROUTE target to make exemptions from the default gw. It works like this: First make a kernel with the netfilter random and ROUTE targets (can be obtained from patch-o-matic-ng, but they are removed from the current HEAD - you'd have to check out an older revision, or I could send you my copies which work with 2.6.16 and 2.6.17). I will get our box upgraded to a 2.6 kernel and give it a try, there is one feature in 2.4 that we need at the moment but I think I found a 2.6 solution for that a few days ago. Then, point the default route to the bigger pipe, and add an iptables rule like this: iptables -t mangle -A POSTROUTING -o (interface of default route) \ -m random --average 43 \ -j ROUTE --gw (ip of other gateway) Makes sense. I only tried this with different interfaces for different upstreams, but thinking about it, it should also work if they are on the same interface. 43% is about 3/7, so about 3/7 of your packets would use the slower line. Next thing to worry about would be the downstream :) Our isp does the downstream already (its 50/50 but our lines are same speed download), we have a /30 on each line (one ip for router, one for gateway linux box), and a /28 which is routed down both lines, and ipv6 too, our isp is very innovative, they built their own l2pp router which does all this and more AA www.aaisp.net.uk Some remarks: - If you can make the downstream work the same way, you have true packet-based bundling, so single connections will also experience the full bandwidth. Depending on how the downstream is configured, different things can happen (only one line used, downstream bundled per-connection, downstream is 50/50 instead 43/57). - if the lines have different latencies, packets can arrive in different order, so e.g. VoIP won't be pleasure - connecting to the modems from your box will need some more rules (packets would also be sent to the modem you're not talking to) - I'm not 100% sure the random match options are right, I used the nth match for lines of equal sizes (so it's round-robin), not random. One could also use a cascade of nth matches to make it round-robin 4:3 (abababa abababa ...) I've already run into the out of order packets problem, pptpd supports this but it seems to be a little buggy at reassembling packets, basically it doesn't work so I had to move our vpn onto the /30 ips which are not bonded, I used round robin dns to load balance our vpn clients across both lines, crude but better than nothing! Thanks for your help Andy /*JOSEDV001TAG/* ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] Unequal Multipath Routing?
Luciano Ruete wrote: On Wednesday 28 June 2006 05:19, Andrew Lyon wrote: Peter Surda wrote: On Tuesday 27 June 2006 15:16, Luciano Ruete wrote: how about: ip route add default nexthop via a.a.a.a weight 4 nexthop via b.b.b.b weight 3 exactly. Not tested but i think it can work. tested, works. Luciano Yours sincerely, Peter It works in so far as the command is accepted and there is no error, but having changed the default route and then doing a upload by ftp I can see that both lines are still getting 1/2 of the outgoing packets. One upload means nothing, plain multipath(vanilla kernel, with multipath cached not set) take in account destination address(DA for convenience) and TOS. For each new pair of DA and TOS it takes the nexthop available. So doing an ftp to a single host will make no difference. Think in connections instead of packets, for a 'per packet multipath' you need to have same source address for all your choosed gw/isps and to patch your kernel. It am not using plain multipath, its equalized multipath using the patch eql-patch-2.4.30.gz. My upload was using both lines, our ISP graphs include bandwidth and I can see the upload was approx 550kbit on each line, but the capacity is 600kbit and 800kbit. I am fairly sure about this because both lines are adsl, when the upstream is saturated the latency goes up and this is reflected in graphs that our isp make available, the line with 600kbit upload has noticeably higher latency, the line with 800kbit does not. The latency problem is easy to solve, making your linux box to be the one who manage the queue, see section 9.2.2.2 of LARTC HowTo. I am not trying to solve the latency, I was only using it as a rough guide of whether the data was being sent in the ratio I expected to the two lines. Have you verified that it does actually distribute the packets in a different ratio? I think multipath is just random. As i say, each time a new pair of DA and TOS arrives it takes the nexthop, in the case mentioned above, it will choose 4 times the hop a.a.a.a and 3 times the hop b.b.b.b and so on. Yes, unless you are using equalize patch. It is possibly that you start a heavy http download and goes by a, and then a ping and goes by b, and then a new heavy http download and it goes by a again. So one line is saturated while the other is empty, thats why multipath works better(fairly) as the number of clients arise. JOSEDV001TAG ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Unequal Multipath Routing?
Hi, I am currently using a 2.4 kernel with multipath routing patch v5 to send outgoing packets in a 1:1 ratio over two lines, however the lines do not actually have equal upstream bandwidth, one has 800kbit and the other 600kbit, so ideally I would like to send packets in a 4:3 ratio, is there anything in 2.6 or a patch for 2.4 that could be used to do that? I tried this ugly hack but it didn't seem to work: ip route add default src my.ip.add.res equalize nexthop via a.a.a.a weight 1 nexthop via b.b.b.b weight 1 nexthop via a.a.a.a weight 1 exthop via b.b.b.b weight 1 nexthop via a.a.a.a weight 1 nexthop via b.b.b.b weight 1 nexthop via a.a.a.a weight 1 ? Andy */ String to disable horrible email disclaimer:JOSEDV001TAG /* ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] Linux router performance
xOn an AMD Athlon64 3200+ (2 GHz) I was able to saturate 2 PCI-Express gigabit cards (but that was with 1500 byte packets). Never tried more although the box has 6 interfaces capable of gigabit, 4 of them attached via PCI-Express. What NIC's are you using? Are they multiport or do you have several pci-express single port cards? Andy Registered Office: J.O. Sims Ltd, Pudding Lane, Pinchbeck, Spalding, Lincs. PE11 3TJ Company reg No: 2084187 Vat reg No: GB 437 4621 47 Tel: +44 (0) 1775 842100 Fax: +44 (0) 1775 842101 Web: www.josims.com Email:[EMAIL PROTECTED] The information contained in this e-mail is confidential and is intended for the addressee only. The contents of this e-mail must not be disclosed or copied without the sender's consent. If you are not the intended recipient of the message, please notify the sender immediately, and delete the message. The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the company. No commitment may be inferred from the contents unless explicitly stated. The company does not take any responsibility for the personal views of the author. This message has been scanned for viruses before sending, but the company does not accept any responsibility for infection and recommends that you scan any attachments.JOSEDV001TAG ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] Problems with Routing and Masquerading
AFAICR using MASQUERADE with multipath is not recommended (but maybe this is outdated, plz correct me if I'm wrong) I have had problems using MASQUERADE with multipath on a 2.4.31 kernel box, with two outbound default routes I got messages about rustys brain broke and things like ICMP etc suffered packet loss. Not recommended, SNAT works perfectly :) Andy Registered Office: J.O. Sims Ltd, Pudding Lane, Pinchbeck, Spalding, Lincs. PE11 3TJ Company reg No: 2084187 Vat reg No: GB 437 4621 47 Tel: +44 (0) 1775 842100 Fax: +44 (0) 1775 842101 Web: www.josims.com Email:[EMAIL PROTECTED] The information contained in this e-mail is confidential and is intended for the addressee only. The contents of this e-mail must not be disclosed or copied without the sender's consent. If you are not the intended recipient of the message, please notify the sender immediately, and delete the message. The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the company. No commitment may be inferred from the contents unless explicitly stated. The company does not take any responsibility for the personal views of the author. This message has been scanned for viruses before sending, but the company does not accept any responsibility for infection and recommends that you scan any attachments.JOSEDV001TAG ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] Problems with Routing and Masquerading
My apologies for sending email disclaimer crap to the list, I forgot the magic string to prevent it from being appended :(. Oops. Andy JOSEDV001TAG -Original Message- From: Andrew Lyon [mailto:[EMAIL PROTECTED] Sent: 30 May 2006 17:13 To: 'lartc@mailman.ds9a.nl' Subject: RE: [LARTC] Problems with Routing and Masquerading AFAICR using MASQUERADE with multipath is not recommended (but maybe this is outdated, plz correct me if I'm wrong) I have had problems using MASQUERADE with multipath on a 2.4.31 kernel box, with two outbound default routes I got messages about rustys brain broke and things like ICMP etc suffered packet loss. Not recommended, SNAT works perfectly :) Andy Registered Office: J.O. Sims Ltd, Pudding Lane, Pinchbeck, Spalding, Lincs. PE11 3TJ Company reg No: 2084187 Vat reg No: GB 437 4621 47 Tel: +44 (0) 1775 842100 Fax: +44 (0) 1775 842101 Web: www.josims.com Email:[EMAIL PROTECTED] The information contained in this e-mail is confidential and is intended for the addressee only. The contents of this e-mail must not be disclosed or copied without the sender's consent. If you are not the intended recipient of the message, please notify the sender immediately, and delete the message. The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the company. No commitment may be inferred from the contents unless explicitly stated. The company does not take any responsibility for the personal views of the author. This message has been scanned for viruses before sending, but the company does not accept any responsibility for infection and recommends that you scan any attachments.JOSEDV001TAG ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
