[LARTC] QoS in Linux
Hello All, I am interested in QoS provided by Linux, when I looked into IP header I came accross ToS field, also while going more into detail about QoS I found that the QoS based on ToS is serviced thru DiffServ which in turn gives more priority to packets with higher value is ToS field, but I am not able to understand when we finally call dev->hard_start_xmit routine of underlying device type driver, how these packets are given high priority or low priority in the device queue. Please advice me here, Thanks -krishan___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Balancing multiple connections and NAT
On Fr, 2006-02-24 at 22:22 +0100, Sebastian Bork wrote: > Done. It happens here, too. But now it gets really strange: the data (I > tried scp) goes out on IF1 with IF2's source address. The ACK packets > come in on IF2. The connection works anyway ... *That's* what I'd call > really cool load-balancing. It obviously only worked with my setup because two of the three routes end on the same router of the upstream provider. As soon as the other provider is used for a route, everything breaks down. I'll try those patches tomorrow. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ipp2p don't block Ares
2006/2/27, Roberto Pereyra <[EMAIL PROTECTED]>: Hi Klaus >AFAIK ipp2p should block the newest version of ares (at least the >login). Yes, ipp2p block latest version Ares login (looks connecting ...) but without connecting upload and download files. I have the same bridge setup and some weeks back the blocking worked well. How I can help you ? roberto 2006/2/26, Klaus <[EMAIL PROTECTED]>: Hi,Andreas Klauer wrote:> On Thu, Feb 23, 2006 at 09:26:48AM -0300, Roberto Pereyra wrote:>>>This bridge works fine buts since two weeks can't block Ares traffic. All>>protocols block fine but Ares not (upload and download). Somebody are using ipp2p blocking the latest Ares version ?>>> Did you already contact the author about this? If the Ares protocol changed,> you've practically got a new protocol there, which requires it's own pattern > for matching. If you can provide details about the new protocol (by dumping> Ares packets or something) and help with testing, it should be not that hard> to fix, provided the new protocol isn't something nasty. Ares is a proprietary protocol and they change their signatures (eventhe login signatures) with every new version.AFAIK ipp2p should block the newest version of ares (at least thelogin). Traffic shaping does not work at the moment, because ares encrypts the data connections with an unknown method and without anygood signatures. I will check the newest version of ares this week andupdate the ares pattern if needed.My real job keeps me very busy at the moment (and I have been ill for three weeks now), but I will try to bring out a new version of ipp2pwith some bug fixes very soon.Klaus,maintainer of ipp2p___LARTC mailing list LARTC@mailman.ds9a.nlhttp://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- Ing. Roberto Pereyra ContenidosOnlineServidores BSD, Solaris y LinuxSoporte técnico ISPsJabber ID: [EMAIL PROTECTED] For reliable and professional DNS, use DNS Made Easy! http://www.dnsmadeeasy.com/u/14989 -- Ing. Roberto PereyraContenidosOnlineServidores BSD, Solaris y LinuxSoporte técnico ISPsJabber ID: [EMAIL PROTECTED] For reliable and professional DNS, use DNS Made Easy!http://www.dnsmadeeasy.com/u/14989 -- Ing. Roberto PereyraContenidosOnlineServidores BSD, Solaris y LinuxSoporte técnico ISPsJabber ID: [EMAIL PROTECTED] For reliable and professional DNS, use DNS Made Easy!http://www.dnsmadeeasy.com/u/14989 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] ipp2p don't block Ares
Hi Klaus >AFAIK ipp2p should block the newest version of ares (at least the >login). Yes, ipp2p block latest version Ares login (looks connecting ...) but without connecting upload and download files. I have the same bridge setup and some weeks back the blocking worked well. How I can help you ? roberto 2006/2/26, Klaus <[EMAIL PROTECTED]>: Hi,Andreas Klauer wrote:> On Thu, Feb 23, 2006 at 09:26:48AM -0300, Roberto Pereyra wrote:>>>This bridge works fine buts since two weeks can't block Ares traffic. All>>protocols block fine but Ares not (upload and download). Somebody are using ipp2p blocking the latest Ares version ?>>> Did you already contact the author about this? If the Ares protocol changed,> you've practically got a new protocol there, which requires it's own pattern > for matching. If you can provide details about the new protocol (by dumping> Ares packets or something) and help with testing, it should be not that hard> to fix, provided the new protocol isn't something nasty. Ares is a proprietary protocol and they change their signatures (eventhe login signatures) with every new version.AFAIK ipp2p should block the newest version of ares (at least thelogin). Traffic shaping does not work at the moment, because ares encrypts the data connections with an unknown method and without anygood signatures. I will check the newest version of ares this week andupdate the ares pattern if needed.My real job keeps me very busy at the moment (and I have been ill for three weeks now), but I will try to bring out a new version of ipp2pwith some bug fixes very soon.Klaus,maintainer of ipp2p___LARTC mailing list LARTC@mailman.ds9a.nlhttp://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- Ing. Roberto Pereyra ContenidosOnlineServidores BSD, Solaris y LinuxSoporte técnico ISPsJabber ID: [EMAIL PROTECTED] For reliable and professional DNS, use DNS Made Easy! http://www.dnsmadeeasy.com/u/14989 -- Ing. Roberto PereyraContenidosOnlineServidores BSD, Solaris y LinuxSoporte técnico ISPsJabber ID: [EMAIL PROTECTED] For reliable and professional DNS, use DNS Made Easy!http://www.dnsmadeeasy.com/u/14989 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] Proxy ARP and UDP
OK - Here is how I am running tcpdump. Not really much to tell. In one window: tcpdump -i eth1 -n And then in another window: tcpdump -i eth0 -n If I were filtering anything with tcpdump I would be pretty embarrassed. :) eth0 is the interface pointing to the Internet. eth1 is inside. For every several thousand packets that tcpdump shows me on eth1, I see maybe one or two on eth0 when running any traffic at all between the Internet and my proxy ARP'd device. Since these are conversations with a host on the other side of the Internet I should see packets flying across both interfaces. But I don't. I only see packets flying across the inside interface, except for a very small subset that I see on the outside interface. This behavior makes no sense. How is it possible that any connection between my proxy ARP'd host and the Internet works if virtually no traffic is moving across the outside interface The obvious answer - it isn't. Traffic must in fact be moving across the outside interface, otherwise my proxy ARP'd device would never see it. So the only possible conclusion is, the traffic must he happening someplace where tcpdump and evidently also the traffic shaping code does not see it. Don't believe me? Try it yourself. Send a bunch of pings from somewhere across the Internet to your proxy ARP'd device and watch your outside interface. I'll bet you don't see them. But your proxy ARP'd device will see them, assuming you have some firewall rules that allow this. It will reply and the requesting host outside the Internet will see the echo reply packets coming back. But your outside firewall interface will look dead even though the echo request/reply packets are clearly flying across it. Look for yourself if you don't believe me. Here is my traffic shaping script. Again, pretty basic stuff - nothing fancy. And it isn't relevant to my issue. TC="/sbin/tc" $TC qdisc del dev $INET_IFACE root $TC qdisc del dev $TRUSTED1_IFACE root $TC qdisc del dev $DMZ_IFACE root $TC qdisc add dev $INET_IFACE root handle 1: prio # This *instantly* creates classes 1:1, 1:2, 1:3 $TC qdisc add dev $TRUSTED1_IFACE root handle 2: prio # This *instantly* creates classes 2:1, 2:2, 2:3 $TC qdisc add dev $INET_IFACE parent 1:1 handle 11: pfifo $TC qdisc add dev $INET_IFACE parent 1:2 handle 12: pfifo $TC qdisc add dev $INET_IFACE parent 1:3 handle 13: pfifo $TC qdisc add dev $TRUSTED1_IFACE parent 2:1 handle 21: pfifo $TC qdisc add dev $TRUSTED1_IFACE parent 2:2 handle 22: pfifo $TC qdisc add dev $TRUSTED1_IFACE parent 2:3 handle 23: pfifo # # This assigns traffic to/from $PUBLIC_VTC1_IP and $PRIVATE_VTC1_IP # to the highest priority band of the queue for the appropriate # interface, and the rest to the next-highest proirity band. # # VTC1 $TC filter add dev $INET_IFACE parent 1:0 protocol ip prio 1 u32 \ match ip dst $PUBLIC_VTC1_IP flowid 1:1 $TC filter add dev $INET_IFACE parent 1:0 protocol ip prio 1 u32 \ match ip src $PUBLIC_VTC1_IP flowid 1:1 # VTC2 $TC filter add dev $INET_IFACE parent 1:0 protocol ip prio 1 u32 \ match ip dst $PUBLIC_VTC2_IP flowid 1:1 $TC filter add dev $INET_IFACE parent 1:0 protocol ip prio 1 u32 \ match ip src $PUBLIC_VTC2_IP flowid 1:1 # Everyone else $TC filter add dev $INET_IFACE parent 1:0 protocol ip prio 2 u32 \ match ip src 0.0.0.0/0 flowid 1:2 $TC filter add dev $TRUSTED1_IFACE parent 2:0 protocol ip prio 2 u32 \ match ip src 0.0.0.0/0 flowid 2:2 exit > Greg, > >Please, if you want answers, provide enough information for us to help. > >In the absence of any shaping configuration script, it is useless to >speculate about why you see nothing being shaped. I will say that UDP >is not "protocol ip". Neither is ARP nor ICMP. > >In the absence of the parameters you are passing to tcpdump, nothing can >be said about why you are not seeing the expected traffic on the external IF. > >Run 'cat /proc/net/ip_conntrack | grep udp' > >There is nothing wrong with your .27 kernel! I have done something >similar to what you seem to be trying to do for years running kernels >from 2.4.25 through .32 and never had any problem at all with proxy ARP >(except for the mental part ;) >-- >gypsy ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
