Re: [LARTC] route with two uplinks actually slower than one
On Mon, 17 Mar 2003, John covici wrote: > Hi. At the moment I have two high speed connections to the internet > -- one somewhat faster than the other. I was looking at the advanced > router howto and created the tables, etc as specified in section 4.2 > of that document and changed my default route to a multipath route > with weight 2 on the faster provider and weight 1 for the slower one. > Then I went and downloaded a test file, but to my surprise I was > getting a lower speed than with the default route to the faster > provider. Is there a better way to do this so it actually does me > some good? On your own, with 1 single test file, multipath routing not help. However, it will help in providing more throughput when a lot of traffic is flowing to and from different sites. Think of it as a multiprocessing problem: if you have only one linear process, there is nothing to multitask. If, however, you have a number of processes they can be dealt with in parallel on the different processing chains (uplinks, in this case), and the end result will be faster overall. Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] routing to two interfaces
On Wed, 20 Nov 2002, Paco Brufal wrote: > Sorry if this question is very common, but I searched the > maillist archive and didn't found an answer... Did you read the HOWTO? > I have a linux box with 3 interfaces, 2 of them have public IPs > (eth1 and eth2), and the third is a private IP (our LAN). I want to do the > following: if a packet is coming from eth1, it must be forwarded to eth0, > and when it comes back, it must be routed to eth1. In case of packet comes > from eth2, it must be forwarded to eth0, and the respose must be routed to > eth2. In other words, a packet must leave our network by the interface it > come. Okay, given the fact that you are using private IP space in your LAN this should be very doable using NAT and connection tracking. Read up on the `Using multiple uplinks' sections in the HOWTO. What I don't really understand though is that you seem to want to allow connections from *outside* to either eth1 or eth2, routing those through to the internal network, and then be able to route the stuff back. The only simple solution to that problem I can see is to use application level proxies on the firewall. Thereby you can suddenly let the application proxy handle the correct forwarding and keep the necessary state on the firewall. Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] detecting link failure
On Tue, 19 Nov 2002, nitin panjwani wrote: > Hi All, > > I am running some tests in which I have to bring down > my interface down as soon as I tear down the cable. > Cable tearing results only in the link failure(as link > light went off), but it doens't bring my interface > down. > > Is there a way to bring the interface down as soon as > my link fails, probably using 'ip link' or 'ip > monitor'. Does anyone know about it. Monitor using mii-tool. > If there is some hardware monitering tool that can > detect the link failure, probably I can use this to > write a small program which will bring down the > interface as soon as I link failure is detected Well, you *could* theoretically write a kernel module that would monitor link status and call back to userland... that would result in the quickest teardown of the link. Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Listing routing tables
On Wed, 13 Nov 2002, Christoph Simon wrote: > Is there a way to list all existing routing tables, even those which > are not referenced by a rule? ip route show table all; ip route show table cache Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: Re: [LARTC] multipath routing problem [Shorter version] - Helpstill needed :-)
On 25 Oct 2002, Vincent Jaussaud wrote: > However, I don't get why, in the same SSH session, TOS may differ from > one packet to another. Using tcpdump, it seems that TOS value change > right after the authentication has been successfully made. Shit... you figured that one out *quite* a bit faster than I did at the time... took me two weeks. What openssh does is first authenticate, then set the TOS value depending on whether you're doing interactive communications (ssh) or bulk transfer (scp). One could see this as a way of minimizing information leakage... Oh, and yes, it does what you deduced. I finally got that from reading the sources... Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: Re: [LARTC] multipath routing problem [Shorter version] - Helpstill needed :-)
On Fri, 25 Oct 2002, Julian Anastasov wrote: > Hello, > On 25 Oct 2002, Vincent Jaussaud wrote: > > But traffic is NAT-ed after multipath routing occurs ! > > Eg, the box which do multipath routing do not NAT traffic; traffic get > > NAT-ed when leaving the gateways: > > > > LAN --> FW w/ multipath-routing > >|| > > Gateway1 Gateway2 > >| (NAT) | (NAT) > >|| > > Remote Network > > > > Packets reach the Remote Network using one of the Gateway NAT-ed IP, so > > that when packets come back they should use the proper return path. Am I > > wrong ? > > Now I see, then the TOS is a big problem for you. May > be your problem will be solved if TOS is not a routing key but > it does not sound as a thing that is easy to fix in kernel. Actually, you can simply play whack-a-mole with the TOS value, using ipchains (or iptables), killing all TOS values present on the packets. Ofcourse, this is not very *nice*, but it'll work. Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] multipath routing problem [Shorter version] - Help stillneeded :-)
On 25 Oct 2002, Vincent Jaussaud wrote: > When only one gateway is used to reach remote networks, everything is > working just fine. (Whatever gateway we choose to use) > Whenever we attempt to activate multipath routing over both gateways, > then SSH don't work anymore. We can ping, traceroute, telnet, ... but > not SSH nor FTP (PASV). ssh tends to play with TOS fields (and rightly so). Routing is keyed to the *triple* (src, dst, tos), something that most people (including me) normally forget. However, in this particular case that may be the reason for your ssh's breaking. The reason for FTP breaking possibly has to do with packets for the control connection going out the one gateway and for the data going out the other... but this is speculation on my part. Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] 1000Base-SX Gbit card recommendations
On Tue, 22 Oct 2002, Phil Doroff wrote: > So, I figured since this list is the most likely to deal with people that > push a lot of packets through Linux, and possible some via fiber I'd like to > know if anyone has any recommendations on which NIC to buy to replace this > thing. I can heartily recommend the Netgear cards. We have one running, and the system happily pumps over 240mbit/s sustained for a few hours. Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] [iptables] LOG & DROP simultaneously ?
On Fri, 18 Oct 2002, raptor wrote: > is there a way to LOG & -j OTHER-TARGET packet with one rule, or i have > to use two ? With iptables you have to use two. Or, you can just create a LOGDROP chain that you then jump to, and have that chain contain the two rules. Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] Help: Multiple internet connections
On Fri, 27 Sep 2002, David H. Lynch Jr. wrote: [snip, trying to do multipath routing through a NAT box] > Trying to grok the interrelations between IPTABLES and routing has given > me a headache. I guess I am not as sharp as I used to be. I am also > having a hard time getting a complete handle on what "stateful" really > means. But I am gathering that this is a routing problem caused as a > side effect of DNATing a connection. If IPTABLES is "stateful" does that > mean that if I MARK a packet that the return packet is also marked ? No. It means that the firewall maintains internal state as to what packets it has seen. This allows it to determine that packets from a TCP connection are allowed, due to the fact that it has indeed been setup from this side. The problem you're seeing is that you let the packets travel out of your firewall again to the server behind it. As soon as the packets are on the wire, there is *no* way to do any tracking of the any more, as you can with fwmarks as long as they stay on the host. The problem is that you lose the information on what interface the packet has originally come in, due to DNAT. > Alternatively, if I set the servers behind the firewall up with > two IP's and DNATed to a different one depending on the incoming > interface shouldn't I be able to chose an outgoing routing table based > on the source IP of the return packet ? That is exactly the right solution to this problem, if you don't intend to do it at the application level. :) > Finally what is a flapping route ? This problem would make allot more > sense to me if it were consistent. Owh, the internet provider of the clients that you see `disappearing' from the server at times re-routes the traffic from time to time. It probably has redundant links to the internet, and using some of these links the problem does occur whereas using others it doesn't. However, due to reconfigurations, hardware failure, all kinds of reasons really, the routes may not be very stable and `flap' between the different links. That is what I meant. > Thank you. Just having a second opinion that I am on the right > track helps allot. Well, you are. :) Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Help: Multiple internet connections
On Wed, 25 Sep 2002, David H. Lynch Jr. wrote: > Mostly things work, and I have read the > http://lartc.org/howto/lartc.rpdb.multiple-links.html#AEN261 pages and > implemented them. *blink*, nice to hear that. :) > I appear to have full access to the extent that my iptables rules > allow to any services running on the router/firewall. Good. > I appear to have outgoing internet access NATed correctly and > running the way I want. Good. > However I have problems with the servers/services that are being > DNATed to behind the firewall. Not so good. [snip] > It is my guess that the inbound packet manages its way to my > server just fine, but on the return trip it decides to head back out the > cable modem as that is the best route back to the client, and since the > client sees a response coming from the wrong source it discards it, but > I could easily be wrong. No, you are most probably right. Unfortunately, there is no real solution to your problem, for as soon as the packet has ben DNATed to the service behind the firewall you lose all information as to which route the packet took to get to your firewall. This means that any return packet can only take the `obvious' short route directly to the remote machine, and not the less-obvious route the long way round but with the correct source address. > I believe I am only having problems with DNATed services behind > the firewall, and I believe it is only when the client is local to the > external interface opposite the one they are coming in on. But I could > easily be wrong. regardless the problem is most ly reproducible - though > it has been know to go away for days at a time on its own, and mostly > limited to a small subset of all clients. Sounds as if there's routes flapping for a subset of your clients. I can see only one real solution: have some sort of application-level proxies run on your firewall host to plug the connections through to the services behind it. One way to do so would be to use socks in listening mode. Another would be to use netcat... Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] Advance Routing Guidance
On Thu, 15 Aug 2002, Laurens van Alphen wrote: > Why don't you want to use NAT? NAT is not dirty. NAT is stable, fast, > secure and saves you from renumbering your network when you switch > providers. On the other hand, NAT breaks useful stuff such as IPSec. Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] "automatic" classes
On Wed, 10 Jul 2002, [iso-8859-1] John Bäckstrand wrote: [snip] > 2) I would _want_ to traffic shape based on mac, not > IP, but this doesnt seem possible. It isnt vital for me > though, ip will work. Actually, it is possible, using netfilter and fwmarks. Netfilter can actually match based on MAC address. Problem is that you can't have it without specifying shit yourself. You could conceivably write a script to take a list of MAC addresses to shape and generate the corresponding tc calls... and then seed that from your ARP table. That would be the closest to automatic you can get. Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] which NIC is which
On Tue, 9 Jul 2002, Michael T. Babcock wrote: > Arthur van Leeuwen wrote: > > >Unfortunately, in systems with identical cards that are configured using > >plug-and-play methods such as those used by PCI random is the best shot you > >have... > > > > > 'Deterministic' is more accurate. It seems to be random, on first boot. > But it will almost never change after that unless you make hardware > changes, in my experience. Not in mine. Every time the PCI bus settings (can't recall the name right now, have been playing with a fixed hardware platform for quite a while) get reset there will probably be a different assignation. Yeah, it'll probably be deterministic *somehow*, but you'll be hard pressed to come up with any rules. Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] which NIC is which
On Tue, 9 Jul 2002, John Telford wrote: > I'm building routers. It's difficult to tell in advance which NIC will > be assigned eth0 and which will assigned eth1 when using two NICs. Ping > testing usually clears up this simple problem. > > The identification problem gets worse when adding a third NIC, after > sorting out the first two NICs. Frequently the eth0 or eth1 assignments > for the first two NICs change. > > Of course adding a fourth and fifth NIC multiplies the identification > problem. Yes, some of my routers are supporting five network segments. > > My question is, what's the algorithm for assigning Ethernet > designations? I know it not placement order in the PCI bus, and I know > its not the NIC data-link address. > > So what is it? Almost random. However, there's some evidence to suggest: order of probing of device drivers order of I/O addresses Unfortunately, in systems with identical cards that are configured using plug-and-play methods such as those used by PCI random is the best shot you have... Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] "Bug" in howto 4.2.1 Split access and other advice
On Fri, 5 Jul 2002, Stef Coene wrote: > On Friday 05 July 2002 21:05, Arthur van Leeuwen wrote: > > On Fri, 5 Jul 2002, Stef Coene wrote: > > > On Friday 05 July 2002 20:47, Arthur van Leeuwen wrote: > > > > On Fri, 5 Jul 2002, Stef Coene wrote: > > > > > Hi, > > > > > > > > > > I was rereading the pages in the howto about multiple ISP's and I > > > > > also found some strange stuff in it. Maybe you can create a patch > > > > > for Bert to update the howto ? > > > > > > > > Could you be more precies? :) > > > > > > export CVSROOT=:pserver:[EMAIL PROTECTED]:/var/cvsroot > > > cvs login > > > CVS password: [enter 'cvs' (without 's)] > > > cvs co 2.4routing > > >password = cvs > > > vi 2.4routing/2.4routing.sgml > > > > > > :wq > > > > > > cvs diff -u > patch > > > uuencode patch patch | mail -s "HOWTO update" [EMAIL PROTECTED] > > On what stuff you found strange, I meant... not on the process of sending > > in a patch for the HOWTO... > quoted from my post above : > > > > > I was rereading the pages in the howto about multiple ISP's and I > quoted from the subject > Re: [LARTC] "Bug" in howto 4.2.1 Split access and other advice > So I was talking about chapter 4.2 : > http://www.lartc.org/HOWTO//cvs/2.4routing/html/lartc.rpdb.multiple-links.html Yeah, that was quite clear. But what did you find particularly strange, other than the style of writing (for which I'm *not* going to apologize :))? > > Doei, Arthur. (Jeez, nerds... :)) > A real nerd takes a plane to Canada to talk about traffic shaping :) No, a real nerd takes a plane to Canada to listen to others talk about traffic shaping. >:) > Yesterday a colleague had a problem. He had a redhat based firewall and > installed NT4 on it. After first reboot, lilo was still booting a linux > kernel even after fdisk'ing the disk. He couldn't remove the tux-virus :) Yes? The disk probably wasn't fully wiped by the NT install, nor was the bootblock cleared. The first will have happened if the kernel was nowhere near the low end of the disk, the second is one of the lesser known issues with Microsoft's fdisk: it will only reset the MBR if you use fdisk /mbr . Doei, Arthur. (Not surprised in the least) -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] "Bug" in howto 4.2.1 Split access and other advice
On Fri, 5 Jul 2002, Stef Coene wrote: > On Friday 05 July 2002 20:47, Arthur van Leeuwen wrote: > > On Fri, 5 Jul 2002, Stef Coene wrote: > > > Hi, > > > > > > I was rereading the pages in the howto about multiple ISP's and I also > > > found some strange stuff in it. Maybe you can create a patch for Bert to > > > update the howto ? > > > > Could you be more precies? :) > export CVSROOT=:pserver:[EMAIL PROTECTED]:/var/cvsroot > cvs login > CVS password: [enter 'cvs' (without 's)] > cvs co 2.4routing >password = cvs > vi 2.4routing/2.4routing.sgml > :wq > cvs diff -u > patch > uuencode patch patch | mail -s "HOWTO update" [EMAIL PROTECTED] On what stuff you found strange, I meant... not on the process of sending in a patch for the HOWTO... Doei, Arthur. (Jeez, nerds... :)) -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] "Bug" in howto 4.2.1 Split access and other advice
On Fri, 5 Jul 2002, Stef Coene wrote: > Hi, > > I was rereading the pages in the howto about multiple ISP's and I also found > some strange stuff in it. Maybe you can create a patch for Bert to update > the howto ? Could you be more precies? :) Doei, Arthur. (Yeah, the type is intentional :)) -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] "Bug" in howto 4.2.1 Split access and other advice
On Fri, 5 Jul 2002, Laurens van Alphen wrote: > What is still unclear to me is when the > http://www.linuxvirtualserver.org/~julian/#routes patches are needed. > What do they do exactly? They add actual dead gateway detection (so that failover in fact does fail over... ;)), alternative routes (so that if multiple routes are defined only the active ones will actually be used), static routes (so that routes don't get deleted by the kernel if the correspondign interface goes down... thus automatically reusing it when it comes back up), and MASQUERADING support for multiple gateways. Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] "Bug" in howto 4.2.1 Split access and other advice
On Fri, 5 Jul 2002, Ard van Breemen wrote: > Hi, > http://lartc.org/HOWTO//cvs/2.4routing/html/lartc.rpdb.multiple-links.html > I am not sure who wrote this part or what it was based upon, but > since I am working a lot longer now with ip rules, I think I want > to add some stuff: The stuff that is in the HOWTO was designed and tested back in 1999. Oh, and I am the author. :) > The example 4.2.1 refers to the picture above, and does a plain > ip rule add from table > The problem with the exampe is that if you connect from the > inside (local network) to your if1 ip or if2 ip, that in this > example the replies to the local-network are going out if1 or > if2... That is not what you want. True. That is indeed a bug. Never saw it in actual practice though: you *should*not* connect to the external IP addresses of your router from the internal network... for various security reasons and such. But you are right. [snip] Whoa, that was large. I'm not sure I entirely follow you though. The *point* of the extra routing tables is that they take precedence over the default routing tables... Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] [OT]: rtt measurement using tcp timestamps from a MITMposition
On Fri, 28 Jun 2002, Patrick McHardy wrote: > Arthur van Leeuwen wrote: > > > > >On Fri, 28 Jun 2002, Patrick McHardy wrote: > > > >>Hi Arthur, [snip, RTT estimation from router] > >>I hope i got you right, you mean i should calculate the difference > >>between my clock and the first timestamp of a session, then > >>send my own and on reply substract the clock-skew again ? > >> > > > >No, that is active intervention again. I meant to *remember* the value of > >your clock and the last seen RTTM field for a session, and then when > >the corresponding ack returns use that remembered value as opposed to the > >the value in the RTTM field for your round-trip time calculation. > > > >>>per TCP stream, and tracking of all active TCP streams running through your > >>>machine. However, the latter is probably necessary *anyway* if you are > >>>going to do rate control, as you're bound to want to store the windowsizes > >>>and stuff related to each TCP stream separately. > >>> > > > >>Yes connection tracking is necessary (and already working fine :) > >> > > > >Well, what you do then is (in pseudocode): > > > >if packet contains RTTM field: > >if packet is SYN: > >remember local time (RTTM value, TCP stream) > >send packet on > >else: > >lookup local time for (TCP stream, RTTM value) > >calculate round-trip with local time > >else: > >do whatever you like > > > >Thereby you merely use the value in the RTTM field as a key to a set of > >stored local clockvalues. Yes, this will break if the value in the RTTM does > >not monotonically increase, but... that increase *is* guaranteed by the RFC. > hmm i suppose with "if packet is SYN" you mean "if packet contains new > data", right ? Well, I mean `if packet contains new RTTM timestamp'. However, I didn't think this through all that well: you want to store the last seen RTTM field in each direction of a TCP stream. > the reason i came up with this is i want to avoid storing lots of > timestamps/myclock pairs, You'll have to store 2 per TCP stream, one for each direction. > the number i would need to store depends on how many packets fit in the > current window, No. You only need to store the one for each window. Thus, upon store, have a counter count acks, and remember the new RTTM field only when the counter drops below the number of packets that fit in the window. Although round-trip-time may vary per packet, the approximation is probably still good enough. > so for bigger windows i would have to remember lots of values. > Remebering only the first one wouldn't work because i had to rely on the > remote clock to increase excactly as fast as mine. Why? The remote clock doesn't do *anything* to the RTTM field. As I read the RFC a host has to copy the RTTM field back verbatim into the ACK to the packet that contained it... as such, you *only* rely on your own clock to measure roundtrip time. Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] [OT]: rtt measurement using tcp timestamps from a MITMposition
On Fri, 28 Jun 2002, Patrick McHardy wrote: > Hi everyone, > i know this is not the right place to discuss this, but i assume some > people here might have some good ideas which could help me. > Also, i don't really know where else to turn .. I'll see if I can help. [snip] > A TCP usually takes care of this (wraparound after min. 24.8 days), but > this will not be true anymore. if we choose our timestamp clock to > increase once every 1 ms the sign bit will wrap after 5.5 minutes. I'm > not sure what to do about this (this is why i'm writing), does anyone > here have good ideas? I would also be happy about a completly different > approach, somehing totaly passive would be nice .. :) The completely different approach would be to recognize all TCP streams running through the machine and keep clocks for them: store the most recent RTTM SYN time for a particular stream as well as the current time of the machine when that RTTM time was seen. This will give you a good enough approximation of the clock-skew between what you would put in the RTTM field yourself and what is in there already, allowing you to use the RTTM fields if they already exist. Note that this takes 64 bits, i.e. 8 bytes of storage per TCP stream, and tracking of all active TCP streams running through your machine. However, the latter is probably necessary *anyway* if you are going to do rate control, as you're bound to want to store the windowsizes and stuff related to each TCP stream separately. Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ip route src
On Wed, 29 May 2002, Ciprian Niculescu wrote: > in LARTC at 4.2.1 Split access > > we have: ip route add $net dev $if src $ip > > i didn't understand what does the "src", if someone can explaint to me. The 'src' specifies which source address to choose in case a packet matching that routing rule does not have a source address yet. This may not seem useful, until you realise that all outgoing packets generated on the local machine don't have a source address when routing... Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] gre tunnel question again
On Thu, 16 May 2002, Vikas B. Wadhwani wrote: > This question adds on to the GRE tunnel query that I > asked earlier. > > For the GRE tunnel to work, do I need to configure > tunnels in both directions. You need to configure the tunnel on both endpoints, as both endpoints have to cooperate to provide the tunnel. So, if you have machine A with IP address 172.16.8.1 and machine B with IP address 172.16.16.1 then you would for example use ip tunnel add abtun mode gre remote 172.16.16.1 local 172.16.8.1 ip addr add 192.168.0.1 peer 192.168.0.2 dev abtun ip link set abtun up on machine A and ip tunnel add abtun mode gre remote 172.16.8.1 local 172.16.16.1 ip addr add 192.168.0.2 peer 192.168.0.1 dev abtun ip link set abtun up on machine B to get the tunnel up and running. Then you should be able to ping the endpoints on the other side, if the GRE encapsulated packets are not being firewalled somewhere along the way. Note that routing is at another level in the protocol stack. Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Fwmark problem - policy routing does not work.
On Sat, 27 Apr 2002, Adrian Chung wrote: > On Sat, Apr 27, 2002 at 10:25:24AM +0200, Arthur van Leeuwen wrote: > > On Fri, 26 Apr 2002, Adrian Chung wrote: > > > > > When you add a route that sets a src like: > > > > > > ip route add table 192.168.1.0/24 src 192.168.1.11 dev eth0 > > > > > > The "src" doesn't specify the source IP to put in the packet (it's not > > > network address translation, like SNAT in iptables), it just specifies > > > which local source IP the routing mechanisms should use to determine > > > where to route the packet. > > > > Actually, it is more subtle than that. The 'src' *does* specify the source > > IP to put in the packet *if* the packet doesn't have a source IP yet. This > > only holds true for packets generated locally. > > Ah okay, that makes sense... But I think in both our cases the > packets were generated locally, so the 'src' flag should have set the > source IP. > > Is it possible for the application (telnet in my case) to explicitly > bind to a socket and set it's source IP? That could explain why the > rule has no effect since by the time the packet reaches the routing > system, it already has a source IP set. Yes, that is possible. Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Fwmark problem - policy routing does not work.
On Fri, 26 Apr 2002, Adrian Chung wrote: > When you add a route that sets a src like: > > ip route add table 192.168.1.0/24 src 192.168.1.11 dev eth0 > > The "src" doesn't specify the source IP to put in the packet (it's not > network address translation, like SNAT in iptables), it just specifies > which local source IP the routing mechanisms should use to determine > where to route the packet. Actually, it is more subtle than that. The 'src' *does* specify the source IP to put in the packet *if* the packet doesn't have a source IP yet. This only holds true for packets generated locally. > For example, I've got policy routing setup with FreeS/WAN on a gateway > with an internal and external interface, where I do: > > # ip rule add table 1 prio 100 > # ip route add table 1 dev ipsec0 src > > This forces the box to route all packets to the remote LAN via the > internal interface, rather than the external interface. > > However, the packets that show up at the other end don't contain a > source IP of from the table 1 route, rather they contain the > source IP of the client machine that sent them. > This led me to believe that the "src" option only adjusts the way the > routing machinery in the kernel decides where and how to route the > packet, but doesn't change/rewrite the source address in the packets > themselves. It does not. The ip rule does that. Routing does not mangle packets, unless the packet is locally generated and incomplete. Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Can Linux 2.4 support DiffServ under IPv6 ?
On Wed, 17 Apr 2002, Scottin wrote: > & If can HOW ? Yes. By writing your own tc32 matches. You can do QoS on any type of packet that is queued. Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Per-connection routing for multiple uplinks/providers ??
On Tue, 16 Apr 2002, Bob Gustafson wrote: > >On Mon, 15 Apr 2002, Bob Gustafson wrote: > > > >> What I would like to do is cleanly move packets out to the Internet over > >> two (maybe 3) separate interfaces, utilizing all of the bandwidth, and > >> avoiding snags. > > > >[snip, lots of nice interesting wishes] > > > >> Does such a beast exist? Is it possible to build with current > >> ip/tc/netfilter technology? I am running a near stock RH 7.2 at the > >> moment. Each ISP line is going through a separate (proprietary/black-box) > >> firewall/router and then into the RH7.2 box. > > > >QoS and routing are basically independent of each other. Orthogonal, > >mathematicians would say. Furthermore, there *is* in fact a patch floating > >around somewhere on the internet that flushes the route cache after every > >packet... that might help. I've never used it, as I don't trust it to keep > >TCP connections intact, but still, it might prove useful. > > > >You'll have to do some digging on your own though... > > I was afraid of that. But this list was the first place to dig, yes? Yes, nowadays it is. :) At least you know there's something out there. Oh, as I recall the patch is by some weird guy in Utrecht, The Netherlands. Can't seem to find it using Google at the moment though. The stuff on http://www-2.cs.cmu.edu/~jcl/programs/ipeql/ipeql.html does seem like something you might want to look at (even though it is *old*). > > > >Doei, Arthur. (Oh, and it is Arthur van Leeuwen. The surname is > > 'van Leeuwen'. Kinda like in 'Ludwig van Beethoven') > > Ahh, learn something every day. The van *isn't* just like a middle > name then. Nope. It would've been capitalized if it were. :) > (I was pretty careful about the spelling of Leeuwen though :-) Don't computers make life *easy*? :P > Thanks much for the feedback My pleasure. Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Per-connection routing for multiple uplinks/providers??
On Mon, 15 Apr 2002, Bob Gustafson wrote: > What I would like to do is cleanly move packets out to the Internet over > two (maybe 3) separate interfaces, utilizing all of the bandwidth, and > avoiding snags. [snip, lots of nice interesting wishes] > Does such a beast exist? Is it possible to build with current > ip/tc/netfilter technology? I am running a near stock RH 7.2 at the > moment. Each ISP line is going through a separate (proprietary/black-box) > firewall/router and then into the RH7.2 box. QoS and routing are basically independent of each other. Orthogonal, mathematicians would say. Furthermore, there *is* in fact a patch floating around somewhere on the internet that flushes the route cache after every packet... that might help. I've never used it, as I don't trust it to keep TCP connections intact, but still, it might prove useful. You'll have to do some digging on your own though... Doei, Arthur. (Oh, and it is Arthur van Leeuwen. The surname is 'van Leeuwen'. Kinda like in 'Ludwig van Beethoven') -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Routing with two providers
On Wed, 10 Apr 2002, Jason A. Pattie wrote: > Arthur van Leeuwen wrote: > > >On Wed, 10 Apr 2002, Martin Ferrari - Decidir IT wrote: > > > >Yes, Julian's patches do have an influence on multipath routing. They make > >it quite a bit nicer to use in the case of interfaces going down and coming > >back up again, which can and does happen. They also make multipath routing > >and masquerading play even nicer with each other, although I haven't seen > >problems on stock kernels with that. May very well be that the tests I've > >done have been on networks with highly active but not highly demanding i > >users, thereby making sure the route cache stays up to date enough... > >don't really know. > > > >Doei, Arthur. > > > The only problem that I have had with Julian's patches is interoperation > with FreeS/WAN. I am still not able to make that work, although I > haven't worked on it in awhile. The last I remember is that with the > patches applied, the moment FreeS/WAN starts, all network traffic goes > out the ipsec0 interface instead of continuing to be routed via eth0 (or > whichever interface). This happens without a tunnel brought up. And > for some reason, I was not able to assign a metric to the route using > either the 'route' command or 'ip route'. Sorry, can't help you there. Never played with that particular setup... Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] Routing with two providers
On Wed, 10 Apr 2002, Martin Ferrari - Decidir IT wrote: > > > The Alexey's patches has some influence on this? > > > > Err... good question. What do you mean with 'the Alexey's patches'? > > You need a kernel newer than (say) 2.2.16, and then it'll just work. > > The work was done by Alexey, yes, but it's been included in the > > kernel for quite some time already. > > Oops, I'd confused Alexey with Julian Anastasov.. I meant Julian' patches > (http://www.linuxvirtualserver.org/~julian) which apply to 2.2 and 2.4 > kernels... Yes, Julian's patches do have an influence on multipath routing. They make it quite a bit nicer to use in the case of interfaces going down and coming back up again, which can and does happen. They also make multipath routing and masquerading play even nicer with each other, although I haven't seen problems on stock kernels with that. May very well be that the tests I've done have been on networks with highly active but not highly demanding i users, thereby making sure the route cache stays up to date enough... don't really know. Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] Routing with two providers
On Wed, 10 Apr 2002, Martin Ferrari - Decidir IT wrote: > > > I have a question that perhaps some of you have already > > faced sometime. > > > > See http://mailman.ds9a.nl/pipermail/lartc/2002q2/003111.html > > > > As you may note, this was written 7 days ago. > > Sorry, I'd suscribed months ago, but I'd missed that one. No problem. It'll be included in the HOWTO within days from now. > Do you know if that way UDP will work okay? and NAT? Yes. Yes. Yes. Yes. > The Alexey's patches has some influence on this? Err... good question. What do you mean with 'the Alexey's patches'? You need a kernel newer than (say) 2.2.16, and then it'll just work. The work was done by Alexey, yes, but it's been included in the kernel for quite some time already. Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Load balancing between 2 DSL lines
On Wed, 10 Apr 2002, Michael Schwartzkopff wrote: > Hi, > > I have got the following problem: I want to connect my net to the internet > using 2 (or more) DSL lines (PPPoE, dynamic IP addresses). > > So my question: Is it possible to connect the intern net via my firewall to > the ISP using 2 DSL lines while my firewall is doing NAT? Is load balancing > possible? If yes: HOW? Yes. See the HOWTO in about 2 days. :) Alternatively, check the mailinglist archives. Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Routing with two providers
On Tue, 9 Apr 2002, Martin Ferrari - Decidir IT wrote: > I have a question that perhaps some of you have already faced sometime. See http://mailman.ds9a.nl/pipermail/lartc/2002q2/003111.html As you may note, this was written 7 days ago. Doei, Arthur. (Busy trying to check out the LARTC CVS tree and writing a patch to it that includes exactly this scenario... it's *very* much a FAQ) -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Policy Routing Help
On Mon, 1 Apr 2002 [EMAIL PROTECTED] wrote: > Hey guys, can anyone comment on this if it is possible? > > My setup: > > Linux BoxCable >_ E0_ >| |___|___| >| | >| |DSL >| | E1_ >| |___|___| >|___| > > > Hopefully everyone can interperet my diagram. Anyhow, I have an FTP > server running off the Linux Box. The DNS resolves to Eth0 which is the > NIC attached to the Cable modem provider and the default route is set to > the Cable next-hop. Eth1 is attached to My Network. What I would like to > happen is that all incoming FTP traffic to Eth0 will always return out > Eth0 through the Cable ISP. Any other traffic will take the DSL provider > via a default route to the DSL next-hop > > I can think of 2 ways to do this: > > 1) Mark FTP traffic and create a rule to set the next-hop to the Cable > default route > > 2) Configure policy routing such that if traffic is destined to Eth0 IP > address, the next-hop is set to the Cable provider. The latter is better. :) > Because there is a default route configured on the linux box to the Cable > ISP, all return traffic regardless of the interface it was received on > will always take the Cable ISP. I would prefer option #2. Can anyone > shed some light on the config necessary to do this? This is pretty quick > and dirty with policy routing on IOS, but I am struggling a little bit on > the linux config. Thanks all! Very well: One creates two additional routing tables, say E0 and E1. These are added in /etc/iproute2/rt_tables. Then you set up routing in these tables as follows: ip route add $CABLE_GW dev eth0 src $IP_ETH0 table E0 ip route add default via $CABLE_GW table E0 ip route add $DSL_GW dev eth1 src $IP_ETH1 table E1 ip route add default via $DSL_GW table E1 Next you set up the main routing table. It is usually a good idea to route things to the direct neighbour through the interface connected to that neighbour. Note the `src' arguments, they make sure the right outgoing IP address is chosen. ip route add $CABLE_GW dev eth0 src $IP_ETH0 ip route add $DSL_GW dev eth1 src $IP_ETH0 ip route add $CABLE_NET via $CABLE_GW ip route add $DSL_NET via $DSL_GW Then, your preference for default route: ip route add default via $DSL_GW Next, you set up the routing rules, making sure that you route out a given interface is you already have the corresponding source address: ip rule add from $IP_ETH0 table E0 ip rule add from $IP_ETH1 table E1 This set of commands makes sure all answers to traffic coming in on a particular interface get answered from that interface. I set something like this up back in 1999 for my then-current employer to deal with a 'secure' leased line and a cable-modem, with e-mail coming in over both lines... Doei, Arthur. (Who just now realises that ftpd's may actually still play havoc with this: set your server to passive-only, if you can.) -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
