Hello Tom,
Sorry, please but i again return to IFB question. If i correct
understand
in current situation IFB haven't profit from ESFQ in common cases (i mean
internal networks masquarading) so as we wait from ESFQ allocates bandwidth
fairly per source IP(internal) but IFB don't know internal IPs.
If i correct, what do you think what can help IFB to solve its main
disadvantage (don't see internal IPs)?
Thank you,
Alex
----
Доставка на дом и в офис пиццы, суши, шашлыка, напитков круглосуточно.
Закажи сейчас! http://www.pizza.by
(017) 266-35-07, (029) 690-93-93, 555-93-93
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
alex wrote:> Hello Tom, > Sorry, please but i again return to IFB question. If i correct > understand > in current situation IFB haven''t profit from ESFQ in common cases (i mean > internal networks masquarading) so as we wait from ESFQ allocates bandwidth > fairly per source IP(internal) but IFB don''t know internal IPs. > If i correct, what do you think what can help IFB to solve its main > disadvantage (don''t see internal IPs)?This seems like an insurmountable limitation of IFBs used to shape input traffic. Looks like you still need to shape output on your internal interfaces if you want to take advantage of ESFQ (when and if it ever makes it into standard kernels/distributions). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>> Hello Tom, >> Sorry, please but i again return to IFB question. If i correct >> understand >> in current situation IFB haven't profit from ESFQ in common cases (i mean >> internal networks masquarading) so as we wait from ESFQ allocates >>bandwidth >> fairly per source IP(internal) but IFB don't know internal IPs. >> If i correct, what do you think what can help IFB to solve its main >> disadvantage (don't see internal IPs)? > > This seems like an insurmountable limitation of IFBs used to shape input >traffic. Looks like you still need to shape output on your internal >interfaces if you want to take advantage of ESFQ (when and if it ever makes >it into standard kernels/distributions).Of course Tom, i am not against, but this way (to shape output on internal interfaces) would not work for multiple interfaces (we MUST have something that will know about situation on all interfaces for effective distribution bandwidth between them). ONLY for case with one internal interface it would work (and not need IFB). As i understand, for incoming traffic we have not yet REALLY useful shaping tools now. May be it will can third generation: IMQ -> IFB -> ... Thank you very much, Alex ---- Я тут! Найди своих друзей и знакомых на TUT.BY! http://i.tut.by/ ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users