Re: [LARTC] QoS book
I can recommend this one: http://www.policyrouting.org/PolicyRoutingBook/ Hello all, Can anyone recommend a good book which thoroughly explains QoS from a Linux perspective? Something with TC examples & the like. I've looked at the following: http://www.amazon.com/gp/product/1580533418/qid=1148368189/sr=1-2/ref=sr_1_2/102-2819973-6353768?s=books&v=glance&n=283155 Engineering Internet QoS. Thanks. ___ 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
Re: [LARTC] Linux router performance
Fermín Galán Márquez skrev: Hi, I wonder about the performance of a Linux box used as router (I guest I'm not the first :). Althought I know it mainly depends on the hardware, I'm trying to find some references on the topic or comparations with other routing solutions (FreeBSD box used as router, Cisco, etc). For example, http://facweb.cti.depaul.edu/jyu/Publications/Yu-Linux-TSM2004.pdf (althought is related with Linux-briding more than with Linux-routing) shows in Figure 14 that with an AMD Duron 1.3GHz 512M RAM a throughput of 90 Mbps can be achieved. Anybody knows any other similar analysis, please? Best regards, Fermín Galán Márquez CTTC - Centre Tecnològic de Telecomunicacions de Catalunya Parc Mediterrani de la Tecnologia, Av. del Canal Olímpic s/n, 08860 Castelldefels, Spain Room 1.02 Tel : +34 93 645 29 12 Fax : +34 93 645 29 01 Email address: [EMAIL PROTECTED] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc This was seen on the mailing list a couple of years ago, doesnt say much but it shows what could be done. On Mon, 02 Dec 2002 22:30:10 +0100 Anton Tinchev <[EMAIL PROTECTED]> wrote: > Hi, > first i wonna thank you for the great work. > I have few slack boxes with several 3com cards that acts as routers. > Some of them has 50+ vlans, 100 000+ routing entries, full BGP (zebra) with 10+ peers > and routes 50-70 mb/s traffic. Everithing is rock solid, few months uptimes. Sounds pretty impressive, really. I admire such setups. > I wona to upgrade some of my cards and need advice what to use. > On 100+mb/s interrups killing my boxes - 20 000+/s (yes, coalescing, i know:)) > What to use? tigon2 or tigon3 for gigabit? (3c985 or 3c996) None of them! Or at least not tigon3! I've tried to use one (3c996-T), and I experienced strange system lockups. The board is a dual Tyan Tiger MP with couple of Athlon MP 1600+. It was just hanging from time to time with completely no output of any kind. Just rock solid lockup. :/ Anyway, I changed to a good old 3c905C and now I don't have any problems. Well, I'm serving at half of your rate, but anyway. So, I would suggest using HP equipment. At least I've heard that it works quote well. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] sniffer that shows application data
im yet to download it, kind of looks like the program i used before. i works as a network administrator and need this in my work, not do anything else. thank you. On Fri, Nov 21, 2003 at 10:15:54PM +0200, Ivo Vachkov wrote: > Tomas Bonnedahl wrote: > >hello, as the subject tells you, im looking for a sniffer that shows the > >application data > >in real time, ie; you can follow a irc query or an icq session. > > I can think of all nasty purposes this program could be use ... but I'll > name it anyway: Ettercap - it has the feaures you want > > >i have had this program but i "lost" it, and cannot remember the name of > >it, anyone? > > > > > >-tomas bonnedahl > >___ > >LARTC mailing list / [EMAIL PROTECTED] > >http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > > > > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] sniffer that shows application data
hello, as the subject tells you, im looking for a sniffer that shows the application data in real time, ie; you can follow a irc query or an icq session. i have had this program but i "lost" it, and cannot remember the name of it, anyone? -tomas bonnedahl ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] two upstream providers
anyone here configured a network to use two upstream providers? if yes, did you use ECMP or routing protocols (EGP/IGP)? how did you solve load balancing with equal cost and failover? -tomas ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] two upstreams without nat
On Thu, Jun 26, 2003 at 09:50:45AM -0600, Aaron Dewell wrote: > On Thu, 26 Jun 2003, Tomas Bonnedahl wrote: > > i dont have any addresses nor do i own an AS, i know there are private ASNs to > > use but this seems like a more complicated solution than a mere multipath default > > route to the two upstream providers. > An ASN can be gotten from ARIN with the justification "I'm multihomed to ASN #X > and #Y" and $500. Or you can use a private AS and have your upstreams filter > it out, also reasonably common. i didnt know it was that easy really, this might be an option. > BGP is not complicated at all to use, that's a myth. It's a fairly simple > protocol, and even easier to set up. Define one external peer per router, one > internal peer (each other), this is all done by AS. Set up the routes you want > advertised. In this case, you want everything, so no inbound filtering. Done. > 3 configuration options in Zebra's bgpd. Less complicated than setting up NAT. i assume i will only advertise the core (some /28) since the lan is still a private network. i probably wont be able to get a whole /24 from my upstream. > Think about it - if you have two IP addresses total, one assigned by each > upstream, and using two default routes, anything connection-oriented is > broken immediately (TCP comes to mind). Anything connectionless (i.e. UDP) > will likely work fine. Web, ssh, IMAP, POP3, SMTP are all TCP. Those not > working make it basically useless. why wont it work? from what i understand, you could get a "per flow" with julians patches so the core-router doesnt varies on a per packet basis and thus make established connections to fail. > Otherwise, you have to have selective routes. Route this block of the internet > through provider X, that block through provider Y. No failover, no redundancy, > no point. Or, you could point default and provider X and a lower priority to > provider Y, but then you have to learn by IGP at your core when provider X dies. > That means advertising default from the borders with your IGP, which is a > workable solution, but could get messy if you're not pretty good at whatever > IGP you are using, making the assumption that your IGP will do it. However, > two problems: 1. Your second connection is idle until the primary fails, thus > wasting money. 2. All TCP connections reset when you fail over to the backup, > and reset again when you resume to the primary. i thought the multihop path was designed to solve this issue with redundancy and failover? my very first thought in this was to use ospf as IGP but i couldnt come up with something to use upstream to see if the providers still were under normal operation. just to sum it up: use something like ospf as IGP and use BGP upstream. were you assuming that i would get a /24 from my isp and use for lan or should i do nat on the core router from the lan? thanks, tomas ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] two upstreams without nat
im in the process of configurating our network to have two upstream providers, it will be loadbalanced under normal operation and a complete failover if one of the lines would fail. internetinternet | | border border | | |- core router - | | lan the "problem" im having is that i will not do nat on the core router, but on the border routers. the multipath default route is on the core router. from what i understand, could be totally wrong, you have to have nat, at least connection tracking on the core to make the multipath route per flow and not per packet. any insight of this? -tomas bonnedahl ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] zebra + tc + policy routing?
anyone here tried to merge a dynamic routing protocol (ospf or bgp) using zebra with traffic control and policy routing (using multiple tables and rules)? i have no plans to implement it, but i guess some difficulties would emerge, especially with zebra and the policy routing part. would be great if someone could address these problems, i really would like to know. ;) (im sure im missing something really fundamentally(?) here and i'll get flamed.. but i take the risk) best regards, tomas bonnedahl ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] 'routing connection'
iptraf could perhaps solve your problems, i donno the url to it but you should find it via google. -tomas On Fri, Mar 14, 2003 at 04:48:26AM -0800, Ming-Ching Tiew wrote: > > Given a running router/firewall machine, there may be > many 'routing connections' going on at same time. > I am stucked with a basic question unanswered, how do > I know which are the applications using the heaviest > routing traffic ? > > I could do a trial and error by using 'iptables', say > using a port range, but there are still too many > possibilities. > > I thought 'netstat' could solve my problem, apparently > not. It seems netstat only shows the connection > originating and terminating in the machine and not > 'routing connections'. I am looking for a simple and > light weight program which can meet this requirement. > Any recommendation ? > > > > > __ > Do you Yahoo!? > Yahoo! Web Hosting - establish your business online > http://webhosting.yahoo.com > ___ > LARTC mailing list / [EMAIL PROTECTED] > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] policy routing problem - solved
martin, you are truly the greatest network hacker around. i works like a charm, i removed the two rules that said "from , use table 'main'", and used the one you provided. thank you so much! best regards, tomas bonnedahl On Thu, Mar 13, 2003 at 11:27:37AM +0100, Tomas Bonnedahl wrote: > On Wed, Mar 12, 2003 at 10:15:21PM -0600, Martin A. Brown wrote: > > Hi Tomas, > > hello again. > > > I hope you didn't sit there waiting for this answer! > > this time no. ;) > > > : things i like to clarify: > > : 1. rules 31000 and 31100 is just so that one address on a defined network can > > reach an > > : address on the internet, and that works perfect. > > > > Looks perfect. > > > > : 2. rules 32100-32400 is supposed to be so that the router can reach > > :defined networks, this does not work. > > > > This may be part of the "which comes first, the chicken or the egg" > > scenario you alluded to in your previous mail. I'm still trying to wrap > > my mind around the intertwined relationship between source address > > selection and route selection. I can't answer your implied question about > > why this doesn't work, nor can I answer your previous question about the > > ARP queries which never have a following ethernet frame with IP payload. > > exactly my thought too with the "chicken or egg". i have looked at the iproute2 > src code and also the kernel route.c code but since im not that good of a programmer > i couldnt make anything out of it. > > i may be stupid here, the arp quierys were sent when i was trying to ping the voIP > network, but it _could_ have come from legatime traffic from the lan (the works) so > the arp request didnt necessarily had to come in conjunction with my ping. im not > sure > but when we have now looked further into this, it seems possible that it was not from > ping but from other traffic. > > > > Maybe one of the people more familiar with the kernel source code can help > > out here. > > yes. though im not sure anyone still reads this thread anymore, if anyone ever did. > ;/ > > > > : some ascii art over the network: > > > > How about some modified ASCII art! Everybody loves ASCII > > > > 0/0 internet -+ +-+ + defined networks ipsec > >\| fw |/ 10.47.17.0/24 > > +-+10.46.23.0/24 > > 192.168.2.1/24 10.100.0.0/16 > > | 192.168.75.0/24 > > | > > 192.168.2.2/24 > > +-+ > > 192.168.4.1/24 /| linux router|\ 192.168.1.1/24 > > / +-+ +--- LAN > > 192.168.4.2/24 / > > ++ > > | voip | > > ++ > >| > >+-- 172.16.1.0/24 > > > > This is what I'm able to gather from your routes and diagram, and you, > > sir, have a garden of networks. > > indeed true. you figured it out and made a much better outline than me. > > > I think what you want to do on "linux router" is to try the following > > (idiomatic) RPDB entry. > > > > # ip rule add iif lo table all# -- or table main in above case > > hm. i do not have the possibility to check this right now, but i will do it > as soon as possible. but i have to tell you, i really dont see what this "means" > or will change. just that everything that exits (and enters?) on the loopback if > will use table all? > > > I know it seems a very simple answer, to a complex question, but I hope it > > will work for you. > > well, so do i ;) > > > By the way, Tomas, did you know that you can have rule types in the RPDB, > > e.g., > > > > # ip rule add blackhole from 192.168.4.2 to 10.0.0.0/8 > > # ip rule add prohibit from 10.47.17.0/24 to 172.16.1.0/24 > > # ip rule add unreachable from 192.168.75.0/24 to 192.168.4.0/24 > > yes, i knew that. i choosed prohibit since the blackhole just drops them on the floor > and let the client time out. > > > OK, I know that tidbit doesn't help you in your current troubles, but I > > was hoping that the "iif lo" trick might help. > > ill check later today and ill mail back to you as soon as possible afterwards. > > thank you martin > > regards, > tomas > > ___ > LARTC mailing list / [EMAIL PROTECTED] > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] policy routing problem
On Wed, Mar 12, 2003 at 10:15:21PM -0600, Martin A. Brown wrote: > Hi Tomas, hello again. > I hope you didn't sit there waiting for this answer! this time no. ;) > : things i like to clarify: > : 1. rules 31000 and 31100 is just so that one address on a defined network can > reach an > :address on the internet, and that works perfect. > > Looks perfect. > > : 2. rules 32100-32400 is supposed to be so that the router can reach > :defined networks, this does not work. > > This may be part of the "which comes first, the chicken or the egg" > scenario you alluded to in your previous mail. I'm still trying to wrap > my mind around the intertwined relationship between source address > selection and route selection. I can't answer your implied question about > why this doesn't work, nor can I answer your previous question about the > ARP queries which never have a following ethernet frame with IP payload. exactly my thought too with the "chicken or egg". i have looked at the iproute2 src code and also the kernel route.c code but since im not that good of a programmer i couldnt make anything out of it. i may be stupid here, the arp quierys were sent when i was trying to ping the voIP network, but it _could_ have come from legatime traffic from the lan (the works) so the arp request didnt necessarily had to come in conjunction with my ping. im not sure but when we have now looked further into this, it seems possible that it was not from ping but from other traffic. > Maybe one of the people more familiar with the kernel source code can help > out here. yes. though im not sure anyone still reads this thread anymore, if anyone ever did. ;/ > : some ascii art over the network: > > How about some modified ASCII art! Everybody loves ASCII > > 0/0 internet -+ +-+ + defined networks ipsec >\| fw |/ 10.47.17.0/24 > +-+10.46.23.0/24 > 192.168.2.1/24 10.100.0.0/16 > | 192.168.75.0/24 > | > 192.168.2.2/24 > +-+ > 192.168.4.1/24 /| linux router|\ 192.168.1.1/24 > / +-+ +--- LAN > 192.168.4.2/24 / > ++ > | voip | > ++ >| >+-- 172.16.1.0/24 > > This is what I'm able to gather from your routes and diagram, and you, > sir, have a garden of networks. indeed true. you figured it out and made a much better outline than me. > I think what you want to do on "linux router" is to try the following > (idiomatic) RPDB entry. > > # ip rule add iif lo table all# -- or table main in above case hm. i do not have the possibility to check this right now, but i will do it as soon as possible. but i have to tell you, i really dont see what this "means" or will change. just that everything that exits (and enters?) on the loopback if will use table all? > I know it seems a very simple answer, to a complex question, but I hope it > will work for you. well, so do i ;) > By the way, Tomas, did you know that you can have rule types in the RPDB, > e.g., > > # ip rule add blackhole from 192.168.4.2 to 10.0.0.0/8 > # ip rule add prohibit from 10.47.17.0/24 to 172.16.1.0/24 > # ip rule add unreachable from 192.168.75.0/24 to 192.168.4.0/24 yes, i knew that. i choosed prohibit since the blackhole just drops them on the floor and let the client time out. > OK, I know that tidbit doesn't help you in your current troubles, but I > was hoping that the "iif lo" trick might help. ill check later today and ill mail back to you as soon as possible afterwards. thank you martin regards, tomas ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] policy routing problem
hello martin, i was sitting here and waiting for your answer, thank you ;x (for ease in the migration i use table 'main' with all routes and table 'test' with only routes to 192.168.1/24 and prohibit 0/0.) [EMAIL PROTECTED]:~# ip rule show 0: from all lookup local 31000: from 172.16.1.2 to 195.43.36.55 lookup main 31100: from 195.43.36.55 to 172.16.1.2 lookup main 32000: from 192.168.1.0/24 lookup main 32100: from 192.168.4.0/24 lookup main 32200: from 192.168.2.0/24 lookup main 32300: from all to 192.168.4.1 lookup main 32400: from all to 192.168.2.2 lookup main 32500: from all lookup test 32766: from all lookup main 32767: from all lookup default [EMAIL PROTECTED]:~# ip route show table main 192.168.4.0/24 dev eth2 scope link 192.168.2.0/24 dev eth0 scope link 192.168.1.0/24 dev eth1 scope link 10.47.17.0/24 via 192.168.2.1 dev eth0 172.16.1.0/24 via 192.168.4.2 dev eth2 10.46.23.0/24 via 192.168.2.1 dev eth0 192.168.75.0/24 via 192.168.2.1 dev eth0 10.100.0.0/16 via 192.168.2.1 dev eth0 127.0.0.0/8 dev lo scope link default via 192.168.2.1 dev eth0 [EMAIL PROTECTED]:~# ip route show table test 192.168.1.0/24 dev eth1 scope link 127.0.0.0/8 dev lo scope link prohibit default things i like to clarify: 1. rules 31000 and 31100 is just so that one address on a defined network can reach an address on the internet, and that works perfect. 2. rules 32100-32400 is supposed to be so that the router can reach defined networks, this does not work. 3. the reason of having so many routes in table main is just plain stupid when the default is the same as there "via..". i will change this in a near future but i added the networks so that it would be more clear what i was doing. some ascii art over the network: internet --| fw | -- some defined networks over ipsec 192.168.2.1/24 | | 192.168.2.2/24 voip 192.168.4.2/24 -- 192.168.4.1/24| router|192.168.1.1 -- LAN (192.168.1/24) i hope you understand, please mail back if there is some more information you would like. thanks, tomas On Wed, Mar 12, 2003 at 11:54:48AM -0600, Martin A. Brown wrote: > Tomas, > > I'd like to look at your problem, but need a few more details. > > Would you post the output of "ip rule show" and "ip route show" "ip route > show table all" (and any other tables. > > I like your sequence of 8 eventsthat help me understand your > problem > > Thank you, > > -Martin > > : i think i may know what the problem can be here. > : > : the order of what happends here is crucial, if the router wants to know > : what interface the packet is supposed to exit on and hence use that > : address as source, it needs to do a lookup in the routing table. while > : this is processing, the router cannot contribute a src address to the > : RPDB, thus the rule "from router, lookup 'main'" will not match. > : > : what will match is the rule "from all use 'main'". but 'main' doesnt > : hold this route. > : > : though this does not explain the arp packets being sent between the router and > router x. > : > : > : argh, can someone please explain this to me? > : > : regards, > : tomas bonnedahl > : > : On Wed, Mar 12, 2003 at 05:55:27PM +0100, Tomas Bonnedahl wrote: > : > hello list subscribers, i may have been too cocky in my previous posts > regarding this > : > policy routing problem of mine. (my old posts in further down). > : > > : > the problem that i cannot reach any defined network from the router still > exists. > : > i though that would be solved when adding "from interface-address, use routing > table > : > 'all'". well, it didnt. > : > > : > what i can conclude, with some help from tcpdump, from this is that the router > can > : > see the routing table when trying to reach a defined network. > : > > : > the routing table looks pretty much like this: "network a could be reached via > router x". > : > my router does send away a arp request to router x in order to send the packet > through it, and > : > router x does indeed reply, so everything tcpdump shows is these two packets, > nothing more. > : > > : > 'ping a' on the router returns: > : > > : > [EMAIL PROTECTED]:~# ping 172.16.1.2 > : > PING 172.16.1.2 (172.16.1.2): 56 octets data > : > sendto: Network is unreachable > : >
Re: [LARTC] policy routing problem
i think i may know what the problem can be here. the order of what happends here is crucial, if the router wants to know what interface the packet is supposed to exit on and hence use that address as source, it needs to do a lookup in the routing table. while this is processing, the router cannot contribute a src address to the RPDB, thus the rule "from router, lookup 'main'" will not match. what will match is the rule "from all use 'main'". but 'main' doesnt hold this route. though this does not explain the arp packets being sent between the router and router x. argh, can someone please explain this to me? regards, tomas bonnedahl On Wed, Mar 12, 2003 at 05:55:27PM +0100, Tomas Bonnedahl wrote: > hello list subscribers, i may have been too cocky in my previous posts regarding this > policy routing problem of mine. (my old posts in further down). > > the problem that i cannot reach any defined network from the router still exists. > i though that would be solved when adding "from interface-address, use routing table > 'all'". well, it didnt. > > what i can conclude, with some help from tcpdump, from this is that the router can > see the routing table when trying to reach a defined network. > > the routing table looks pretty much like this: "network a could be reached via > router x". > my router does send away a arp request to router x in order to send the packet > through it, and > router x does indeed reply, so everything tcpdump shows is these two packets, > nothing more. > > 'ping a' on the router returns: > > [EMAIL PROTECTED]:~# ping 172.16.1.2 > PING 172.16.1.2 (172.16.1.2): 56 octets data > sendto: Network is unreachable > ping: sent 64 octets to 172.16.1.2, ret=-1 > > i have googled on this but without any meaningful results. > > i was also concerned with the fact that only adding the interface address in the > rules > would be a problem, and it is. the arp reply from router x will be routed according > to table > 'main' and thus not reach the origin address. so i simpy added router x's address to > the rules and > told it to use table 'all'. i still cannot reach network a from the router. > > the thing i seem to think is the most difficult to understand here is that route > lookup is > correct, otherwise the arp request wouldnt be sent, but the packet never leaves the > router. > > this is how i see it: > 1. router is requested by me to ping network a > 2. router looks in the RPDB to see which routing table to use > 3. RPDB says "use table 'all'" > 4. router looks after a route to network a in routing table 'all' > 5. router finds a route to network a and understands that it has to send it via > router x > 6. router checks arp cache, doesnt see anything for router x > 7. router sends out a arp request to router x > 8. router x answers with a arp reply > (this is where nothing happends) > 9. router _should_ compose a packet and send it to router x > > ip route flush cache is not a problem. > > any insight on this would be helpful. thank you for your time and for reading this > far. > > > best regards, > tomas bonnedahl > > > On Tue, Mar 11, 2003 at 06:07:03PM +0100, Tomas Bonnedahl wrote: > > hello again list. i have another solution to this that has some > > advantages over my last post. > > > > when dealing with packets and their 'coming-back' i choosed to add routes > > to these networks in table 'main', instead i can create two more rules (a > > total of four rules altogether) that looks like the first two but uses > > the to parameter unstead of the from. (they'll just say "packets that is going > > to x, use table 'all'"). > > > > > > -tomas bonnedahl > > > > On Tue, Mar 11, 2003 at 05:32:51PM +0100, Tomas Bonnedahl wrote: > > > i have some additional information regarding this issue with policy routing. > > > > > > on the router that has policy routing implemented, read further down for > > > more information on my gols, three ethernet interfaces exists. > > > > > > since the routing table 'main' just consists of a route to 192.168.1/24 > > > with a prohihbit 0/0, you cannot from the router reach a network > > > that is located on some of the other interfaces than 192.168.1/24 exists > > > on. this is because the src address in the packet will be the address of > > > that interface which the packet will exit. according to the rules that exists > > > in the RPDB, that address will u
[LARTC] policy routing problem
hello list subscribers, i may have been too cocky in my previous posts regarding this policy routing problem of mine. (my old posts in further down). the problem that i cannot reach any defined network from the router still exists. i though that would be solved when adding "from interface-address, use routing table 'all'". well, it didnt. what i can conclude, with some help from tcpdump, from this is that the router can see the routing table when trying to reach a defined network. the routing table looks pretty much like this: "network a could be reached via router x". my router does send away a arp request to router x in order to send the packet through it, and router x does indeed reply, so everything tcpdump shows is these two packets, nothing more. 'ping a' on the router returns: [EMAIL PROTECTED]:~# ping 172.16.1.2 PING 172.16.1.2 (172.16.1.2): 56 octets data sendto: Network is unreachable ping: sent 64 octets to 172.16.1.2, ret=-1 i have googled on this but without any meaningful results. i was also concerned with the fact that only adding the interface address in the rules would be a problem, and it is. the arp reply from router x will be routed according to table 'main' and thus not reach the origin address. so i simpy added router x's address to the rules and told it to use table 'all'. i still cannot reach network a from the router. the thing i seem to think is the most difficult to understand here is that route lookup is correct, otherwise the arp request wouldnt be sent, but the packet never leaves the router. this is how i see it: 1. router is requested by me to ping network a 2. router looks in the RPDB to see which routing table to use 3. RPDB says "use table 'all'" 4. router looks after a route to network a in routing table 'all' 5. router finds a route to network a and understands that it has to send it via router x 6. router checks arp cache, doesnt see anything for router x 7. router sends out a arp request to router x 8. router x answers with a arp reply (this is where nothing happends) 9. router _should_ compose a packet and send it to router x ip route flush cache is not a problem. any insight on this would be helpful. thank you for your time and for reading this far. best regards, tomas bonnedahl On Tue, Mar 11, 2003 at 06:07:03PM +0100, Tomas Bonnedahl wrote: > hello again list. i have another solution to this that has some > advantages over my last post. > > when dealing with packets and their 'coming-back' i choosed to add routes > to these networks in table 'main', instead i can create two more rules (a > total of four rules altogether) that looks like the first two but uses > the to parameter unstead of the from. (they'll just say "packets that is going > to x, use table 'all'"). > > > -tomas bonnedahl > > On Tue, Mar 11, 2003 at 05:32:51PM +0100, Tomas Bonnedahl wrote: > > i have some additional information regarding this issue with policy routing. > > > > on the router that has policy routing implemented, read further down for > > more information on my gols, three ethernet interfaces exists. > > > > since the routing table 'main' just consists of a route to 192.168.1/24 > > with a prohihbit 0/0, you cannot from the router reach a network > > that is located on some of the other interfaces than 192.168.1/24 exists > > on. this is because the src address in the packet will be the address of > > that interface which the packet will exit. according to the rules that exists > > in the RPDB, that address will use the routing table 'main' which, in turn, > > does not have a route to that network. > > > > the solution to this would be to: > > 1. make (two) rules which says "if the src address of a packet is the adress > > of an interface, use table 'all'". (also note that im using the /32 address) > > 2. add, in routing table 'main', routes to these /32 addresses. > > > > the first part here is used so that a packet could be _sent_ away correct, the > > second part is used so that a packets can come _back_ correct. > > > > im sure martin have some insight in this, perhaps a simpler solution? > > > > indeed, i did not think of this when implementing policy routing since i was > > only concerned with networks and not the router itself. > > > > i hope this will help someone struggeling with policy routing. > > > > > > best regards, > > tomas bonnedahl > > > > On Thu, Mar 06, 2003 at 04:31:42PM +0100, Tomas Bonnedahl wrote: > > > hello list (and martin) ;x > > > > > > i have now composed my f
Re: [LARTC] policy routing at its best
hello again list. i have another solution to this that has some advantages over my last post. when dealing with packets and their 'coming-back' i choosed to add routes to these networks in table 'main', instead i can create two more rules (a total of four rules altogether) that looks like the first two but uses the to parameter unstead of the from. (they'll just say "packets that is going to x, use table 'all'"). -tomas bonnedahl On Tue, Mar 11, 2003 at 05:32:51PM +0100, Tomas Bonnedahl wrote: > i have some additional information regarding this issue with policy routing. > > on the router that has policy routing implemented, read further down for > more information on my gols, three ethernet interfaces exists. > > since the routing table 'main' just consists of a route to 192.168.1/24 > with a prohihbit 0/0, you cannot from the router reach a network > that is located on some of the other interfaces than 192.168.1/24 exists > on. this is because the src address in the packet will be the address of > that interface which the packet will exit. according to the rules that exists > in the RPDB, that address will use the routing table 'main' which, in turn, > does not have a route to that network. > > the solution to this would be to: > 1. make (two) rules which says "if the src address of a packet is the adress > of an interface, use table 'all'". (also note that im using the /32 address) > 2. add, in routing table 'main', routes to these /32 addresses. > > the first part here is used so that a packet could be _sent_ away correct, the > second part is used so that a packets can come _back_ correct. > > im sure martin have some insight in this, perhaps a simpler solution? > > indeed, i did not think of this when implementing policy routing since i was > only concerned with networks and not the router itself. > > i hope this will help someone struggeling with policy routing. > > > best regards, > tomas bonnedahl > > On Thu, Mar 06, 2003 at 04:31:42PM +0100, Tomas Bonnedahl wrote: > > hello list (and martin) ;x > > > > i have now composed my final(?) policy routing design. > > > > the goals i had when beginning with this, for you that have not follow > > mine and martins thread, was to 1) only let 192.168.1/24 to see all routes, > > 2) not route between defined networks, except to and from 192.168.1/24 and 3) not > > defined networks should only be able to reach 192.168.1/24. > > > > this might sound simple. it wasnt for me. > > > > the solution i came up with, after days and days of thinking (and patience) was > > this: > > > > two routing tables, one called "ALL" that, suprisingly, held routes to all > > networks defined > > and a default route to internet. the other called "main", just for ease, that held > > one route to > > 192.168.1/24 and had a default prohibit. > > > > the one rule that exists just says "if src == 192.168.1/24 use table ALL". of > > course there is > > an additional rule, the standard one that says "from all lookup main" with a > > number of 32766. > > > > so, for you that doesnt understand my poor english, literally every network that > > passes, except > > from 192.168.1/24, will use the main table that just holds the route to > > 192.168.1/24 and the > > prohibit one. > > > > > > this so simple, something just has to be wrong. feel free to englighten me. > > > > > > please flame. > > > > best regards, > > tomas bonnedahl > > ___ > > LARTC mailing list / [EMAIL PROTECTED] > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > ___ > LARTC mailing list / [EMAIL PROTECTED] > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] policy routing at its best
i have some additional information regarding this issue with policy routing. on the router that has policy routing implemented, read further down for more information on my gols, three ethernet interfaces exists. since the routing table 'main' just consists of a route to 192.168.1/24 with a prohihbit 0/0, you cannot from the router reach a network that is located on some of the other interfaces than 192.168.1/24 exists on. this is because the src address in the packet will be the address of that interface which the packet will exit. according to the rules that exists in the RPDB, that address will use the routing table 'main' which, in turn, does not have a route to that network. the solution to this would be to: 1. make (two) rules which says "if the src address of a packet is the adress of an interface, use table 'all'". (also note that im using the /32 address) 2. add, in routing table 'main', routes to these /32 addresses. the first part here is used so that a packet could be _sent_ away correct, the second part is used so that a packets can come _back_ correct. im sure martin have some insight in this, perhaps a simpler solution? indeed, i did not think of this when implementing policy routing since i was only concerned with networks and not the router itself. i hope this will help someone struggeling with policy routing. best regards, tomas bonnedahl On Thu, Mar 06, 2003 at 04:31:42PM +0100, Tomas Bonnedahl wrote: > hello list (and martin) ;x > > i have now composed my final(?) policy routing design. > > the goals i had when beginning with this, for you that have not follow > mine and martins thread, was to 1) only let 192.168.1/24 to see all routes, > 2) not route between defined networks, except to and from 192.168.1/24 and 3) not > defined networks should only be able to reach 192.168.1/24. > > this might sound simple. it wasnt for me. > > the solution i came up with, after days and days of thinking (and patience) was > this: > > two routing tables, one called "ALL" that, suprisingly, held routes to all networks > defined > and a default route to internet. the other called "main", just for ease, that held > one route to > 192.168.1/24 and had a default prohibit. > > the one rule that exists just says "if src == 192.168.1/24 use table ALL". of course > there is > an additional rule, the standard one that says "from all lookup main" with a number > of 32766. > > so, for you that doesnt understand my poor english, literally every network that > passes, except > from 192.168.1/24, will use the main table that just holds the route to 192.168.1/24 > and the > prohibit one. > > > this so simple, something just has to be wrong. feel free to englighten me. > > > please flame. > > best regards, > tomas bonnedahl > ___ > LARTC mailing list / [EMAIL PROTECTED] > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] policy routing at its best
hello list (and martin) ;x i have now composed my final(?) policy routing design. the goals i had when beginning with this, for you that have not follow mine and martins thread, was to 1) only let 192.168.1/24 to see all routes, 2) not route between defined networks, except to and from 192.168.1/24 and 3) not defined networks should only be able to reach 192.168.1/24. this might sound simple. it wasnt for me. the solution i came up with, after days and days of thinking (and patience) was this: two routing tables, one called "ALL" that, suprisingly, held routes to all networks defined and a default route to internet. the other called "main", just for ease, that held one route to 192.168.1/24 and had a default prohibit. the one rule that exists just says "if src == 192.168.1/24 use table ALL". of course there is an additional rule, the standard one that says "from all lookup main" with a number of 32766. so, for you that doesnt understand my poor english, literally every network that passes, except from 192.168.1/24, will use the main table that just holds the route to 192.168.1/24 and the prohibit one. this so simple, something just has to be wrong. feel free to englighten me. please flame. best regards, tomas bonnedahl ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] full policy routing
hello again martin, i sat down and kind of figured it out, all i have
to do now is to write some flashy bash script like you did ;)
this is what i got:
routing tables
main: all routes
prohibit: prohibit 0/0
rules
from defined1 -> 192.168.1/24 lookup main
from defined2 -> 192.168.1/24 lookup main
...
from definedN -> 192.168.1/24 lookup main
from 192.168.1/24 -> x lookup main
from x -> 192.168.1/24 lookup main
from x -> x lookup prohibit
where x here is an undefined network.
the thing is now to really get it straigh with the prio in the rules.
if you are able to, i would like a comment on it.
thanks,
tomas
On Tue, Feb 18, 2003 at 07:01:52PM -0600, Martin A. Brown wrote:
> : what i have is an internal router that transports data from ten
> : different defined networks and of course "internet traffic". one of
> : these defined networks is our lan 192.168.1/24.
> :
> : the utopia that im trying to reach is that there is a routing table for
> : each and every one of these defined networks. these routing tables will
> : pretty much only say "192.168.1/24 is on eth1. drop all other traffic
> : that is not destined for 192.168.1/24". of course the table for
> : 192.168.1/24 will have routes for all of these networks plus a default
> : route to the internet. i then use rules for directing "from network x,
> : use table x". the main table will just have one route, to 192.168.1/24
> : so that "internet traffic" can get through.
>
> I guess I can see why you'd want this, although I wouldn't recommend
> relying on routing to enforce your security. It can't hurt as an
> additional measure, though.
>
> I think you could make good use of the prohibit route. In the example
> script I just cooked up (see below), I have used a table whose sole
> purpose is to return a prohibit route. This way, you can use the RPDB to
> perform a lookup for any route to any other network. I'm not great at
> algorithms, so I'm sure somebody else out there will have a better
> suggestion for how to cheaply achieve the same end. That said, you should
> be able to define your networks in the $CONFIG file and have a bunch of
> rules entered saying--you can't go here from there.
>
> I think the big benefit here is that you are specifically "DENY"ing
> traffic based on source and destination pairings. This means you only
> have to manage two routing tables, not number-of-networks tables. The
> main routing table is still used by all hosts, unless the RPDB suggests
> looking up in table prohibit-table.
>
> : this is just for security, that a ipsec defined network cannot reach
> : the voIP network and so on, every network should just be able to reach
> : the lan.
> :
> : should this work? perhaps that was what you meant when you talked about
> : RPDB?
>
> Yes. Most definitely.
>
> : btw, seems like trouble shooting with policy routing isnt the easiest
> : ;x
>
> Indeed. It takes a bit of patience, tcpdump, printing out all of the
> routing tables and the RPDB, and some patience. But by remembering that
> it's just a big stateless mechanism, you ease your burden.
>
> Did I mention that it requires patience?
>
> -Martin
>
> # cat destinations
> 172.16.0.0/24 ipsec
> 172.17.108.0/24voip
> 192.168.132.0/24 modempool
> 10.251.8.0/24 serverfarm
> 172.195.44.0/24turnip
> 192.168.12.0/24internal
> 10.49.85.0/24 ldapnet
>
>
>
> #! /bin/bash
> #
> # -- populate some tables
>
> CONFIG=destinations
>
> ALLNETS=$( awk '{print $1 }' $CONFIG )
>
> ip rule show | grep -Ev '^(0|32766|32767):|iif lo' \
> | while read PRIO RULE; do
> ip rule del prio ${PRIO%%:*} $( echo $RULE | sed 's|all|0/0|' )
> done
>
> TABLES=/etc/iproute2/rt_tables
>
> grep -q prohibit-table $TABLES || echo 249 prohibit-table >> $TABLES
> ip route add prohibit default table prohibit-table
>
> while read NETADDR NETNAME GARBAGE ; do
> #
> # -- cycle through all of the networks, adding prohibit routes
> #ot@piggles bonnedahl]# ./maketables.sh
> for DEST in $ALLNETS ; do
>
> test $DEST = $NETADDR && continue
> ip rule add from $NETADDR to $DEST lookup prohibit-table
>
> done
>
> done < $CONFIG
>
> --
> Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED]
>
>
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] full policy routing
hello again martin. the setup i have in mind is not very exciting really. ;( what i have is an internal router that transports data from ten different defined networks and of course "internet traffic". one of these defined networks is our lan 192.168.1/24. the utopia that im trying to reach is that there is a routing table for each and every one of these defined networks. these routing tables will pretty much only say "192.168.1/24 is on eth1. drop all other traffic that is not destined for 192.168.1/24". of course the table for 192.168.1/24 will have routes for all of these networks plus a default route to the internet. i then use rules for directing "from network x, use table x". the main table will just have one route, to 192.168.1/24 so that "internet traffic" can get through. this is just for security, that a ipsec defined network cannot reach the voIP network and so on, every network should just be able to reach the lan. should this work? perhaps that was what you meant when you talked about RPDB? btw, seems like trouble shooting with policy routing isnt the easiest ;x thanks, tomas On Tue, Feb 18, 2003 at 10:46:52AM -0600, Martin A. Brown wrote: > : hello martin, thank you for your quick reply. > > My pleasure. > > : (the default routing table is empty for me, but is listed in > : /etc/iproute2/rt_tables) > > True indeedI guess I just don't know if it's a special table or just a > convention. I have never used it. Any others on the list use the default > table (table 253)? > > : i want to use "as much" rules as i can, meaning that the main table > : will only have one route to my network that come from networks not > : defined in the rules. > > I'm not quite sure I understand this completely. Do you wish to prefer > the RPDB for route selection? I don't see any technical reason you > couldn't configure one routing table for each class of outbound route, but > it seems somewhat counterintuitive. Then again, perhaps I do not > understand your desired goal. Explain more--sounds like an interesting > approach. > > : now, about the local table. if the local table is the first one > : consulted when the router is to determine a path for a packet, i dont > : want that to be filled with rules that is not defined from that > : network, but the rules maybe override that? when i looked in my local > : table, i just see broadcast address and local connected addresses, as > : you also said. > > The local table has only broadcast, local, and nat routes. There will not > be routes for remote networks--try it, and you'll get: > > RTNETLINK answers: Invalid argument > > : any idea? it seems best to go with "ip route flush table main", btw, > : you also reminded me to clean the other tables too when re-populating > : the tables, i forgot it. thank you. ;) > > I have been bitten by that one before, too! ;) > > -Martin > > -- > Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] > > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] full policy routing
hello martin, thank you for your quick reply. (the default routing table is empty for me, but is listed in /etc/iproute2/rt_tables) i want to use "as much" rules as i can, meaning that the main table will only have one route to my network that come from networks not defined in the rules. now, about the local table. if the local table is the first one consulted when the router is to determine a path for a packet, i dont want that to be filled with rules that is not defined from that network, but the rules maybe override that? when i looked in my local table, i just see broadcast address and local connected addresses, as you also said. any idea? it seems best to go with "ip route flush table main", btw, you also reminded me to clean the other tables too when re-populating the tables, i forgot it. thank you. ;) you probably understand that my native language is not english. please feel free to ask if there's something in this you dont understand. best regards, tomas On Tue, Feb 18, 2003 at 09:26:06AM -0600, Martin A. Brown wrote: > > Tomas, > > It never occurred to me to try "ip route flush table all". Does it work? > [ I'll have to try that on my critical Internet connected router! ;-) ] > > I have gotten in the habit of using "ip route flush table $ID" for any > table I'm about to populate with routes. This way, I know I'm starting > from an empty routing table. Typically I don't muck about with the main > routing table, and just use the RPDB to override the routes configured in > the main routing table. > > I don't know what you mean by the "default" routing table, but the local > routing table is a very important routing table--it's the first one > consulted in most route lookups, to see if the IP is a locally hosted IP, > a broadcast address, or a (dumb) NAT transformation. > > Have a good day, > > -Martin > > : when you are using full policy routing (multiple tables and rules for every >network), > : is one supposed to wipe all the tables clean with > : > : "ip route flush table all" > : > : or use > : > : "ip route flush table main" > : > : and still be sure that the policy routing works as it's supposed to? > : > : indeed, i dont know what the local and default tables are really doing. > : > : > : enlighentment would be appriciated. > : > : best regards, > : tomas > : ___ > : LARTC mailing list / [EMAIL PROTECTED] > : http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > : > > -- > Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] > > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] full policy routing
when you are using full policy routing (multiple tables and rules for every network), is one supposed to wipe all the tables clean with "ip route flush table all" or use "ip route flush table main" and still be sure that the policy routing works as it's supposed to? indeed, i dont know what the local and default tables are really doing. enlighentment would be appriciated. best regards, tomas ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] ip rule show fails but not ip route show
as you can see in the topic there is a problem with iproute2. 'ip rule show' returns RTNETLINK answers: Invalid argument Dump terminated while 'ip route show' for example returns the right output, what can possible be the problem here? the kernel is 2.4.18 and im not really sure with the version of iproute2. thanks for your help, tomas ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] most out of qos
i dont really see your reasoning here. of course my isp has no "control" of the data that other people is sending me, but if the sending party could do egress filtering on their nearest router on the path to reach me, my isp should be able to do the same? the difference between my isp doing egress filtering and if i were to do egress filtering is that if the isp would do it, the data is yet to enter the bottlneck in the path and could be buffred their. was this what you meant? thanks, tomas On Thu, Feb 06, 2003 at 06:22:04PM +0100, Stef Coene wrote: > On Thursday 06 February 2003 18:11, Tomas Bonnedahl wrote: > > hm, the only way i see how to really get a hold on downloads is egress > > filtering on the isp side. > Even that's too late. The isp has no control on the data that people is > sending to you. > > > ingress filtering here is just waste of time? partly because, what stef > > also said, the data is already reveived, so i can get the same effect with > > egress filtering on the internal interface of the fw, and partly because > > ingress filtering in linux is not well functioning? > You can get the same effect. And ingress shaing is works, but it's not so > powerfull. > > Stef > > -- > > [EMAIL PROTECTED] > "Using Linux as bandwidth manager" > http://www.docum.org/ > #lartc @ irc.oftc.net > > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] most out of qos
hm, the only way i see how to really get a hold on downloads is egress filtering on the isp side. ingress filtering here is just waste of time? partly because, what stef also said, the data is already reveived, so i can get the same effect with egress filtering on the internal interface of the fw, and partly because ingress filtering in linux is not well functioning? thanks, tomas On Thu, Feb 06, 2003 at 11:01:08AM -0600, Martin A. Brown wrote: > : > I'd suggest that Tomas throttles his bandwidth on transmit to the internal > : > network. It is a router, so very little traffic will be initiated from > : > the router itself. > : > Why not perform traffic control on packets transmitted to the Internet on > : > the outward facing NIC. > : > Then perform traffic control on packets received from the Internet on the > : > inward facing NIC. > : > What's wrong with this? > : Euh nothing :) > : But you have the same problem. You are controlling already received data. So > : you can only hope that the other end of the link stops sending data if you > : drop packets. > > Well, slap me with a wet fish! That's pretty obvious. > > (Martin, neophyte with traffic control, returns to routing.) > > Thanks, Stef, > > -Martin > > -- > Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] > > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] most out of qos
ok, thanks, one question though, you mean that i should use "regular" ingress qos? this could rise some problems since i want to shape both traffic entering at a physical interface and traffic entering at a virtual ipsec interface. do you have any experiance from this particular sitaution? thanks, tomas On Thu, Feb 06, 2003 at 05:23:27PM +0100, Stef Coene wrote: > On Wednesday 05 February 2003 22:28, Tomas Bonnedahl wrote: > > well, if tcp throttles down at the point where packets are dropped is of > > course good, but still, when a download is peaking at the maximum speed > > minus a couple kbits, the delay is terrible, that's what i want to change. > > any idea? > You can give the download 98% of the link so there is always 2% available for > something else. It also helps to throttle down _all_ incoming bandwidth to > 99% of your link so _you_ are shaping and not your router. > > Stef > > > > > regards, > > > > tomas bonnedahl > > > > On Wed, Feb 05, 2003 at 10:13:27PM +0100, Stef Coene wrote: > > > On Wednesday 05 February 2003 16:44, Tomas Bonnedahl wrote: > > > > to get most out of qos in general, would the best thing be to set up > > > > qos on both ends of a bottleneck with both ingress and egress > > > > filtering? the reason for asking is because we have a 2mbit connection > > > > with egress filtering qos, the problem is that we experience most > > > > downloads compared to uploades and therefor the egress filtering doesnt > > > > provide much help. > > > > > > > > what we could do is to get ingress filtering on our side here, but i > > > > dont know how much that would help really, the data has already passed > > > > the bottleneck in the path. so, my question, would i experience any > > > > different delay if adding ingress filtering? > > > > > > Yes. A tcp connection will throttle down if you drop packets. But this > > > is not the same as egress shaping. > > > > > > > it is a 2mbit fiber stub network which looks pretty much like this: > > > > > > > > lan - router - fw - isp - internet > > > > > > > > the egress qos is at the moment at the router which pretty much says > > > > "prioritize interactive sessions". > > > > > > > > > > > > since the filtering for qos is rather simple, just telnet/ssh to a > > > > certain host, should i contact my isp and ask them to set some egress > > > > qos going to our network on the cisco router that is at their place? > > > > btw, anyone know how good the qos is on cisco 2600? > > > > > > I have no idea how the qos works on cisco router. > > > Just give it a try and se what happens. > > > > > > Stef > > > > > > -- > > > > > > [EMAIL PROTECTED] > > > "Using Linux as bandwidth manager" > > > http://www.docum.org/ > > > #lartc @ irc.oftc.net > > > > ___ > > LARTC mailing list / [EMAIL PROTECTED] > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > -- > > [EMAIL PROTECTED] > "Using Linux as bandwidth manager" > http://www.docum.org/ > #lartc @ irc.oftc.net > > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] most out of qos
yes, thanks for the idea, the reason i did not think of implementing this is that i cannot see how it would help, the data has already passed the bottleneck with no particular qos with regard to interactive sessions, which should mean, if i did egress on the fws internal interface, that the ssh/telnet data would come in bursts from the fw to the host. what i mean is this, i will try to illustrate it, (this is if the egress on the fw would be implemented); data (most bulk traffic, some interactive session too) from the isp -> fw (buffer the bulk traffic, prioritize the session traffic) -> router and lan this in turn would mean that after sending the session traffic the fw would send the bulk traffic in its buffer. meanwhile the fw have received additional session and bulk traffic, and so on. maybe im missing something here? thanks, tomas On Thu, Feb 06, 2003 at 09:55:37AM +0100, Rob Rankin wrote: > Stick an egress filter on the LAN side of the firewall, and use it to > control the *inbound* data from your ISP (downloads pass through the > firewall and become *outbound* traffic on the LAN side / interface). > > Old style Ingress filtering in Linux is horrible. Its a blanket rule > stating "if the bw gets above X, drop packets" with no real filtering > capability. > > Using an egress filter on the opposite side of the firewall from the > traffic flow does actually work, although I'm not entirely sure its a > "supported" configuration. For what its worth, I have it setup exactly > as I am suggesting on my firewalls, and it does actually work. Peak > downloads are slowed down, interactive sessions do get higher priority, > etc. > > The other alternative would be to use the IMQ logical network device, > which allows the use of HTB for both ingress and egress filtering. I > plan on moving to this type of setup as soon as I have a maintenance > window long enough to drop the firewalls and bring them up to date with > the new tools / patches necessary. > > Cheers, hope this was of some help. > > On Wed, 2003-02-05 at 22:28, Tomas Bonnedahl wrote: > > well, if tcp throttles down at the point where packets are dropped is of course >good, but still, when a download is peaking at the maximum speed > > minus a couple kbits, the delay is terrible, that's what i want to change. any >idea? > > > > regards, > > > > tomas bonnedahl > > > > On Wed, Feb 05, 2003 at 10:13:27PM +0100, Stef Coene wrote: > > > On Wednesday 05 February 2003 16:44, Tomas Bonnedahl wrote: > > > > to get most out of qos in general, would the best thing be to set up qos on > > > > both ends of a bottleneck with both ingress and egress filtering? the > > > > reason for asking is because we have a 2mbit connection with egress > > > > filtering qos, the problem is that we experience most downloads compared to > > > > uploades and therefor the egress filtering doesnt provide much help. > > > > > > > > what we could do is to get ingress filtering on our side here, but i dont > > > > know how much that would help really, the data has already passed the > > > > bottleneck in the path. so, my question, would i experience any different > > > > delay if adding ingress filtering? > > > Yes. A tcp connection will throttle down if you drop packets. But this is > > > not the same as egress shaping. > > > > > > > it is a 2mbit fiber stub network which looks pretty much like this: > > > > > > > > lan - router - fw - isp - internet > > > > > > > > the egress qos is at the moment at the router which pretty much says > > > > "prioritize interactive sessions". > > > > > > > > > > > > since the filtering for qos is rather simple, just telnet/ssh to a certain > > > > host, should i contact my isp and ask them to set some egress qos going to > > > > our network on the cisco router that is at their place? btw, anyone know > > > > how good the qos is on cisco 2600? > > > I have no idea how the qos works on cisco router. > > > Just give it a try and se what happens. > > > > > > Stef > > > > > > -- > > > > > > [EMAIL PROTECTED] > > > "Using Linux as bandwidth manager" > > > http://www.docum.org/ > > > #lartc @ irc.oftc.net > > > > > > > > ___ > > LARTC mailing list / [EMAIL PROTECTED] > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > -- > Rob Rankin > [EMAIL PROTECTED] > http://undertow.ca > > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] most out of qos
well, if tcp throttles down at the point where packets are dropped is of course good, but still, when a download is peaking at the maximum speed minus a couple kbits, the delay is terrible, that's what i want to change. any idea? regards, tomas bonnedahl On Wed, Feb 05, 2003 at 10:13:27PM +0100, Stef Coene wrote: > On Wednesday 05 February 2003 16:44, Tomas Bonnedahl wrote: > > to get most out of qos in general, would the best thing be to set up qos on > > both ends of a bottleneck with both ingress and egress filtering? the > > reason for asking is because we have a 2mbit connection with egress > > filtering qos, the problem is that we experience most downloads compared to > > uploades and therefor the egress filtering doesnt provide much help. > > > > what we could do is to get ingress filtering on our side here, but i dont > > know how much that would help really, the data has already passed the > > bottleneck in the path. so, my question, would i experience any different > > delay if adding ingress filtering? > Yes. A tcp connection will throttle down if you drop packets. But this is > not the same as egress shaping. > > > it is a 2mbit fiber stub network which looks pretty much like this: > > > > lan - router - fw - isp - internet > > > > the egress qos is at the moment at the router which pretty much says > > "prioritize interactive sessions". > > > > > > since the filtering for qos is rather simple, just telnet/ssh to a certain > > host, should i contact my isp and ask them to set some egress qos going to > > our network on the cisco router that is at their place? btw, anyone know > > how good the qos is on cisco 2600? > I have no idea how the qos works on cisco router. > Just give it a try and se what happens. > > Stef > > -- > > [EMAIL PROTECTED] > "Using Linux as bandwidth manager" > http://www.docum.org/ > #lartc @ irc.oftc.net > > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] most out of qos
to get most out of qos in general, would the best thing be to set up qos on both ends of a bottleneck with both ingress and egress filtering? the reason for asking is because we have a 2mbit connection with egress filtering qos, the problem is that we experience most downloads compared to uploades and therefor the egress filtering doesnt provide much help. what we could do is to get ingress filtering on our side here, but i dont know how much that would help really, the data has already passed the bottleneck in the path. so, my question, would i experience any different delay if adding ingress filtering? it is a 2mbit fiber stub network which looks pretty much like this: lan - router - fw - isp - internet the egress qos is at the moment at the router which pretty much says "prioritize interactive sessions". since the filtering for qos is rather simple, just telnet/ssh to a certain host, should i contact my isp and ask them to set some egress qos going to our network on the cisco router that is at their place? btw, anyone know how good the qos is on cisco 2600? thanks for you time, best regards tomas bonnedahl ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] iproute2 and freeswan
hello, anyone using freeswan and iproute2 with policy routing? freeswan creates routes for VPN destination networks and puts them in the main table, or for you that use the route command, the only table. anyway, this is causing me troubles since i want to keep the main table free from the VPN networks, i want them in a special table and use that table in conjunction with ip rule. a clue anyone? regards, tomas bonnedahl ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] re: dynamic device names?
additinal info regarding this issue, the character i wanted to show here did not encode as i wanted it to, so, well, look \377 up and see what it looks like or perhaps you dont need that since that perticular character doesnt matter that much ;) -tomas ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] dynamic device names?
hello, this might be a little off the list and probably only concerns the iproute2 suite. i use tc htb with iproute2, worked fine with an uptime of ~70 days, suddenly, the device name of eth0 changes from "eth0" to "eth0". the strange(?) part of this is that all the routes that used eth0 changed too, so "X via Y dev eth0". since i couldnt get putty to type that particular letter (ÿ), i had to reboot so that it could reread the startup file with all the info about interfaces. now, have anyone seen this before, is it iproute2 related or could it be something else? greatful for enlightenment, tomas bonnedahl ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] the router knows it all?
hello, (another) quick question, the set up looks like this: lan - router - fw - the big and bad internet one time, the fw stalled/hung/died/became unreachable and when pinging the internal interface of the fw from the lan at that very time, the router answered with a icmp that the firewall "is unreachable". how on earth is the router able to know this? since there isnt a dynamic routing structure here, just a ordinary default route, i find this very strange. i dont think i have seen this before iproute2 was installed on both the router and the fw. is this some kind of feature of the iproute2 suit to know when router's are not alive although they dont rely on dynamic routing? regards, tomas bonnedahl ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] additional routes?
hello again and thanks for replying. the prohibit rule is supposed to be in that particular table that im creating for hosts whose src address is network A? i was also thinking of blackholeing as default. would this work? ip route add networkB dev eth1 table X ip route add networkA via networkB-router dev eth1 table X ip route add 0/0 blackhole table X since i dont want to use iptables too much either. thanks -tomas On Thu, Nov 28, 2002 at 11:48:01PM -0600, Martin A. Brown wrote: > > Tomas, > > I'm glad to be of help. > > : if i want to allow hosts from network A to reach and talk to hosts on > : network C, but _not_ hosts on network B, is this best controlled by > : iptables? since i now probably need to specify the route to network B > : in that very table, i cannot deny network A hosts to talk to network B > : with ip, or can i? > > I'd suggest you use iptables and a prohibit route: > > http://plorf.net/linux-ip/html/tools-ip-route.htm#EX-TOOLS-IP-ROUTE-ADD-FROM > > Here's an example: > > # ip route add prohibit x.x.x.x/24 from y.y.y.y/24 > > I would be inclined to block packets at the packet filter as well. > > # iptables -t filter -A FORWARD -d x.x.x.x/24 -s y.y.y.y/24 -j REJECT > > Good luck, > > -Martin > > -- > Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] > > > > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] additional routes?
thanks for your reply martin, i am yet to read your paper. the reason for using policy routing is that i manage several networks and i do want some kind of control on who can access whose network. this i thought is best accomplished with policy routing using ip route and ip rule. if i want to allow hosts from network A to reach and talk to hosts on network C, but _not_ hosts on network B, is this best controlled by iptables? since i now probably need to specify the route to network B in that very table, i cannot deny network A hosts to talk to network B with ip, or can i? regards, tomas bonnedahl On Thu, Nov 28, 2002 at 04:30:47PM -0600, Martin A. Brown wrote: > Tomas, > > Perhaps you want a summary of how the kernel makes a routing decision? > > See my description of the route selection process: > > http://plorf.net/linux-ip/html/routing-selection.htm > > I'm not sure you need policy routing though... If network B is reachable > from network A, and the router for network B is directly connected to > network A but is not the default gateway, you'll have something sort of > like this: > > network-C via router-B > network-B via router-B > network-A dev ethX > default via default-gw > > Is this your configuration? If so, then you need no policy routing. > > -Martin > > On Thu, 28 Nov 2002, Tomas Bonnedahl wrote: > > : hello, a simple question; on a router, if I want network A to be routed > : to network C that goes through network B, using policy routing, do i > : need to specify a route to network B also, or could i just have routes > : to A and C in the routing table? > : > : the reason that im asking is because i dont know how the ip utility > : uses the main table together with antoher table. if i didnt use policy > : routing, just "regular", this would not work, but perhaps if not > : finding a route to network B, it checks the main table? > : > : > : please enlighten me. > : > : regards, > : > : tomas bonnedahl > : ___ > : LARTC mailing list / [EMAIL PROTECTED] > : http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > : > > -- > Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] > > > > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] additional routes?
hello, a simple question; on a router, if I want network A to be routed to network C that goes through network B, using policy routing, do i need to specify a route to network B also, or could i just have routes to A and C in the routing table? the reason that im asking is because i dont know how the ip utility uses the main table together with antoher table. if i didnt use policy routing, just "regular", this would not work, but perhaps if not finding a route to network B, it checks the main table? please enlighten me. regards, tomas bonnedahl ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] problem with fragmenting (mtu/mss)
well, not really actually. i tried with iptables version 1.2.7a (the latest at the time) but the compile didnt succeed on the 2.4.5, though it did on a 2.4.18 (another box). i have now upgraded the kernel to 2.4.19 and the iptables installation worked, though im having _really_ big problems with getting a new version (1.99) of freeswan to work correct. i have compiled freeswan into the kernel, but the err msgs i get when trying to start it claims that my kernel do not have KLIPS and cant locate the modules 'ipsec'. if you have _any_ idea, please tell me. thanks tomas bonnedahl On Fri, Nov 22, 2002 at 06:20:48PM -0200, Ethy H. Brito wrote: > On 15 Nov 2002, Vincent Jaussaud wrote: > > > Hi tomas, > > > > On Wed, 2002-11-13 at 13:34, Tomas Bonnedahl wrote: > > > i have a setup that looks like this > > > > > > LAN <--> router <--> fw <--> internet > > > > > > both the router and the fw is slackware with 2.4.5, the fw also has > > > ipsec tunnels using the freeswan software. > > > > > > the problem is that the fw is continuously hanging when sending too large > > > packets through the tunnel, even a frame over 1400 bytes gets the fw to hang. > > > (which it shouldnt, 40 bytes overhead for the ip and tcp header, and perhaps 20 > > > bytes for the ESP header). > > Did you have success solving this? > > Regards > > Ethy H. Brito /"\ > InterNexo Ltda. \ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML > +55 (12) 3941-6860 X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL > S.J.Campos - Brasil / \ > > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] traffic _control_
since this list includes control of traffic, i was wondering if there is anyone that uses MRTG and knows how to set the bandwidth static? it dynamicly changes accroding to the traffic, but i want to set it at a specified bandwidth (bits/sec or bytes/sec). anyone? thanks, tomas bonnedahl ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] iproute2 with new kernel
well, does it matter _which_ kernel include files you include in the makefile for iproute2? (or, does the term "correct" mean the old or just a bootable/normal kernel?) -tomas On Thu, Nov 21, 2002 at 11:02:02AM -0300, Esteban Ribicic wrote: > from iproute2 tarball > > How to compile this. > > 1. Look at start of Makefile and set correct values for: > KERNEL_INCLUDE should point to correct linux kernel include directory. > > blah blah blah > > greets! > > > On Thu, 2002-11-21 at 10:47, Stef Coene wrote: > > On Thursday 21 November 2002 13:40, Tomas Bonnedahl wrote: > > > hello, is it necessary to recompile iproute2 when you add a new kernel, and > > > hence move the link /usr/src/linux to point on a different kernel? > > I'm not sure, but iproute uses some kernel files, so I think you better > > recompile. > > > > Stef > > > > -- > > > > [EMAIL PROTECTED] > > "Using Linux as bandwidth manager" > > http://www.docum.org/ > > #lartc @ irc.oftc.net > > > > ___ > > LARTC mailing list / [EMAIL PROTECTED] > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > -- > Esteban Ribicic > Network Operation Center > UOL-Sinectis S.A. > > Florida 537 Piso 6, Buenos Aires, Argentina > +54-11-4321-9110 ext 2503 > +54-11-4321-9107 Directo > [EMAIL PROTECTED] > www.uolsinectis.com > > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] iproute2 with new kernel
hello, is it necessary to recompile iproute2 when you add a new kernel, and hence move the link /usr/src/linux to point on a different kernel? thanks tomas bonnedahl ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] problem with fragmenting (mtu/mss)
i have a setup that looks like this LAN <--> router <--> fw <--> internet both the router and the fw is slackware with 2.4.5, the fw also has ipsec tunnels using the freeswan software. the problem is that the fw is continuously hanging when sending too large packets through the tunnel, even a frame over 1400 bytes gets the fw to hang. (which it shouldnt, 40 bytes overhead for the ip and tcp header, and perhaps 20 bytes for the ESP header). i have run out of options now, that's way im interested to hear your ideas. the different areas that i have tried to search for a solution for this problem is; 1. changing the mtu on the router to 1300 to send packets (fragmented with a small size) to the fw and let it encrypt them 2. using iptables on the router to set the mss on the syn packets travelling _from_ the ipsec network to our lan (making our clients think that it has to have that mss to send) to everything from 500 to 1440 on the router. an interactive session is able to go through the tunnel since those packets are relativly small (40-100 bytes / packet), but using ftp to upload from our lan is impossible. anyone has a clue what could cause this problem on the fw, i would feel "better" if the packets just were not sent, or perhaps that the ipsec software crashed, but this.. wtf? tomas bonnedahl network administrator ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] filter problems with htb + sfq, with script
i forgot to attach the script to my previous message, im sorry for the inconvenience. - tomas bonnedahlSkicka snabbmeddelanden till dina vänner online med MSN Messenger: Klicka här tc qdisc del root dev eth1 tc qdisc add dev eth1 root handle 1:0 htb default 222 tc class add dev eth1 parent 1:0 classid 1:1 htb rate 4Mbit ceil 4Mbit tc class add dev eth1 parent 1:1 classid 1:10 htb rate 2Mbit ceil 2Mbit tc class add dev eth1 parent 1:1 classid 1:20 htb rate 2Mbit ceil 2Mbit tc class add dev eth1 parent 1:20 classid 1:210 htb rate 512kbit ceil 2Mbit tc class add dev eth1 parent 1:20 classid 1:220 htb rate 1536kbit ceil 1536kbit tc class add dev eth1 parent 1:220 classid 1:221 htb rate 307kbit ceil 1536kbit tc class add dev eth1 parent 1:220 classid 1:222 htb rate 1229kbit ceil 1536kbit tc qdisc add dev eth1 parent 1:210 sfq perturb 10 tc qdisc add dev eth1 parent 1:221 sfq perturb 10 tc qdisc add dev eth1 parent 1:222 sfq perturb 10 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 172.16.1.0/24 flowid 1:10 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 10.47.17.23/32 flowid 1:210 tc filter add dev eth1 protocol ip parent 1:1 prio 1 u32 match ip dst 10.46.23.0/24 flowid 1:221 tc filter add dev eth1 protocol ip parent 1:1 prio 2 u32 match ip dport 0x19 0x flowid 1:221 tc filter add dev eth1 protocol ip parent 1:1 prio 2 u32 match ip dport 0x6e 0x flowid 1:221
[LARTC] filter problems with htb + sfq, with script
i forgot to attach the script to my previous message, im sorry for the inconvenience. - tomas bonnedahlMed MSN Foto kan du enkelt dela med dig av dina fotografier och beställa kopior: Klicka här ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] filter problem with htb + sfq
hello. our setup looks like this: we want to shape the egress traffic with htb and in the leaf, sfq. the problem is that all traffic goes to the default class/qdisc. i removed the default parameter in the root qdisc and instead addad another class that becomes the default class, but still all traffic goes to that class. i have tried to filter root qdisc, "root" class, everything. i have tried filtering the dst ip and also the dport, nothing matches.. what could cause this? i will attach my rc.qos script for anyone to see, it's nothing complicated, just a few classes. thank you. - tomas bonnedahlMSN Hotmail är världens populäraste e-posttjänst. Skaffa dig ett eget konto du också: Klicka här ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
