fastroute
Hi packet gurus. I am wondering if there is a fastroute function in pf. I have not found it in pf documentation anywhere. I am using 3.1 release. I ask because I want to fastroute my isp's multicast streams beyong my NAT box. Cheers Marco __ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com
Missing Posts (was: Re: Is it possible to apply 'route-to' rules to redirected packets?)
* Dries Schellekens <[EMAIL PROTECTED]> [20021002 16:40]: > On Wed, 2 Oct 2002, Henning Brauer wrote: [I'm missing this ^ parent post, among others] > > sorry. > > > > I hate reply-to: to the list address. > > Bwa, it's in german. BTW what the heck is "schlammcatchen"? ;-) Is it just me, or is anybody else missing various posts made today? I know that Daniel's telco's dslam module was down but some of you (Dries, Henning) are replyig to stuff I haven't received? *harrumph* John -- John Bacalle Pride is an abomination. One must forgo the self to attain total spiritual creaminess, and avoid the chewy chunks of degradation. --A. Ventura
BINAT troubles -- SOLVED!
Loic Cuguen's suggestion to add an alias to the NAT box fixed the problem. That would be why I had half-open connections all the time. Hopefully soon I'll be able to write up getting a NAT box up and running -- there are nice tutorials for transparent bridging, but I haven't found any for NAT. When I have something I'll have y'all look at it. Thanks for the help! *** * Adam Getchell [EMAIL PROTECTED] * System Architect/Programmer (530) 752-1584 * Human Resources Information Systems http://www.hr.ucdavis.edu/ *** "Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu
R: Load balancing/failover
Hi,
I'm working on vrrp implementation on OBSD.
My starting point was Linux vrrp implementation done by Jerome Etienne
and FreeBSD vrrp.
I hope in 2 or 3 weeks to have a "running" version of vrrpd for OBSD 3.1
In the meaning time I send a patch around ifconfig and 'if' files to
support MAC showing and MAC setting on ethernet card.
Luk
__
Ing. Luca Peruginio mailto: [EMAIL PROTECTED]
o
Oxys S.r.l. o Mob.: +39 335 7746997
Via Gaetana Agnesi, 12o Off.: +39 02 58327300
20135 Milano MI (ITALY) o Fax : +39 02 58304654
> -Messaggio originale-
> Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Per conto di Dries Schellekens
> Inviato: mercoledì 2 ottobre 2002 18.12
> A: [EMAIL PROTECTED]
> Oggetto: Re: Load balancing/failover
>
>
> On Wed, 2 Oct 2002, Daniel Hartmeier wrote:
>
> > Another point is how this deals with #Ip1 going down.
> Should any part of
> > pf (in kernel?) monitor (or even probe) the targets and
> modify the list
> > automatically? Or would you want a userland daemon to do
> that? Or do it
> > manually completely?
>
> Just write an userland daemon that monitors all the IPs and change the
> PF rule to remove the IP of servers that go down and later
> add it again.
>
> Just copy the behaviour IPFilter has. Described in the old ipnat(5)
>
> LOAD-BALANCING
>Two options for use with rdr are available to support
>primitive, round-robin based load balancing. The first
>option allows for a rdr to specify a second destination,
>as follows:
>
>rdr le0 203.1.2.3/32 port 80 -> 203.1.2.3,203.1.2.4 port 80 tcp
>
>This would send alternate connections to either 203.1.2.3
>or 203.1.2.4. In scenarios where the load is being spread
>amongst a larger set of servers, you can use:
>
>rdr le0 203.1.2.3/32 port 80 -> 203.1.2.3,203.1.2.4
> port 80 tcp round-robin
>rdr le0 203.1.2.3/32 port 80 -> 203.1.2.5 port 80 tcp
> round-robin
>
>In this case, a connection will be redirected to
>203.1.2.3, then 203.1.2.4 and then 203.1.2.5 before going
>back to 203.1.2.3. In accomplishing this, the rule is
>removed from the top of the list and added to the end,
>automatically, as required. This will not effect the dis-
>play of rules using "ipnat -l", only the internal applica-
>tion order.
>
>
> Cheers,
>
> Dries
> --
> Dries Schellekens
> email: [EMAIL PROTECTED]
>
begin 666 lladdr_support.tgz
M'XL(`(D;E#T``^T::W/:2#)?Q:_H\]8E8 26>-IDG0L5VUEJ'=L5R"95V10U
ME@9018PX29CUI7R__;IG)"&!R&-O[>S=JAWTF.GNF>G7]+2R8*$U>W2_8!@M
MH]MNXUW"YET]=]NMMF&V&ZTFMIM&M]-YU+[G>4E8!B'S<4C?\\+/X:UFG+L/
M,:&'A07I_R#PK(^.5Y^-%_=A#JA.H]-J[=(_]G9C_;=:3;(3L]GIF(^,/WHB
M>? 7UW^M5H-8^]J9[\"0+Z#1!=/H-0][C28T#*-1JE:K"=;8\YUI&M4XZK6Z
MO49#H3Y_#K5N2^] %:^'\/QY"7ZP^<017!L.+E^<#,[Z)R>O-1@/+M^6GSA/
M=&BT=0A"?VF%X$Q\_L^*=K /-G=YR&%P!LRV?=@_R++IY[#II-@PUV$!\4)6
MR.# FDTE+VK>8O9R<';2'_4UXO4Z8M;-F=.4T]O89B$C'M6(!T0\SL]I2@`I
M-LW&!AM B#BYCO@(+K_A;K+$#,=A/D,1_,%AB-7J/;,X[6L5_:1W[<;W;7WB[X$$.B>\M0R[;J6>",1,&%Z%;HEI,8B@QA7X?EV/7$5 >+(N2!7'I+B,Q!CI79=XYHQHS5#>1)["#[Z(K].*B.@'+FQG
M4JIFA-"A^%X"V(=W[][U.^[_EP#.5]
M9[*H/J9"O?6SW&@Q_*%61.732L5^-LQ&)4M'C'$"Y+L2+3Y_1EURC7A%DSK
M],?45 _8.%K?)H-XL=LK'/[95AA\Q0ISFETN/K/NR%317S54-ENZ88]L@%88
M>+5G@3=>^!Y:Y;%ZA?M11IH<#UFE06G* 0HG-3+Z35<7+
MS+? 2-YGY_V70QW*L:L_1I85,LH[4E#&'M&5JNA*+]$#PQF/$BQVRWV98/$@
M`$\`$^21W)\PB]<)7]+TB<0)('3F'%8<$=U;U.)BX?DA6-P/F2- 1CCP)FL&
M@2ZIF;")R/;$DQ"S5M=;J0EP,0UG1$!O\1Q0#BE_YYR@)Q1A2)\B9;08XT&AM':TL-
M)LF^?;"5@SL#354M@]1:@4]9;Q^M)^=G QRFM_MPA\,+P\/
MC49[.VA@7(IL4:D]
M8]:8"\*);4D'.<,Q!;#Q^>G%9T) ])JX_T[A7ER>G/Z28G27"ILQDD']LD/]
M17XZ_!_UTR#/3^,[1=;?Y;*Q66-ND7#Z8SPYTX>'4!IEXJ?WM_\[%R?*1(JT
MV6X8_E=P^I.'"PH!(/CJFT)&;*K?$#J^'#$RG%5V1%JK/'2T0>$,E 9G8:LQ>!-?0B0%17AA5S6XD;2ZS/'Y7Y^-V9**AO9Z*W*N@:"1(B2
MJ1THTQ0*M669VV@/V\0I!!FL=G=?^QZS4QRPEV31.&J2+!I'[:@XIGV"O=J<
MVP[S%N&>KEVG)H']Y-7IQ_EK7E@+9QGAPIRM*1^ TA<5S
M" <7PY&NQ42$F*'Z:HHD!B.ADM:>+M]C\KC?2)X4I%00CTS)EHZ!-O"M_0/-
MT#7Y2Y2YB88ZV$2+U+*)Z;@NGS)W_R!&I@Y"DO;7;790VE6\'^EF)';M#B_X
M*]6TQ>PV&"/?0:DJ2Q-1I5#/EJ*R.\W:K:70.T33:2
M@%8*R@+;* 4RP7:[$=N@MO=K^%YJ'>15IJ(?X'UB;ZH5GQQ/?/A5[,4TV!'Z
MC@4"LJWA,F[:JD1)A,@LY"5#*5;HG'A:6&&V-,;'3&>X% *S4;2>.%.*S($>
M,YCJLV&$+WODTCM')A63&EVCK;=463BJ%961!V:(D:B2DJH*%NE@HK+1!45K,,9U453/8YTP>WQ(4?,<<+<((/2''W#B#2)SH
M])*3\*T8+FEOSMR)YZ/N9"Y?R^3R>SNK?ZF4"2 S<6%A0AXG:X+-N0[J&CC_
MXMXDTU7)3%BUIXJ$L'ERVHT]87,'SR7'T#\;GP\N?EYCJA,"BD+?(E+ER9WG
MA"VW'N:[=>35.^0K.>!)DL*!'DA:AQ\K$H0+Y
MJOO>B=D#P4;^?_@=\G^SU6@D^7];MILMHUM\_WT(R.3_AYOY?*?7;N?D_X>[
M\W_S:)W_-[H=F7#@S51?<.("[:O1&\ =2E5>;7[C6/+K)'5-G1LN2E#O^W##
MW"6'>@E>N)[ S4Q^]PU@A4D?[K+HQ4Y4NU6(+ `65WPPJ:[EMAIL PROTECTED]
M2M5TC3B[,V[5B&%$S"ULN^:P##A]."U5>7U:E__=ALEJV:O^BPT&,L!0?3;A
MI..(WG(ZHX%+U3FG*K 3S!5/
Re[2]: Load balancing/failover
Hello Daniel,
Wednesday, October 2, 2002, 12:25:38 PM, you wrote:
DH> On Wed, Oct 02, 2002 at 12:15:26PM -0300, Alejandro G. Belluscio wrote:
>> rdr-load on #if inet proto tcp from any to #ExtIf port www -> \
>> {#Ip1 port www, #Ip2 port www, #Ip3 port www} \
>> [balance-weight {4, 5, 9} #idnum | balance-round-robin #idnum]
DH> Yes, that makes sense, and Ryan McBride is actually working on doing
DH> something like that. There are a couple of questions still, though. If
DH> we allow free lists like { #Ip1, #Ip2, ... }, we have to find a way to
DH> store them in kernel and pass them through ioctls. Considering that the
DH> list may be large, that can be non-trivial (also adding or removing
DH> addresses from this list without removing the entire rule).
I think you could let the IP fixed and just work on the balancing
algorithm. So if you use weighted, you just asign 0 value. If you use
round robin you may make an available bitmap and use it for deciding
to which ip forward. You may loose the oportunity to add/delete new IP,
but you can efectively turn on/off. Which may be should be just fine.
DH> Another point is how this deals with #Ip1 going down. Should any part of
DH> pf (in kernel?) monitor (or even probe) the targets and modify the list
DH> automatically? Or would you want a userland daemon to do that? Or do it
DH> manually completely?
Well, I usually like to keep thing to the minimum. That's why I
supposed that we should use something like hearbeat from userland and
let him modify this data. It may have some security implications, thou.
--
Best regards,
Alejandro Belluscio
PD: I forgot to post to the list, sorry.
Re: Re[2]: Load balancing/failover
Making, drinking tea and reading an opus magnum from Alejandro G. Belluscio:
> Hello Michael,
>
> Wednesday, October 2, 2002, 12:29:12 PM, you wrote:
>
> MS> Making, drinking tea and reading an opus magnum from Alejandro G. Belluscio:
> >> Daniel,
> >> I've just subscribed, but on Sat, 10 Aug 2002 23:11:41 +0200 you
> >> replyed to Loic Cuguen regarding the non existence of a roadmap with:
> >> > There are certainly some larger goals that have not been achieved yet,
> >> > like redundancy/failover, load balancing, proxies for further
> >> > protocols, altq integration, etc.
> >> I've always thought about the failover/load balancing by making an
> >> extension to rdr, something like
> >>
> >> rdr-load on #if inet proto tcp from any to #ExtIf port www -> \
> >> {#Ip1 port www, #Ip2 port www, #Ip3 port www} \
> >> [balance-weight {4, 5, 9} #idnum | balance-round-robin #idnum]
> >>
> >>For this to work you'd need to keep state on the tcp connection and
> >> do something sane on udp. So when a Syn packet comes to the rdr-load
> >> address/port, you evaluate the balance algorithm (in this case I
> >> proposed round robin and some fix weight) decide some of the given IPs
> >> and so you make a rdr to that IP. I haven't taken a look at the pf code
> >> (not that I'm good enough to understand it) but I though this wouldn't
> >> kill performance (may be double the lookup time for the rdr packets) and
> >> shouldn't be too invasive. I've given #idnum so you could eventually
> >> change the weight or add/takeout IP from the pool for a given rule.
> >> A second option would be to create a pseudo device that does the
> >> balancing, and have a whole syntax just for that, but then we would be
> >> duplicating information and processing time.
> >> I haven't evaluated how would this interact with the route-from
> >> extension (if it's going to be merged :-) but any of the two alternative
> >> shouldn't be incompatible.
> >> This is just a proposal, if has been discused before, apologies. If
> >> you find it stupid or uninformed just tell me where can I get more info
> >> to make better proposals.
>
> MS> ah, uh, my eyes.
> MS> this is an ugly hack that violates the whole concept of the networking.
> MS> we've discussed this w/ daniel a few times already.
> MS> there are a few different approaches here.
> MS> one might be to use a vrrp and a state sync between two pf boxens.
> MS> the other, in case there are two uplinks from one pf box
> MS> is to teach the networking stack about multiple routes to the same
> MS> destination and make it do the ballancing or whatever.
> MS> both this cases are doable and allow a whole bunch of other usefull
> MS> things to be implemented beyond one "useful" pf hack.
> MS> i find route-from a very bad idea myself.
>
>I didn't understand what specifically you didn't like. Could you
> give me some specific part that you think is so brain dead. I'm not
> saying that my idea is right. But at least point out what's the problem.
> Are you aware that I'm proposing a solution to presenting a farm of
> servers as a single IP/port to the outside world? Because from your
> responce it seems more like if I was talking about the multiple ISP load
> balancing (which I'm not).
argh, i was reading the route-from thread and by the end
of your post got hooked up onto it again since you mentioned it as well (;
it means for the route-from, of course.
but, incoming load-balancing is a completely separate
task, it needs no knowledge of the filtering rules and
requires a lot of userland action as well.
therefor it has to be implemented outside of the pf or
network stack in general for that matter.
cu
--
paranoic mickey (my employers have changed but, the name has remained)
Re: Load balancing/failover
On Wed, 2 Oct 2002, Daniel Hartmeier wrote: > Another point is how this deals with #Ip1 going down. Should any part of > pf (in kernel?) monitor (or even probe) the targets and modify the list > automatically? Or would you want a userland daemon to do that? Or do it > manually completely? Just write an userland daemon that monitors all the IPs and change the PF rule to remove the IP of servers that go down and later add it again. Just copy the behaviour IPFilter has. Described in the old ipnat(5) LOAD-BALANCING Two options for use with rdr are available to support primitive, round-robin based load balancing. The first option allows for a rdr to specify a second destination, as follows: rdr le0 203.1.2.3/32 port 80 -> 203.1.2.3,203.1.2.4 port 80 tcp This would send alternate connections to either 203.1.2.3 or 203.1.2.4. In scenarios where the load is being spread amongst a larger set of servers, you can use: rdr le0 203.1.2.3/32 port 80 -> 203.1.2.3,203.1.2.4 port 80 tcp round-robin rdr le0 203.1.2.3/32 port 80 -> 203.1.2.5 port 80 tcp round-robin In this case, a connection will be redirected to 203.1.2.3, then 203.1.2.4 and then 203.1.2.5 before going back to 203.1.2.3. In accomplishing this, the rule is removed from the top of the list and added to the end, automatically, as required. This will not effect the dis- play of rules using "ipnat -l", only the internal applica- tion order. Cheers, Dries -- Dries Schellekens email: [EMAIL PROTECTED]
Re: Load balancing/failover
Making, drinking tea and reading an opus magnum from Alejandro G. Belluscio:
> Daniel,
> I've just subscribed, but on Sat, 10 Aug 2002 23:11:41 +0200 you
> replyed to Loic Cuguen regarding the non existence of a roadmap with:
> > There are certainly some larger goals that have not been achieved yet,
> > like redundancy/failover, load balancing, proxies for further
> > protocols, altq integration, etc.
> I've always thought about the failover/load balancing by making an
> extension to rdr, something like
>
> rdr-load on #if inet proto tcp from any to #ExtIf port www -> \
> {#Ip1 port www, #Ip2 port www, #Ip3 port www} \
> [balance-weight {4, 5, 9} #idnum | balance-round-robin #idnum]
>
>For this to work you'd need to keep state on the tcp connection and
> do something sane on udp. So when a Syn packet comes to the rdr-load
> address/port, you evaluate the balance algorithm (in this case I
> proposed round robin and some fix weight) decide some of the given IPs
> and so you make a rdr to that IP. I haven't taken a look at the pf code
> (not that I'm good enough to understand it) but I though this wouldn't
> kill performance (may be double the lookup time for the rdr packets) and
> shouldn't be too invasive. I've given #idnum so you could eventually
> change the weight or add/takeout IP from the pool for a given rule.
> A second option would be to create a pseudo device that does the
> balancing, and have a whole syntax just for that, but then we would be
> duplicating information and processing time.
> I haven't evaluated how would this interact with the route-from
> extension (if it's going to be merged :-) but any of the two alternative
> shouldn't be incompatible.
> This is just a proposal, if has been discused before, apologies. If
> you find it stupid or uninformed just tell me where can I get more info
> to make better proposals.
ah, uh, my eyes.
this is an ugly hack that violates the whole concept of the networking.
we've discussed this w/ daniel a few times already.
there are a few different approaches here.
one might be to use a vrrp and a state sync between two pf boxens.
the other, in case there are two uplinks from one pf box
is to teach the networking stack about multiple routes to the same
destination and make it do the ballancing or whatever.
both this cases are doable and allow a whole bunch of other usefull
things to be implemented beyond one "useful" pf hack.
i find route-from a very bad idea myself.
cu
--
paranoic mickey (my employers have changed but, the name has remained)
Re: Load balancing/failover
On Wed, Oct 02, 2002 at 12:15:26PM -0300, Alejandro G. Belluscio wrote:
> rdr-load on #if inet proto tcp from any to #ExtIf port www -> \
> {#Ip1 port www, #Ip2 port www, #Ip3 port www} \
> [balance-weight {4, 5, 9} #idnum | balance-round-robin #idnum]
Yes, that makes sense, and Ryan McBride is actually working on doing
something like that. There are a couple of questions still, though. If
we allow free lists like { #Ip1, #Ip2, ... }, we have to find a way to
store them in kernel and pass them through ioctls. Considering that the
list may be large, that can be non-trivial (also adding or removing
addresses from this list without removing the entire rule).
Another point is how this deals with #Ip1 going down. Should any part of
pf (in kernel?) monitor (or even probe) the targets and modify the list
automatically? Or would you want a userland daemon to do that? Or do it
manually completely?
Daniel
Load balancing/failover
Daniel,
I've just subscribed, but on Sat, 10 Aug 2002 23:11:41 +0200 you
replyed to Loic Cuguen regarding the non existence of a roadmap with:
> There are certainly some larger goals that have not been achieved yet,
> like redundancy/failover, load balancing, proxies for further
> protocols, altq integration, etc.
I've always thought about the failover/load balancing by making an
extension to rdr, something like
rdr-load on #if inet proto tcp from any to #ExtIf port www -> \
{#Ip1 port www, #Ip2 port www, #Ip3 port www} \
[balance-weight {4, 5, 9} #idnum | balance-round-robin #idnum]
For this to work you'd need to keep state on the tcp connection and
do something sane on udp. So when a Syn packet comes to the rdr-load
address/port, you evaluate the balance algorithm (in this case I
proposed round robin and some fix weight) decide some of the given IPs
and so you make a rdr to that IP. I haven't taken a look at the pf code
(not that I'm good enough to understand it) but I though this wouldn't
kill performance (may be double the lookup time for the rdr packets) and
shouldn't be too invasive. I've given #idnum so you could eventually
change the weight or add/takeout IP from the pool for a given rule.
A second option would be to create a pseudo device that does the
balancing, and have a whole syntax just for that, but then we would be
duplicating information and processing time.
I haven't evaluated how would this interact with the route-from
extension (if it's going to be merged :-) but any of the two alternative
shouldn't be incompatible.
This is just a proposal, if has been discused before, apologies. If
you find it stupid or uninformed just tell me where can I get more info
to make better proposals.
Regards,
Alejandro Belluscio
Re: Is it possible to apply 'route-to' rules to redirected packets?
On Wed, Oct 02, 2002 at 04:40:45PM +0200, Dries Schellekens wrote: > Bwa, it's in german. BTW what the heck is "schlammcatchen"? ;-) Mudwrestling. I spent the last three weeks in military service. Cold, wet, mandatory, annoying. Don't ask. :)
Re: Is it possible to apply 'route-to' rules to redirected packets?
On Wed, Oct 02, 2002 at 04:36:25PM +0200, Henning Brauer wrote: > I hate reply-to: to the list address. Removed. On the other hand, I prefer replies that are of non-personal nature and might be of general interest being sent to the list, otherwise FAQs well never get archived and picked up by google. But the choice is yours, reply-to: was meant as a hint, not a trap :) Daniel
Re: Is it possible to apply 'route-to' rules to redirected packets?
On Wed, Oct 02, 2002 at 04:40:45PM +0200, Dries Schellekens wrote: > On Wed, 2 Oct 2002, Henning Brauer wrote: > > > sorry. > > > > I hate reply-to: to the list address. > > Bwa, it's in german. BTW what the heck is "schlammcatchen"? ;-) some things better don't get translated ;-)
Re: Is it possible to apply 'route-to' rules to redirected packets?
On Wed, 2 Oct 2002, Henning Brauer wrote: > sorry. > > I hate reply-to: to the list address. Bwa, it's in german. BTW what the heck is "schlammcatchen"? ;-) Dries -- Dries Schellekens email: [EMAIL PROTECTED]
Re: Is it possible to apply 'route-to' rules to redirected packets?
sorry. I hate reply-to: to the list address.
Re: Is it possible to apply 'route-to' rules to redirected packets?
On Wed, Oct 02, 2002 at 04:29:19PM +0200, Daniel Hartmeier wrote: > On Wed, Oct 02, 2002 at 03:37:55PM +0200, Clemens Dumat wrote: > > > I'm not into the normal development-cycle of openbsd, so my question may be > > stupid: will these patches make it into the normal cvs-tree, and if so, will > > they be in time for 3.2-stable? > > The source tree is already locked for the 3.2 release, so it won't make > it into 3.2. I'll update the patch so it applies cleanly to 3.2-release > and -stable, so it will be easy to test. > > Whether it makes it into 3.2-current depends on further testing and how > generally useful the other developers think this is. I never know in > advance :) ich hab irgendwie nicht geschnallt wozu das gut ist ;-) wie war das schlammcatchen? ;-)
Re: Is it possible to apply 'route-to' rules to redirected packets?
On Wed, Oct 02, 2002 at 03:37:55PM +0200, Clemens Dumat wrote: > I'm not into the normal development-cycle of openbsd, so my question may be > stupid: will these patches make it into the normal cvs-tree, and if so, will > they be in time for 3.2-stable? The source tree is already locked for the 3.2 release, so it won't make it into 3.2. I'll update the patch so it applies cleanly to 3.2-release and -stable, so it will be easy to test. Whether it makes it into 3.2-current depends on further testing and how generally useful the other developers think this is. I never know in advance :) Thanks for the feedback, Daniel
Re: Is it possible to apply 'route-to' rules to redirected packets?
(I sent this mail already 2 weeks ago, but it looks as if it was lost in ADSL-Nirvana :) ) Zitiere Daniel Hartmeier <[EMAIL PROTECTED]>: > On Mon, Sep 02, 2002 at 04:10:45PM +0200, Clemens Dumat wrote: > > > Great :) And as i said, i'm willing to help (if i can be of any help), > > if route-reply-to is to be implemented. > > Well, you can help test it :) It took me some days to set up a current-system to apply the patches against, but now the system runs smoothly for some days (aktually weeks by now :) with two 'reply-to' rules for now (this will definitely grow :) ). Thanks a lot! I'm not into the normal development-cycle of openbsd, so my question may be stupid: will these patches make it into the normal cvs-tree, and if so, will they be in time for 3.2-stable? Clemens
