Hello,
</snip>
> >
> > it seems to me 'route-to vs. pfsync' still needs more thought. the
> > next-hop IP address in route-to may be different for each PF box
> > linked by pfsync(4). To be honest I have no answer to address this
> > issue at the moment.
>
> i have thought about that a little bit. we could play with what the
> argument to route-to means. rather than requiring it to be a directly
> connected host/gateway address, we could interpret it as a destination
> address, and use the gateway for that destination as the nexthop.
>
> eg, if i have the following routing table on frontend a:
>
> Internet:
> Destination Gateway Flags Refs Use Mtu Prio Iface
> default 192.168.96.33 UGS 6 176171 - 8 vmx0
> 224/4 127.0.0.1 URS 0 0 32768 8 lo0
> 10.0.0.0/30 192.168.0.1 UGS 0 0 - 8 gre0
</snip>
>
> and this routing table on frontend b:
>
> Internet:
> Destination Gateway Flags Refs Use Mtu Prio Iface
> default 192.168.96.33 UGS 9 87548 - 8 aggr0
> 224/4 127.0.0.1 URS 0 0 32768 8 lo0
> 10.0.0.0/30 192.168.0.3 UGS 0 0 - 8 gre0
</snip>
>
> if gre0 on both frontends pointed at different legs on the same backend
> server, i could write a pf rule like this:
>
> pass out to port 80 route-to 10.0.0.1
>
> 10.0.0.1 would then end up as the rt_addr field in pf_state and
> pfsync_state.
>
> both frontend a and b would lookup the route to 10.0.0.1, and then
> use 192.168.0.1 and 192.168.0.3 as the gateway address respectively.
> both would end up pushing the packet over their gre link to the
> same backend. the same semantic would work if the link to the backend
> was over ethernet instead of a tunnel.
>
> > > thoughts?
> > >
> >
> > What you've said makes sense. However I still feel pfsync(4)
> > does not play well with route-to.
>
> maybe your opinion is different if the above makes sense?
>
Thanks for detailed explanation. This is good enough to make me happy.
The remaining questions on this are sort of 'homework for me' to poke
to PF source code, for example:
are we doing route look up for every packet? or route look up
is performed when state is created/imported? (and we cache
outbound interface + next-hop along the state)
also what happens when route does not exist on pfsync peer, which
receives state? How admin will discover state failed to import?
Anyway, your plan above looks solid to me now. It's certainly more flexible
(?reliable?) to select route to particular destination, than using pair of
interface,next-hop.
thanks and
regards
sashan
