Hello!
On Thu, Jan 17, 2008 at 02:38:56PM +0000, Stuart Henderson wrote:
> > It isn't my way because actually I have two 'default route' sources: eBGP
> > and iBGP. If eBGP 'default route' fails I'll use iBGP information.
> > I can't override them with one static route because I'll lose
> > redundancy if main uplink fails.
> Ah, so you don't receive a full table by ibgp when your ebgp peer
> is down? (if you do, there's no problem, as the more-specifics would
> override the static default).
No, I don't. I receive just default routes. I think that using of
fullview to solve routes priority problem - it's a little bit overkill.
> > I decided to went another way and configure 'reply-to' feature of pf:
> It's my understanding (and a 5-second test seems to bear this out)
> that you still need a route in the routing-table matching the destination
> otherwise things won't get far enough up the stack to reach PF.
Here is a part of pf.conf(5):
reply-to
The reply-to option is similar to route-to, but routes packets that
pass in the opposite direction (replies) to the specified inter-
face. Opposite direction is only defined in the context of a state
entry, and reply-to is useful only in rules that create state. It
can be used on systems with multiple external connections to route
all outgoing packets of a connection through the interface the in-
coming connection arrived through (symmetric routing enforcement).
So, my understanding is: i have a directly connected gateway and no
default route in my routing table,
when incoming packet comes through external interface the new state is
created and all outgoing traffic for this session should flow to
'reply-to' gateway even if there is no 'default route' entry in my main
routing table.
So this option should work for incoming sessions. Maybe I'm wrong.
--
WBR,
Alexander Burnos
