Re: [LARTC] Routing problem (RTNETLINK answers: Invalid argument) on multiple internet link.
On Tue, 2007-02-13 at 22:54 +0100, Paul Viney wrote: I still seem to have much the same problem. I no longer get ICMP unreachable errors, but the packet just seems to disappear - I can't see it being forwarded on any interface, nor can I find any kind of reply - icmp or otherwise. This is one of my favourites :-) Usually that problem is caused by the rp_filter feature, which silently drops packets that arrive on an interface answers wouldn't be routed to. Just try for i in /proc/sys/net/ipv4/conf/eth*/rp_filter; do echo 0 $i done and see if that helps. (indeed, you don't really need to switch it off for all of them, just the uplink interfaces would be enough) Hth, Torsten ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] know if packets are marked
On Mi, 2007-01-24 at 07:29 -0300, Roberto Pereyra wrote: /usr/local/sbin/iptables -A PREROUTING -t mangle -m physdev --physdev-in eth1 -p tcp --dport 80 -j MARK --set-mark 2 How I can know if this packets are marked ? On the same machine (your bridge), you can match the mark later with iptables ... -m mark --mark value[/mask] ... and there is a classifier for tc, too, I think. The mark doesn't stay on the packets once they leave your bridge, though, so you can't match them on other boxes. Regards, Torsten ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Re: dst cache overflow
On Mi, 2007-01-10 at 14:20 +0100, ArcosCom Linux User wrote: The configuration is: 1) linux box with 2.6.19.1 kernel with these patches/modules: a) l7-filter b) multipath patch (from nano-howto) c) IMQ That's interesting - how did you get IMQ into 2.6.19.1? Afaik, the most recent patch is for 2.6.17, and there were some rejects if you try to patch it into 2.6.19. Regards, Torsten ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Fail-over uplink problem
Hi list, I have a problem I thought was simple first, but now I'm stuck. In a nutshell, it's about redundant uplinks at an outside location. Crude ASCII-Art follows: Internet || ++ | cisco with | | uplinks| ++ | | ATM interface +--+ ... | alvarion | | | wireless |+---+ | base || DSL | +--+| modem | ||| +---+ ++ | | wireless | | | subscriber | / ++/ | / +-+ | small linux | | box | +-+ | target net The target net is connected via a 20 MBit wireless connection which should be the normal route, and a 2 MBit DSL connection as backup. Switching to the backup line should work automatically. There are link networks between the linux box and the DSL modem and between the linux box and the base (subscriber is acting as a bridge). We control all the equipment, including the cisco. So I thought I'd use quagga and build a small OSPF or RIP between the linux box and the cisco where the linux box announces the target net. The wireless route would have higher priority because of the higher line speed. But how do I set the default route on the box? I don't want to redistribute BGP into OSPF on the cisco, it knows 2x20,000 routes from two uplink peers and the linux box is really small (300 MHz Celeron with 128 MB RAM). Thanks in advance for any advice. - Torsten ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] iptables u32 kernel 2.6.17
On Wed, 2006-08-02 at 10:55 +0200, gerald HUET wrote: [ 5333.87] ip_tables: u32 match: invalid size 0 != 2028 iptables: Unknown error -1 I tried to do some modifications on ipt_u32.c following modifications which work for ipp2p (http://www.sieglitzhof.net/~doc/ipp2p/) without any succes. Hm, that should have worked - it's the same problem for all the little-maintained stuff in patch-o-matic. Does anyone have an explication why the problem occurs whith the new kernel and how to solve it ? The parameters to checkentry() and match() changed incompatibly between 2.6.16 and 2.6.17. The u32 match in current SVN works with 2.6.17 (but not with 2.6.16 or earlier). You need to svn co http://svn.netfilter.org/netfilter/trunk/patch-o-matic-ng then patch your kernel and recompile. Regards, Torsten ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] iptables u32 kernel 2.6.17
On Wed, 2006-08-02 at 23:30 +0200, Piotr Chytla wrote: apply also patch from attachment. 2.6.17 needs matchsize in ipt_match struct. Whoopsie. I missed that in the patch I sent to netfilter-devel a while ago. Thanks for doing it yourself. Regards, Torsten ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] routing ssh to secondary uplink
On Do, 2006-07-06 at 09:49 +0300, [EMAIL PROTECTED] wrote: Hello, I'm following this HOWTO http://linux-ip.net/html/adv-multi-internet.html to route outgoing SSH from a secondary ISP. I can see using tcpdump,jnettop,iftop that when one of the computers located in my internal network is trying to SSH to a box online using SSH, packets are routed via the secondary internet ethernet card. However, packets don't seem to know how to get back. I understand the two uplinks have different ethernet interfaces. Did you disable rp_filter? Perhaps echo 0 /proc/sys/net/ipv4/conf/(interface for ssh)/rp_filter would help. You can also use tcpdump on that interface to see if the return packets arrive at your box, and on the inner interface to see if they leave it. Regards, Torsten ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] Unequal Multipath Routing?
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). 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). 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) 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 :) 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 ...) Regards, Torsten ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Limit my bandwidth
On Fr, 2006-06-23 at 14:36 -0700, Alaios wrote: rtfm means? [Please] read the fine manuals. Ok, some people don't say fine. Regards, Torsten ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] iptables match u32
On Thu, 2006-06-22 at 09:21 +0200, gerald HUET wrote: hello, I try to use iptables rules to drop skype trafic. The iptables rule is : iptables -I FORWARD -p udp -m length --length 39 -m u32 --u32 '270x8f=7' --u32 '31=0x01020304' -j ACCEPT Interesting match... but doesn't skype work on TCP, too, if UDP doesn't work? I've been told it even runs over http proxy, when there's no direct internet connection available. the problem I encounter is that i can't have the match u32 for iptables. Could someone help me ? Yes, the u32 match is in the netfilter patch-o-matic repository. You can get the new iptables and patch-o-matic code using subversion, like this: svn co http://svn.netfilter.org/netfilter/trunk/iptables svn co http://svn.netfilter.org/netfilter/trunk/patch-o-matic-ng After that, you need to prepare kernel sources and use the 'runme' script in patch-o-matic-ng to patch iptables and your kernel sources. Hth, Torsten ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] TC using vlan interface
On Thu, 2006-06-22 at 11:28 -0300, Luciano wrote: Hi all, Is it possible to use TC (HTB) in vlan interfaces ? Where can I find more documentation ? Yes, that is possible. VLAN interfaces are really different from the physical interface they reside on, kernel-wise. For example, if you put a 1 MBit HTB on eth0, but no qdisc on VLAN device eth0.1, traffic through eth0.1 won't be throttled at all. I suspect the same goes for iptables rules (but didn't try that yet). For documentation, see the LARTC howto and the docs on the HTB home page. There are also some ready-made shaping scripts which can help you understanding how all this works. Regards, Torsten ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] TC using vlan interface
On Fri, 2006-06-23 at 01:17 +0300, Radu Oprisan wrote: Torsten Luettgert wrote: On Thu, 2006-06-22 at 11:28 -0300, Luciano wrote: Let me explain... Due to the fact that vlan id's add some 4 bytes to the header of the packet, tc filter does not work properly unless you feed it with an offset and a hex match. I use 801.q and TC with iptables and tc filter rules based on iptables mark with great success. I admit it is more complicated this way, but it works... iptables -A FORWARD -t mangle -d xxx.xxx.xxx.xxx -j MARK --set-mark 12 iptables -A FORWARD -t mangle -d xxx.xxx.xxx.xxx -j RETURN Oh, I see. Didn't ever think of those problems, because I never use tc filters. My setup would look like iptables -t mangle -A FORWARD -d x.y.z.t -j CLASSIFY --set-class 10:112 which removes a bit of the complexity. Regards, Torsten ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] TC on virtual NIC, and how to manage the incoming traffic
On Di, 2006-06-20 at 19:50 +0200, Stefano Mainardi wrote: I need to work with TC on a virtual interface. Is it possible ? I guess you mean the eth0:1 and alike that ifconfig generates. If so, no, it is not possible (at least directly), since those are just additional addresses bound to an existing interface. There are other virtual interfaces where it works (loopback, VLANs, tunnel interfaces etc.) You can see which ones work by using ip link ls. That being said, your problem can be solved, of course (this is linux, after all!) If you need to shape traffic differently based on IP addresses (or just about anything else), you can use iptables to mark the packets or classify them directly to tc classes. Look into the CLASSIFY and MARK targets for that. Hth, Torsten ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
