Re: [LARTC] neighbor table overflow
Looking into it further an ip route shows: 64.0.0.0/8 via 64.202.224.1 dev eth0 proto zebra metric 20 equalize So the 64.0.0.0 announce is coming into this box through OSPF (zebra) The 169.254.0.0/16 is being automajically added through the sysconfig network scripts. I'm looking into why. In either case I still don't see why these entries would make the neighbor table overflow. Could it have been the previous fix to the hosts file? mc Alexandru Dragoi wrote: Marco C. Coelho wrote: the ip route with a grep for link returns: snip** too long 64.202.227.198 dev ppp436 proto kernel scope link src 10.20.1.1 64.202.227.196 dev ppp421 proto kernel scope link src 10.20.1.1 64.202.227.197 dev ppp211 proto kernel scope link src 10.20.0.1 64.202.227.194 dev ppp13 proto kernel scope link src 10.20.1.1 64.202.227.192 dev ppp404 proto kernel scope link src 10.20.1.1 64.202.227.254 dev ppp194 proto kernel scope link src 10.20.1.1 64.202.227.253 dev ppp130 proto kernel scope link src 10.20.1.1 64.202.227.252 dev ppp243 proto kernel scope link src 10.20.1.1 64.202.227.249 dev ppp195 proto kernel scope link src 10.20.1.1 64.202.227.248 dev ppp254 proto kernel scope link src 10.20.1.1 64.202.227.247 dev ppp235 proto kernel scope link src 10.20.1.1 64.202.227.242 dev ppp78 proto kernel scope link src 10.20.1.1 64.202.227.240 dev ppp328 proto kernel scope link src 10.20.1.1 64.202.227.237 dev ppp44 proto kernel scope link src 10.20.1.1 64.202.227.236 dev ppp122 proto kernel scope link src 10.20.1.1 64.202.227.234 dev ppp316 proto kernel scope link src 10.20.1.1 64.202.227.232 dev ppp132 proto kernel scope link src 10.20.1.1 64.202.227.231 dev ppp104 proto kernel scope link src 10.20.0.1 64.202.227.226 dev ppp179 proto kernel scope link src 10.20.0.1 64.202.224.0/24 dev eth0 proto kernel scope link src 64.202.224.8 192.168.1.0/24 dev eth3 proto kernel scope link src 192.168.1.8 169.254.0.0/16 dev eth3 scope link The one above must be deleted, many redhat-like distros attach 169.254.0.0/16. All the pppoe terminations (pppd) are shown, as well as the last three subnets. I'll have to see where the 169.254.0.0/16 is coming from? mc Alexandru Dragoi wrote: Marco C. Coelho wrote: This box is doing a lot. It terminates 1000 PPPoE connections, provides traffic shaping using TC/HTB, authenticates all users via Radius. It also runs OSPF routing for the internal network. Looking at a simple route output I see all the PPP connections coming through the box, and due to the OSPF I also see the rest of my network announcements. The only strange things are: 1. The last man working on this box had mistakenly edited the hosts file and added the machine name and complete domain name to the local host 127.0.0.1 name. It should only be pointed to the eth0 interface. I have changed this. 2. The route output is making an announcement 64.0.0.0argontech.net 255.0.0.0 UG20 00 eth0 This doesn't look dangerous for your problem, I was only talking about directly connected networks: # ip route |grep link My public IP space is a /20 within that space, not the whole Class A. I have not found which box is announcing this within my network yet. Jeff Welling wrote: On 10/23/07 06:56, Alexandru Dragoi wrote: What about checking your routing table? you may have link routes for massive subnets (like 85.0.0.0/8 or 140.20.0.0/16). Some programs prefer to use standard netmask of classes A and B. I'm betting that the OP has other things going on seeing has how s/he mentioned PPPoE, which to my knowledge is a layer 2 protocol, and thus not subject to typical routing scenarios. In essence the OP could have thousands of PPPoE connections terminating on one system with the ARP cache having to deal with where to send traffic to which MAC address. There is not a lot of room for routing in such a scenario. I agree with Peter's suggestion, arpd. I ran into the neighbor table overflow problem recently, at the hands of our ISP. I was in the process of recompiling the kernel and mucking with arpd (I couldn't get it to run/start properly) when the problem disappeared as quickly as it showed up. Lucky for me, this was some kind of ISP problem, I was able to determine that much through `tcpdump -i X -n arpd`. My 'two cents' is that you try arpd, I did a bit of looking when I came across that problem and it seemed to be the last ditch effort when changing the gc threshold had no effect. Wasn't able to confirm that it worked for sure though. Cheers. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list
Re: [LARTC] One machine, two net feeds, outbound route selection
On 10/25/07, Peter Rabbitson [EMAIL PROTECTED] wrote: I can't bind Sendmail's outgoing SMTP client mailer to a specific interface, because it has to be able to forward mail on to inside systems, too. Of course you can. Remember that the kernel knows about both networks ... Hmmm. You're right, of course. And even better, it worked when I tried it. ;) Thanks! Now, for the sake of knowledge, let us say that a piece of needed software didn't have an option to bind to a specific interface. Would it be possible to control the outgoing route/interface anyway, by using iptables or some other mechanism external to the software? For example, what if Sendmail didn't have a ClientPortOptions directive (heh, I know, use Postfix, but work with me here)? And remember: This is for something running on the gateway, not forwarding packets received from another machine. :) (No, I don't presently have such a piece of software, but I'd like to know.) Thanks again, either way! -- Ben ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] neighbor table overflow
Marco C. Coelho wrote: Looking into it further an ip route shows: 64.0.0.0/8 via 64.202.224.1 dev eth0 proto zebra metric 20 equalize This /8 doesn't affect the neighbor table. There must be a problem on the site that announce it So the 64.0.0.0 announce is coming into this box through OSPF (zebra) The 169.254.0.0/16 is being automajically added through the sysconfig network scripts. I'm looking into why. In either case I still don't see why these entries would make the neighbor table overflow. Could it have been the previous fix to the hosts file? Well, when somebody try to make traffic with somebody from 169.254.0.0/16 throught you, your server will ask for arp on eth3, and most probably will record an incomplete entry in arp table. Virii and others can make this worse. Another quick fix is to drop arps from/to 169.254.0.0/16 with arptables. mc Alexandru Dragoi wrote: Marco C. Coelho wrote: the ip route with a grep for link returns: snip** too long 64.202.227.198 dev ppp436 proto kernel scope link src 10.20.1.1 64.202.227.196 dev ppp421 proto kernel scope link src 10.20.1.1 64.202.227.197 dev ppp211 proto kernel scope link src 10.20.0.1 64.202.227.194 dev ppp13 proto kernel scope link src 10.20.1.1 64.202.227.192 dev ppp404 proto kernel scope link src 10.20.1.1 64.202.227.254 dev ppp194 proto kernel scope link src 10.20.1.1 64.202.227.253 dev ppp130 proto kernel scope link src 10.20.1.1 64.202.227.252 dev ppp243 proto kernel scope link src 10.20.1.1 64.202.227.249 dev ppp195 proto kernel scope link src 10.20.1.1 64.202.227.248 dev ppp254 proto kernel scope link src 10.20.1.1 64.202.227.247 dev ppp235 proto kernel scope link src 10.20.1.1 64.202.227.242 dev ppp78 proto kernel scope link src 10.20.1.1 64.202.227.240 dev ppp328 proto kernel scope link src 10.20.1.1 64.202.227.237 dev ppp44 proto kernel scope link src 10.20.1.1 64.202.227.236 dev ppp122 proto kernel scope link src 10.20.1.1 64.202.227.234 dev ppp316 proto kernel scope link src 10.20.1.1 64.202.227.232 dev ppp132 proto kernel scope link src 10.20.1.1 64.202.227.231 dev ppp104 proto kernel scope link src 10.20.0.1 64.202.227.226 dev ppp179 proto kernel scope link src 10.20.0.1 64.202.224.0/24 dev eth0 proto kernel scope link src 64.202.224.8 192.168.1.0/24 dev eth3 proto kernel scope link src 192.168.1.8 169.254.0.0/16 dev eth3 scope link The one above must be deleted, many redhat-like distros attach 169.254.0.0/16. All the pppoe terminations (pppd) are shown, as well as the last three subnets. I'll have to see where the 169.254.0.0/16 is coming from? mc Alexandru Dragoi wrote: Marco C. Coelho wrote: This box is doing a lot. It terminates 1000 PPPoE connections, provides traffic shaping using TC/HTB, authenticates all users via Radius. It also runs OSPF routing for the internal network. Looking at a simple route output I see all the PPP connections coming through the box, and due to the OSPF I also see the rest of my network announcements. The only strange things are: 1. The last man working on this box had mistakenly edited the hosts file and added the machine name and complete domain name to the local host 127.0.0.1 name. It should only be pointed to the eth0 interface. I have changed this. 2. The route output is making an announcement 64.0.0.0argontech.net 255.0.0.0 UG20 00 eth0 This doesn't look dangerous for your problem, I was only talking about directly connected networks: # ip route |grep link My public IP space is a /20 within that space, not the whole Class A. I have not found which box is announcing this within my network yet. Jeff Welling wrote: On 10/23/07 06:56, Alexandru Dragoi wrote: What about checking your routing table? you may have link routes for massive subnets (like 85.0.0.0/8 or 140.20.0.0/16). Some programs prefer to use standard netmask of classes A and B. I'm betting that the OP has other things going on seeing has how s/he mentioned PPPoE, which to my knowledge is a layer 2 protocol, and thus not subject to typical routing scenarios. In essence the OP could have thousands of PPPoE connections terminating on one system with the ARP cache having to deal with where to send traffic to which MAC address. There is not a lot of room for routing in such a scenario. I agree with Peter's suggestion, arpd. I ran into the neighbor table overflow problem recently, at the hands of our ISP. I was in the process of recompiling the kernel and mucking with arpd (I couldn't get it to run/start properly) when the problem disappeared as quickly as it showed up. Lucky for me, this was some kind of ISP problem, I was able to determine that much through `tcpdump -i X -n
[LARTC] TC (HTB) doesn't work well when network is congested?
Hi, I have a server and ten clients in a Gigabit network. The server has 125mbps network bandwidth. I want that the server has 40Mbps bandwidth reserved for client 1 (IP 192.168.5.141), and the rest bandwidth is for all other clients. My script looks like this (I use IFB for incoming traffic): #!/bin/bash export TC=/sbin/tc $TC qdisc add dev ifb0 root handle 1: htb default 30 r2q 100 $TC class add dev ifb0 parent 1:0 classid 1:1 htb rate 125mbps mtu 9000 $TC class add dev ifb0 parent 1:1 classid 1:10 htb rate 40mbps ceil 125mbps mtu 9000 prio 0 $TC class add dev ifb0 parent 1:1 classid 1:30 htb rate 85mbps ceil 125mbps mtu 9000 prio 1 $TC filter add dev ifb0 parent 1: protocol ip prio 1 u32 match ip src 192.168.5.141/32 flowid 1:10 $TC qdisc add dev eth2 ingress $TC filter add dev eth2 parent : protocol ip prio 1 u32 \ match u32 0 0 flowid 1:1 \ action mirred egress redirect dev ifb0 $TC qdisc add dev eth2 root handle 1: htb default 30 r2q 100 $TC class add dev eth2 parent 1: classid 1:1 htb rate 125mbps mtu 9000 $TC class add dev eth2 parent 1:1 classid 1:10 htb rate 40mbps ceil 125mbps mtu 9000 prio 0 $TC class add dev eth2 parent 1:1 classid 1:30 htb rate 85mbps ceil 125mbps mtu 9000 prio 1 $TC filter add dev eth2 parent 1: protocol ip prio 1 u32 match ip dst 192.168.5.141/32 classid 1:10 I ran a test in which all 10 clients send/receive packets to/from the server simultaneously. But Client 1 only got 20mbps bandwidth for sending, and 38mpbs for receiving. If I limit the rate of both classes 1:1 to 60mbps instead of 125mbps, Client 1 got 39mbps for sending, and 40mbps for receiving. I am not sure what might cause this. Is it because TC doesn't work well when network is congested? Or my script is not right? Thanks a lot, william ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] One machine, two net feeds, outbound route selection
Ben Scott wrote: Now, for the sake of knowledge, let us say that a piece of needed software didn't have an option to bind to a specific interface. Would it be possible to control the outgoing route/interface anyway, by using iptables or some other mechanism external to the software? For example, what if Sendmail didn't have a ClientPortOptions directive (heh, I know, use Postfix, but work with me here)? Unfortunately not easy without doing local NAT (from the local interface to another local interface). The problem lies in how the kernel sends packets without a specified source. I wrote an explanation some time ago: http://mailman.ds9a.nl/pipermail/lartc/2007q2/020941.html ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] TC (HTB) doesn't work well when network is congested?
William Xu wrote: Hi, I have a server and ten clients in a Gigabit network. The server has 125mbps network bandwidth. I want that the server has 40Mbps bandwidth reserved for client 1 (IP 192.168.5.141), and the rest bandwidth is for all other clients. snip I ran a test in which all 10 clients send/receive packets to/from the server simultaneously. But Client 1 only got 20mbps bandwidth for sending, and 38mpbs for receiving. If I limit the rate of both classes 1:1 to 60mbps instead of 125mbps, Client 1 got 39mbps for sending, and 40mbps for receiving. I am not sure what might cause this. Is it because TC doesn't work well when network is congested? Or my script is not right? No network will be able to operate at its theoretical maximum. In the case of a gigabit network you will be lucky to get consistent 120mbps, and it heavily depends on the hardware quality, and the number of switches in between. So what you are doing is oversaturating the link, the ACK packets can not get through, your speed drops due to delays/retransmissions. Perform a test with only two systems sending stuff to each other to see what is the actual bandwidth you can hope for, and use that number instead of 125mbps. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] network question
Hi all I have following network question and want you to help 1/ I got the RX FCSErrors 6 from switch. (router ---link--switchhost). how can I determine it is host issue or router issue? 2/ when I use my linux as router with iptables, do i need to set 0=net.ipv4.tcp_timestamps What parameters in kernel i need to set in linux router to have good performance in router? 3/ what is the best way to capture data for audit later as I sometimes get bandwidth drop in mrtg graph? now I only capture load from top, netstat -i every minutes in cronjob. Thank you for your help - Ask a question on any topic and get answers from real people. Go to Yahoo! Answers. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] One machine, two net feeds, outbound route selection
On 10/25/07, Peter Rabbitson [EMAIL PROTECTED] wrote: Unfortunately not easy without doing local NAT (from the local interface to another local interface). I thought that might be the case. I even started to write a rule about how the NAT might work... but then I ran into brain pain trying to figure out how, because I didn't know when the packets get what address/interface info assigned to them, and I didn't know how SNAT would interact with the routing tables. Normally, I do SNAT in the POSTROUTING chain, but by then the routing rules have already run, right? So the packet would still be bound for the wrong interface, even if the source address is translated. No? In other words, let's say $DEF_ADDR is the IP address of the interface that is going to be picked by the default routing table, but I really want the packets to go out the $ALT_ADDR interface. So I try this: iptables -t nat -A POSTROUTING -s $DEF_ADDR -p tcp --dport smtp -j SNAT --to $ALT_ADDR But the whole point of changing the source address/interface is to influence which routing rules match, and those have already been applied by the time the packet transverses the POSTROUTING chain, right? In any event, that didn't work. So then I thought, well, maybe I can do SNAT in the PREROUTING chain for this? But in that case, the kernel won't have assigned it an address yet, right? So there's nothing to SNAT. And I can't do -s 0/0 because that actually means match all packets, right? So then I thought, well, maybe I can mark the packet in the OUTPUT chain of the mangle table, and match that in the routing rules, and *also* match that in the POSTROUTING chain: iptables -t mangle -A OUTPUT -s $DEF_ADDR -p tcp --dport smtp -j MARK --set-mark 42 ip rule add fwmark 42 table 42 iptables -t nat -A POSTROUTING -m mark --mark 42 -j SNAT --to-source $ALT_ADDR I think I tried that and it didn't work either. It was getting late and my maintenance window was closing and my brain hurt. If this is just one of those you can't do that situations, I'm willing to accept that answer. But if there is a way, I'd like to know what it is. :) -- Ben ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ADSL channel boding or Load balancing
+---+ +-+ ++ | ...245.18 +-+ ...77.1 | +---+ | ...0.x +-+ ...0.1| |COLO +-+ 101.x | ++ | ...245.19 +-+ ...78.1 | +---+ +---+ +-+ (Slight clean up.) Where are you doing your NATing to the world? Are you NATing on your PPtP tunnels or on the COLO system? Currently I'm natting on 0.1 ( -o ppp+ -j MASQUERADE ) , This was setup by default as I did not want 0.x to be routed. I've however taken off the natting, and added a route for 0.20/32 dev ppp62 nexthop dev ppp32 ( the 2 vpn interfaces) at COLO and obviously same nexthop routes at 0.1 for 101.x testing from 0.20, I scp a tar file over to 101.20 , still goes via one line at time, the route cache which I disabled, just reroute it the whole time( about every 5 sec) via the diffrent uplink, but not to our result we want I use sysstat to check the speeds and tcpdump verified I its from 0.20 - 101.20 ssh If you are doing your NATing on the COLO system and you add two routes to your internal network via the two PPtP tunnels, you should be able to equal cost multipath route across both PPtP tunnels to achieve increased bandwidth. The key part is that both tunnels have to appear to the world as a single external IP. I understand now very clearly the key part. My problem must be the tunnel, im sure im messing up, the equal cost multipath routing , am I using the right utitily? , still iproute2 right, or is iptables gonna play big part here as well? S ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] TC (HTB) doesn't work well when network is congested?
Thanks, Peter, So what you means is that network congestion caused my problem. I test the bandwidth between client1 and server using iperf, SEND and RECV are both 122MB/s. I tried different values for the total bandwidth, and I got the following numbers: total bandwidth 120MB/sclient1 SEND :10MB/s RECV :39MB/s total bandwidth 110MB/sclient1 SEND :16MB/s RECV :40MB/s total bandwidth 100MB/sclient1 SEND :30MB/s RECV :38MB/s total bandwidth 90MB/sclient1 SEND :39MB/s RECV :40MB/s total bandwidth 80MB/sclient1 SEND :39MB/s RECV :40MB/s total bandwidth 70MB/sclient1 SEND :40MB/s RECV :40MB/s total bandwidth 60MB/sclient1 SEND :40MB/s RECV :40MB/s So TC works well as long as total bandwidth is below 90MB/s, which is about 70% of the wise speed. Is it possible that I can use the full bandwidth (122MB/s) in my script? william Peter Rabbitson wrote: William Xu wrote: Hi, I have a server and ten clients in a Gigabit network. The server has 125mbps network bandwidth. I want that the server has 40Mbps bandwidth reserved for client 1 (IP 192.168.5.141), and the rest bandwidth is for all other clients. snip I ran a test in which all 10 clients send/receive packets to/from the server simultaneously. But Client 1 only got 20mbps bandwidth for sending, and 38mpbs for receiving. If I limit the rate of both classes 1:1 to 60mbps instead of 125mbps, Client 1 got 39mbps for sending, and 40mbps for receiving. I am not sure what might cause this. Is it because TC doesn't work well when network is congested? Or my script is not right? No network will be able to operate at its theoretical maximum. In the case of a gigabit network you will be lucky to get consistent 120mbps, and it heavily depends on the hardware quality, and the number of switches in between. So what you are doing is oversaturating the link, the ACK packets can not get through, your speed drops due to delays/retransmissions. Perform a test with only two systems sending stuff to each other to see what is the actual bandwidth you can hope for, and use that number instead of 125mbps. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] unregister me from this site
-- Shashank Sharma, M.Tech (Microelectronics System Embedded Technology) Contact no. : 9899912081 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] TC (HTB) doesn't work well when network is congested?
William Xu wrote: So TC works well as long as total bandwidth is below 90MB/s, which is about 70% of the wise speed. Is it possible that I can use the full bandwidth (122MB/s) in my script? In order to troubleshoot further more info is needed: 1) execute your script with 120MB/s as limit 2) perform a test transfer for several minutes 3) post back the output of the following commands: ip link show tc qdisc show tc -s -d class show dev ifb0 tc -s -d class show dev eth2 Peter ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] One machine, two net feeds, outbound route selection
On Thu, Oct 25, 2007 at 02:00:14PM -0400, Ben Scott wrote: On 10/25/07, Peter Rabbitson [EMAIL PROTECTED] wrote: Unfortunately not easy without doing local NAT (from the local interface to another local interface). Can you use marking, mark the packet in the mangle table, us iptables to select the which packets and then use ip rules fw mark - routing table (sorry about the syntax) I thought that might be the case. I even started to write a rule about how the NAT might work... but then I ran into brain pain trying to figure out how, because I didn't know when the packets get what address/interface info assigned to them, and I didn't know how SNAT would interact with the routing tables. Normally, I do SNAT in the POSTROUTING chain, but by then the routing rules have already run, right? So the packet would still be bound for the wrong interface, even if the source address is translated. No? In other words, let's say $DEF_ADDR is the IP address of the interface that is going to be picked by the default routing table, but I really want the packets to go out the $ALT_ADDR interface. So I try this: iptables -t nat -A POSTROUTING -s $DEF_ADDR -p tcp --dport smtp -j SNAT --to $ALT_ADDR But the whole point of changing the source address/interface is to influence which routing rules match, and those have already been applied by the time the packet transverses the POSTROUTING chain, right? In any event, that didn't work. So then I thought, well, maybe I can do SNAT in the PREROUTING chain for this? But in that case, the kernel won't have assigned it an address yet, right? So there's nothing to SNAT. And I can't do -s 0/0 because that actually means match all packets, right? So then I thought, well, maybe I can mark the packet in the OUTPUT chain of the mangle table, and match that in the routing rules, and *also* match that in the POSTROUTING chain: iptables -t mangle -A OUTPUT -s $DEF_ADDR -p tcp --dport smtp -j MARK --set-mark 42 ip rule add fwmark 42 table 42 iptables -t nat -A POSTROUTING -m mark --mark 42 -j SNAT --to-source $ALT_ADDR I think I tried that and it didn't work either. It was getting late and my maintenance window was closing and my brain hurt. If this is just one of those you can't do that situations, I'm willing to accept that answer. But if there is a way, I'd like to know what it is. :) -- Ben ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc signature.asc Description: Digital signature ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] One machine, two net feeds, outbound route selection
Ben Scott wrote: On 10/25/07, Peter Rabbitson [EMAIL PROTECTED] wrote: Unfortunately not easy without doing local NAT (from the local interface to another local interface). I thought that might be the case. I even started to write a rule about how the NAT might work... but then I ran into brain pain trying to figure out how, because I didn't know when the packets get what address/interface info assigned to them, and I didn't know how SNAT would interact with the routing tables. Normally, I do SNAT in the POSTROUTING chain, but by then the routing rules have already run, right? So the packet would still be bound for the wrong interface, even if the source address is translated. No? I was not thorough enough. The NAT is necessary in order to make the packet come back through the link/interface you want (because as I noted previously you do not have control over the choice of a source address). Once this is out of the way the only problem is how to make an already routed packet to leave via a different interface. One way to do this is the ROUTE target: http://netfilter.org/documentation/HOWTO//netfilter-extensions-HOWTO-4.html#ss4.5 There might also be other ways to do this, but I never investigated, as this is a mostly theoretical exercise. Peter ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] ncsh: docs + news
... Not so long time ago there was a mail about distros. I made packages of ipp2p and l7-filter for ALT Linux Sisyphus repository -- so, now there is one more PC-oriented distro with both these tools. ... About ncsh: * new docs: http://www.radlinux.org/docs/static/en/ncsh_usecases.html (not proofreaded yet, I'll send it to Mohan with next mail) * new capability: l7-filter frontend An l7-filter usage example: ! configure network interfaces ethernet 0 ! address 10.0.0.1/24 ! egress htb ! class 1 rate 100Mbit ! class 2 match l7 edonkey match l7 ftp match l7 socks rate 16Kbit ! default 1 rate 100Mbit l7 support in connexion requires a trivial patch on l7-filter, which can be found in the download area along with connexion snapshots: http://www.radlinux.org/download/ ... Any comments/wishes -- welcome. -- Peter V. Saveliev ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ADSL channel boding or Load balancing
On 10/25/2007 1:06 PM, the sew wrote +---+ +-+ ++ | ...245.18 +-+ ...77.1 | +---+ | ...0.x +-+ ...0.1| |COLO +-+ 101.x | ++ | ...245.19 +-+ ...78.1 | +---+ +---+ +-+ Currently I'm natting on 0.1 ( -o ppp+ -j MASQUERADE ) , This was setup by default as I did not want 0.x to be routed. I've however taken off the natting, and added a route for 0.20/32 dev ppp62 nexthop dev ppp32 ( the 2 vpn interfaces) at COLO and obviously same nexthop routes at 0.1 for 101.x Ok, good. The NATing at 0.1 was part of the problem. testing from 0.20, I scp a tar file over to 101.20 , still goes via one line at time, the route cache which I disabled, just reroute it the whole time( about every 5 sec) via the diffrent uplink, but not to our result we want Hum. I would question the routes then. I use sysstat to check the speeds and tcpdump verified I its from 0.20 - 101.20 ssh Ok. I understand now very clearly the key part. My problem must be the tunnel, im sure im messing up, the equal cost multipath routing , am I using the right utitily? , still iproute2 right, or is iptables gonna play big part here as well? To the best of my knowledge you will still be using the ip command from iproute2. Will you please show us your routing table and / or the ip route command you are using to set up your ecmp route? Grant. . . . ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
