Re: [LARTC] Traffic monitor per IP
On Monday 13 November 2006 18:45, Eduardo Bejar wrote: But I would like to know if anyone knows other package to monitor traffic per IP in real time, without requiring each IP's MAC address as I have some iftop And have a look at the view modes activated by pressing s, d and p ... Daniel ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
AW: AW: [LARTC] Why did I need strange ceiling settings? (full version)
Hi andy, I reset the ceiling to 600kbit and get same same bad results as before. Also I set all classes to use the same quantum which is mtu (it is 1488 here). Here is the output you requested: miles:~# tc -s -d class ls dev ppp0 class htb 1:101 parent 1:1 leaf 8019: prio 0 quantum 1488 rate 15bit ceil 60bit burst 1674b/8 mpu 0b overhead 0b cburst 1899b/8 mpu 0b overhead 0b level 0 Sent 130659 bytes 806 pkts (dropped 0, overlimits 0) rate 224bit lended: 632 borrowed: 174 giants: 0 tokens: 84164 ctokens: 24117 class htb 1:1 root rate 60bit ceil 60bit burst 1899b/8 mpu 0b overhead 0b cburst 1899b/8 mpu 0b overhead 0b level 7 Sent 27239843 bytes 29309 pkts (dropped 0, overlimits 0) rate 286640bit 34pps lended: 16484 borrowed: 0 giants: 0 tokens: -66101 ctokens: -66101 class htb 1:103 parent 1:1 leaf 801b: prio 2 quantum 1488 rate 25bit ceil 60bit burst 1724b/8 mpu 0b overhead 0b cburst 1899b/8 mpu 0b overhead 0b level 0 Sent 27111784 bytes 28505 pkts (dropped 0, overlimits 0) rate 286232bit 34pps backlog 2p lended: 12193 borrowed: 16310 giants: 0 tokens: -83395 ctokens: -41934 class htb 1:102 parent 1:1 leaf 801a: prio 1 quantum 1488 rate 15bit ceil 60bit burst 1674b/8 mpu 0b overhead 0b cburst 1899b/8 mpu 0b overhead 0b level 0 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) lended: 0 borrowed: 0 giants: 0 tokens: 91601 ctokens: 25976 class htb 1:104 parent 1:1 leaf 801c: prio 3 quantum 1488 rate 5bit ceil 20bit burst 1624b/8 mpu 0b overhead 0b cburst 1699b/8 mpu 0b overhead 0b level 0 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) lended: 0 borrowed: 0 giants: 0 tokens: 266600 ctokens: 69726 I hope this helps to track down the problem. Thanks, Philipp -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Andy Furniss Gesendet: Dienstag, 14. November 2006 00:50 An: Philipp Leusmann Cc: lartc@mailman.ds9a.nl Betreff: Re: AW: [LARTC] Why did I need strange ceiling settings? (full version) Philipp Leusmann wrote: -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:lartc- [EMAIL PROTECTED] Im Auftrag von Andy Furniss Gesendet: Sonntag, 12. November 2006 21:51 An: Philipp Leusmann Cc: lartc@mailman.ds9a.nl Betreff: Re: [LARTC] Why did I need strange ceiling settings? (full version) Philipp Leusmann wrote: You will need to back off from the rates more and use kbit of course. tc qdisc add dev $IFACE root handle 1:0 htb default 103 default is bad if $IFACE is eth your arp will go here, also if eth Quantum should be set to ip mtu + 14. $IFACE is ppp0. Does this make difference? Yes - using htb default is safe on ppp and quantum doesn't need 14 adding. One caveat, if you get ppp MTU by script what if mtu on ppp is really big - my old ISP used to ask (during ppp negotiation) for mru of about 32k (aal5 mtu), which meant that mtu on the ppp was set to 32k. And you would recommend to use no backup at all? Had it been eth then you could have made a catch all ip filter with lower prio to get anything else. You could also have made a filter for arp/other non ip - but if non ip trafic levels are low I would just let them through unshaped, which is what htb does if you don't specify a default class / use default 0. (hfsc is the opposite - unclassified gets dropped by default). Try setting uprate ceil to 600kbit and make sure the sum of rates doesn't exceed it. Upload for a few minutes and while still uploading do - tc -s -d class ls dev ppp0 and post the output. Andy. post the output ___ 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
[LARTC] NAT/MASQ with multiple external static IPs
Hello everyone, really not sure if this is a LARTC question or not, but I have several hundred users all MASQ'd behind a single static IP. Users are reporting that certain websites are blacklisting that single static external IP for various reasons. What I would like to do is use several external IP's and have a MASQ'd user getting a random one each time. Here is a very simplified example: eth0:1.2.3.4 eth0:1 1.2.3.5 eth0:2 1.2.3.6 eth0:3 1.2.3.7 eth1: 192.168.0.0/16 Whereas, a user will sent out and given one of the eth0 addresses by random. Any clue where to start looking? Thanks! Ron [EMAIL PROTECTED] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] NAT/MASQ with multiple external static IPs
В Вто, 14/11/2006 в 16:15 +0300, Ron McKown пишет: Hello everyone, really not sure if this is a LARTC question or not, but I have several hundred users all MASQ'd behind a single static IP. Users are reporting that certain websites are blacklisting that single static external IP for various reasons. What I would like to do is use several external IP's and have a MASQ'd user getting a random one each time. Here is a very simplified example: eth0:1.2.3.4 eth0:1 1.2.3.5 eth0:2 1.2.3.6 eth0:3 1.2.3.7 eth1: 192.168.0.0/16 Whereas, a user will sent out and given one of the eth0 addresses by random. Any clue where to start looking? # man iptables .. SNAT This target is only valid in the nat table, in the POSTROUTING chain. It specifies that the source address of the packet should be modified (and all future packets in this connection will also be mangled), and rules should cease being examined. It takes one type of option: --to-source ipaddr[-ipaddr][:port-port] which can specify a single new source IP address, an inclusive range of IP addresses, and optionally, a port range (which is only valid if the rule also specifies -p tcp or -p udp). If no port range is specified, then source ports below 512 will be mapped to other ports below 512: those between 512 and 1023 inclusive will be mapped to ports below 1024, and other ports will be mapped to 1024 or above. Where possible, no port alter- ation will occur. You can add several --to-source options. If you specify more than one source address, either via an address range or multiple --to-source options, a simple round-robin (one after another in cycle) takes place between these adresses. .. -- Покотиленко Костик [EMAIL PROTECTED] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] netmask 255.255.255.255 vs ip route add via ... (bug?)
Greetings routing folks, I want to use the netmask 255.255.255.255 to insulate (not quite isolate) machines on a shared subnet from each other. This works just fine on win XP, but Linux iproute will not acccept the gateway address in one step -- neither on the command line nor via DHCP: Here's the interface, set up with a netmask of /32: # ip addr ... 2: eth0: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:08:74:48:1f:0c brd ff:ff:ff:ff:ff:ff inet 192.168.1.6/32 brd 192.168.1.255 scope global eth0 inet6 fe80::208:74ff:fe48:1f0c/64 scope link valid_lft forever preferred_lft forever ... And here's me trying to add the route: # ip route add default via 192.168.1.17 RTNETLINK answers: Network is unreachable Hmm ... erk ... workaround ... add a host route first, then add it as a default route ... # sudo ip route add 192.168.1.17 dev eth0 # sudo ip route add default via 192.168.1.17 And this is what we get ... (yep, it works) # ip route ls 192.168.1.17 dev eth0 scope link default via 192.168.1.17 dev eth0 But wait! We can delete the host route! And it works just fine (you *can* try this at home folks). # sudo ip route del 192.168.1.17 # ip route ls default via 192.168.1.17 dev eth0 So why did we need that host route? It should be possible to add the gateway directly, or it should be impossible to delete it once something depends on it. The current behaviour seems a little unbalanced (and, for my strange purposes, inconvenient :) Tested on Ubuntu 6.06 Dapper (Kernel: 2.6.15, iproute2 20041019) Looks the same on Fedora Core 3, (Kernel 2.6.11.8, iproute2 2.6.9) :-) -- Disclaimer: this disclaimer and your base are us ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] netmask 255.255.255.255 vs ip route add via ... (bug?)
Does it work if you do this? Ip route add -net x.x.x.x netmask 255.255.255.255 gw x.x.x.x Jon Flechsenhaar Boeing WNW Team Network Services (714)-762-1231 202-E7 -Original Message- From: Andrew McGill [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 14, 2006 5:49 AM To: lartc@mailman.ds9a.nl Subject: [LARTC] netmask 255.255.255.255 vs ip route add via ... (bug?) Greetings routing folks, I want to use the netmask 255.255.255.255 to insulate (not quite isolate) machines on a shared subnet from each other. This works just fine on win XP, but Linux iproute will not acccept the gateway address in one step -- neither on the command line nor via DHCP: Here's the interface, set up with a netmask of /32: # ip addr ... 2: eth0: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:08:74:48:1f:0c brd ff:ff:ff:ff:ff:ff inet 192.168.1.6/32 brd 192.168.1.255 scope global eth0 inet6 fe80::208:74ff:fe48:1f0c/64 scope link valid_lft forever preferred_lft forever ... And here's me trying to add the route: # ip route add default via 192.168.1.17 RTNETLINK answers: Network is unreachable Hmm ... erk ... workaround ... add a host route first, then add it as a default route ... # sudo ip route add 192.168.1.17 dev eth0 # sudo ip route add default via 192.168.1.17 And this is what we get ... (yep, it works) # ip route ls 192.168.1.17 dev eth0 scope link default via 192.168.1.17 dev eth0 But wait! We can delete the host route! And it works just fine (you *can* try this at home folks). # sudo ip route del 192.168.1.17 # ip route ls default via 192.168.1.17 dev eth0 So why did we need that host route? It should be possible to add the gateway directly, or it should be impossible to delete it once something depends on it. The current behaviour seems a little unbalanced (and, for my strange purposes, inconvenient :) Tested on Ubuntu 6.06 Dapper (Kernel: 2.6.15, iproute2 20041019) Looks the same on Fedora Core 3, (Kernel 2.6.11.8, iproute2 2.6.9) :-) -- Disclaimer: this disclaimer and your base are us ___ 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] netmask 255.255.255.255 vs ip route add via ... (bug?)
It works because linux (and XP too) maintain a cache of all routes learned. Try: ip route show cache.You can clean this cache: ip route flush cache. From:Andrew McGill [EMAIL PROTECTED]To:lartc@mailman.ds9a.nlSubject:[LARTC] netmask 255.255.255.255 vs ip route add via ... (bug?)Date:Tue, 14 Nov 2006 15:48:41 +0200 (SAST)Greetings routing folks,I want to use the netmask 255.255.255.255 to insulate (not quite isolate) machines on a shared subnet from each other.This works just fine on win XP, but Linux iproute will not acccept the gateway address in one step -- neither on the command line nor via DHCP:Here's the interface, set up with a netmask of /32: # ip addr ... 2: eth0: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:08:74:48:1f:0c brd ff:ff:ff:ff:ff:ff inet 192.168.1.6/32 brd 192.168.1.255 scope global eth0 inet6 fe80::208:74ff:fe48:1f0c/64 scope linkvalid_lft forever preferred_lft forever ...And here's me trying to add the route: # ip route add default via 192.168.1.17 RTNETLINK answers: Network is unreachableHmm ... erk ... workaround ... add a host route first, then add it as a default route ... # sudo ip route add 192.168.1.17 dev eth0 # sudo ip route add default via 192.168.1.17And this is what we get ... (yep, it works) # ip route ls 192.168.1.17 dev eth0scope link default via 192.168.1.17 dev eth0But wait!We can delete the host route! And it works just fine (you *can* try this at home folks). # sudo ip route del 192.168.1.17 # ip route ls default via 192.168.1.17 dev eth0So why did we need that host route?It should be possible to add the gateway directly, or it should be impossible to delete it once something "depends" on it.The current behaviour seems a little unbalanced (and, for my strange purposes, inconvenient :) Tested on Ubuntu 6.06 Dapper (Kernel: 2.6.15, iproute2 20041019) Looks the same on Fedora Core 3, (Kernel 2.6.11.8, iproute2 2.6.9):-)--Disclaimer: this disclaimer and your base are us___LARTC mailing listLARTC@mailman.ds9a.nlhttp://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartcMSN Amor Busca tu ½ naranja ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Troubles DNATing UDP
Well, I did more testing/research today... 1. I've found some posts telling about the bug in the kernel prior to 2.6.13 about ip_conntack and UNREPLIED connections probably related to my problem. Later I've found some posts telling that the bug still appear in most modern kernels. 2. I tryed to reproduce this problem in other inveronment. I've written program that sends udp packets (source and destination ports 4000) similar to those produced by HW pingers. And I felt no problem DNAT'ing packets sent from 2 machines on both 2.6.8 and 2.6.17 kernels. While doing that I've mentioned one strange thing. The output of tcpdump -v -v in reproduced case always show different UDP ID for each packet, while in real case it show the same UDP ID for all HW pingers for all packets. Does somebody know that is UDP ID and should it be related to this problem? Just in case: # tcpdump -i br0 port 4000 -v -n tcpdump: listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes 20:58:21.636684 IP (tos 0x0, ttl 64, id 6552, offset 0, flags [none], length: 102) 10.10.100.22.4000 192.168.1.2.4000: UDP, length: 74 20:58:22.888548 IP (tos 0x0, ttl 64, id 6552, offset 0, flags [none], length: 102) 10.10.100.21.4000 192.168.1.2.4000: UDP, length: 74 20:58:23.065247 IP (tos 0x0, ttl 64, id 6552, offset 0, flags [none], length: 102) 10.10.100.22.4000 192.168.1.2.4000: UDP, length: 74 20:58:23.351091 IP (tos 0x0, ttl 64, id 6552, offset 0, flags [none], length: 102) 10.10.100.23.4000 192.168.1.2.4000: UDP, length: 74 3. I've played with the router in real case and found out that the problem not always appear. Having the rule: iptables -t nat -A PREROUTING -d 10.10.100.1 -p udp -m udp --dport 4000 -j DNAT --to-destination 192.168.1.2 and doing ifdown br0, then ifup br0, and looking in /proc/net/ip_conntrack: One time I got: udp 17 29 src=10.10.100.23 dst=10.10.100.1 sport=4000 dport=4000 [UNREPLIED] src=192.168.1.2 dst=10.10.100.23 sport=4000 dport=4000 use=1 udp 17 28 src=10.10.100.21 dst=10.10.100.1 sport=4000 dport=4000 [UNREPLIED] src=10.10.100.1 dst=10.10.100.21 sport=4000 dport=4000 use=2 udp 17 29 src=10.10.100.22 dst=10.10.100.1 sport=4000 dport=4000 [UNREPLIED] src=192.168.1.2 dst=10.10.100.22 sport=4000 dport=4000 use=1 (note this src=10.10.100.1 for second rule). 10.10.100.23 and 10.10.100.22 got through. Several next times I got 2 others to work. And finally I got all of them to work: udp 17 29 src=10.10.100.23 dst=10.10.100.1 sport=4000 dport=4000 [UNREPLIED] src=192.168.1.2 dst=10.10.100.23 sport=4000 dport=4000 use=1 udp 17 28 src=10.10.100.21 dst=10.10.100.1 sport=4000 dport=4000 [UNREPLIED] src=192.168.1.2 dst=10.10.100.21 sport=4000 dport=4000 use=1 udp 17 29 src=10.10.100.22 dst=10.10.100.1 sport=4000 dport=4000 [UNREPLIED] src=192.168.1.2 dst=10.10.100.22 sport=4000 dport=4000 use=1 To conclude, right now I have all packets being DNAT'd like I want, but I guess this is until next reboot :/ -- Покотиленко Костик [EMAIL PROTECTED] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: AW: AW: [LARTC] Why did I need strange ceiling settings? (full version)
Philipp Leusmann wrote: Hi andy, I reset the ceiling to 600kbit and get same same bad results as before. Also I set all classes to use the same quantum which is mtu (it is 1488 here). Here is the output you requested: class htb 1:103 parent 1:1 leaf 801b: prio 2 quantum 1488 rate 25bit ceil 60bit burst 1724b/8 mpu 0b overhead 0b cburst 1899b/8 mpu 0b overhead 0b level 0 Sent 27111784 bytes 28505 pkts (dropped 0, overlimits 0) rate 286232bit 34pps backlog 2p lended: 12193 borrowed: 16310 giants: 0 tokens: -83395 ctokens: -41934 That is strange - assuming that upload is tcp, there are no drops and only a backlog of 2. When uploading you are somewhat dependant on the size of the window advertised by the far end - also loss, which in this case is not by htb, will make your cwind small. I think what you need to do is tcpdump -s 100 -w dumpfile the connection from the start and have a look/ post what's going on. Another way to see if it's external loss is on the sender do a few netstat -s | grep retrans and look at the counter. Small chance there could be some window scaling mismatch caused by a broken router in the way. The loss could be isp/target server dropping or - You mentioned a nominal upload rate of 1mbit which you don't reach. If you are synced at a low target SNR margin then some modems will doggedly hold the line and take the loss - others will drop and resync (often at a similar rate as the extra noise that causes the resync is gone when it retrains). I have to limit my downrate to 75% of 6db speed and it still drops sometimes. My up is solid, though, as it's limited to 50% due to the product I am on (448/up to 8128 - horribly asymmetric if I could sync at 8128) As to why shaping on/off makes such a difference - I am not sure, you are backlogged so there is some limiting happening, so maybe the higher speeds achieved without htb rely on being able to burst out full speed whenever loss is low. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] netmask 255.255.255.255 vs ip route add via ... (bug?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings Andrew McGill, : I want to use the netmask 255.255.255.255 to insulate (not quite : isolate) machines on a shared subnet from each other. This works : just fine on win XP, but Linux iproute will not acccept the : gateway address in one step -- neither on the command line nor : via DHCP: Try using the onlink nexthop flag for your route: # ip route add onlink default via 192.168.1.17 This marks the route for entry even though the local routing table may not have a route to the nexthop destination. In your case, this is a valid parameter, and should prevent the need for you to add the host route only to remove it. : So why did we need that host route? You need the host route to the destination as a simple sanity check. - From the perspective of the kernel, there's no route to 192.168.1.17 if the IP bound to your interface is a /32. When you add the route, the sanity check succeeds. Essentially, you are suppressing this sanity check by using the onlink parameter, which says Yes, I know there's no route to IP 192.168.1.17 out this interface, but I know the IP is there on this link layer anyway, so set the route anyway and stop griping.* Good luck, - -Martin * RTNETLINK answers: Network is unreachable - -- Martin A. Brown http://linux-ip.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: pgf-0.72 (http://linux-ip.net/sw/pine-gpg-filter/) iD8DBQFFWnH+HEoZD1iZ+YcRAsu2AKDixJF7A0LMClN8snQVq1zk9DV4dQCeIW7R HMtOMud8Kt5yQLskMK7HwDY= =PVyl -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
