All of lore.kernel.org
 help / color / mirror / Atom feed
* [LARTC] Re: tc filter protocol arp question
@ 2004-01-31 21:11 lartc
  2004-01-31 21:19 ` Alexander Clouter
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: lartc @ 2004-01-31 21:11 UTC (permalink / raw)
  To: lartc

Alexander Clouter writes: 

> On Jan 31, lartc@pro-technica.com wrote:
>> Hello,  
>> 
>> I try to shape dhcp requests, but filter rule don't work. My script is:  
>> 
>> [snipped] 
>> 
> I really think you have other problems if you need to shape DHCP requests and
> their responses.  If we overlook the logistical part (QoS under linux only
> see's IP packets iirc, and so ARP packets are invisible) and look at what you 
> are trying to achieve. 
> 
> QoS you should seen as a way of saying "this group of packets can arrive
> 'later' without really any effect" or "these packets should arrive as soon as
> possible".  DHCP does not have realtime requirements, hell I could not care
> if it takes 2 seconds to renew my DHCP lease or 10 seconds.  If you do worry
> about things then consider a large lease time or better still look at what
> traffic is on your network and reduce it; Windoze NetBIOS is a common thing
> that can affect large networks. 
> 
> I am unsure why _anyone_ would want to prioritise DHCP traffic, it operates
> over an unreliable protocol and is built to try to obtain an IP address over
> a period of 30 seconds; if you cannot get a DHCP lease in that time (even on
> a congested network) then you have other problems which should probably be
> addressed in manner other than QoS. 
> 
> Obviously we would like to help, but we are unsure why you would want to do 
> such a thing, "Its damn right crazy man!" :) 
> 
> Regards 
> 
> Alex 
> 
> -- 
>  _______________________ 
> < All's well that ends. >
>  ----------------------- 
>         \   ^__^
>          \  (oo)\_______
>             (__)\       )\/\
>                 ||----w |
>                 ||     ||
 

I manage lan network with more that 1000 home users. Every user have 
iptables/tc pairs for marking packets/traffic limiting. Entire network 
operate via dhcp. If I miss only one user from shaper then his traffic going 
to default class. This class must have very low rate ( abount 1Kbit ). There 
going dhcp conversation. If missed user start to download, entire network 
lose dhcp server becouse of dropped packets. 

So I really need to give dhcp server priority. I thing that 512Kbit is over 
that enough to satisfy about 500 winbozes, powered on in ten minutes period. 
( This is not a joke, I see that nightmare every evening... ) 

Such a rule 'tc filter add dev eth0 protocol arp flowid ... ' i see in 
lartc.org and somewhere in mailing list. But this don't work on my linux ( 
RedHat Advanced Server 3 ). 

 --
Svetozar 


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [LARTC] Re: tc filter protocol arp question
  2004-01-31 21:11 [LARTC] Re: tc filter protocol arp question lartc
@ 2004-01-31 21:19 ` Alexander Clouter
  2004-02-02  8:01 ` arek
  2004-02-02 10:12 ` Alexander Clouter
  2 siblings, 0 replies; 4+ messages in thread
From: Alexander Clouter @ 2004-01-31 21:19 UTC (permalink / raw)
  To: lartc

[-- Attachment #1: Type: text/plain, Size: 1914 bytes --]

On Jan 31, lartc@pro-technica.com wrote:
> 
> I manage lan network with more that 1000 home users. Every user have 
> iptables/tc pairs for marking packets/traffic limiting. Entire network 
> operate via dhcp. If I miss only one user from shaper then his traffic 
> going to default class. This class must have very low rate ( abount 1Kbit 
> ). There going dhcp conversation. If missed user start to download, entire 
> network lose dhcp server becouse of dropped packets. 
> 
I know see your needs, however could I offer an alternative solution.  DHCP 
relays, put them on certain IP addresses and then mark their IP's for high 
priority traffic, this can be put in the same band along with ssh traffic and 
classed as 'core network traffic' or something fancy.

This probably would help you no end and give you the flexiblilty to do other 
things later down the road.

> So I really need to give dhcp server priority. I thing that 512Kbit is over
> that enough to satisfy about 500 winbozes, powered on in ten minutes
> period. ( This is not a joke, I see that nightmare every evening... )
> 
hmmmmm tasty :)

> Such a rule 'tc filter add dev eth0 protocol arp flowid ... ' i see in 
> lartc.org and somewhere in mailing list. But this don't work on my linux ( 
> RedHat Advanced Server 3 ). 
> 
well after my comment about shaping ARP packets, I was looking for things on 
a completed unrelated note and stumbled across something in the FAQ[1].

[1] http://www.docum.org/stef.coene/qos/faq/cache/63.html

have fun

Alex

-- 
 ________________________________________ 
/ You may be marching to the beat of a   \
| different drummer, but you're still in |
\ the parade.                            /
 ---------------------------------------- 
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: [LARTC] Re: tc filter protocol arp question
  2004-01-31 21:11 [LARTC] Re: tc filter protocol arp question lartc
  2004-01-31 21:19 ` Alexander Clouter
@ 2004-02-02  8:01 ` arek
  2004-02-02 10:12 ` Alexander Clouter
  2 siblings, 0 replies; 4+ messages in thread
From: arek @ 2004-02-02  8:01 UTC (permalink / raw)
  To: lartc

> > ). There going dhcp conversation. If missed user start to
> download, entire
> > network lose dhcp server becouse of dropped packets.

Moment, DHCP is not arp packet.
and ARP is not DHCP.

DHCP is always IP addressed /check via tcpdump/
so you can mark these addresses with tc without any problems.

ARP packets are low level packets of ethernet interconnectivity.
They will work always, unless your LAN is overloaded or somebody will do
nasty things like /arp poisoning/.
The only way you can increase your network performance for arp packets is
enabling broadcast storm control in layer-2 devices.
Some limmitations of arp-settings in linux /proc filesystem (gc_thresh_...
etc)
You can neither set static arp from Server side /and client side too (more
complex)/


Arkadiusz Binder

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [LARTC] Re: tc filter protocol arp question
  2004-01-31 21:11 [LARTC] Re: tc filter protocol arp question lartc
  2004-01-31 21:19 ` Alexander Clouter
  2004-02-02  8:01 ` arek
@ 2004-02-02 10:12 ` Alexander Clouter
  2 siblings, 0 replies; 4+ messages in thread
From: Alexander Clouter @ 2004-02-02 10:12 UTC (permalink / raw)
  To: lartc

[-- Attachment #1: Type: text/plain, Size: 2062 bytes --]

On Feb 02, arek@chelmnet.pl wrote:
> 
> Moment, DHCP is not arp packet.
> and ARP is not DHCP.
> 
however every dhcp request fires off a bunch of ARP requests.  I am 
suggesting using DHCP-relay so you put the 'long distance' DHCP requests into 
a kind of IP tunnel (?).  If this is not true then you could accomplish the 
same with IPSec/ssh tunnels.  The idea of this is to shunt the DHCP (and 
related traffic) into something that is managable.

> DHCP is always IP addressed /check via tcpdump/
> so you can mark these addresses with tc without any problems.
>
good point :)
 
> ARP packets are low level packets of ethernet interconnectivity.
> They will work always, unless your LAN is overloaded or somebody will do
> nasty things like /arp poisoning/.
> The only way you can increase your network performance for arp packets is
> enabling broadcast storm control in layer-2 devices.
> Some limmitations of arp-settings in linux /proc filesystem (gc_thresh_...
> etc)
> You can neither set static arp from Server side /and client side too (more
> complex)/
> 
I would still be keen on shunting things into a managable IP(Sec)/ssh tunnel, 
although it sounds overboard, if you are dealing with thousands of PC's (even 
hundreds) thats likely to cross several subnets.

As I mentioned before it would give you the infrastructure to have 
'maintainence' tunnel, you could put all the insecure telnet traffic in this 
tunnel to prevent it crossing the whole distance un-encrypted :)  More so you 
can give it a high priority which would help you get access to machines when 
you need to during a crisis.

Regards

Alex

-- 
 __________________________________ 
/ A likely impossibility is always \
| preferable to an unconvincing    |
| possibility.                     |
|                                  |
\ -- Aristotle                     /
 ---------------------------------- 
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2004-02-02 10:12 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-31 21:11 [LARTC] Re: tc filter protocol arp question lartc
2004-01-31 21:19 ` Alexander Clouter
2004-02-02  8:01 ` arek
2004-02-02 10:12 ` Alexander Clouter

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.