On Thu, Jan 05, 2006 at 01:33:42PM +0059, Claudio Jeker wrote:
> On Thu, Jan 05, 2006 at 06:46:54AM -0500, jared r r spiegel wrote:
> > 
> >   bgpd has (should have?) enough info from its config
> >   to know if it should send an addr_remove (i think this is the one)
> >   to pf based upon what addr it is thinking about removing, what table
> >   it is removing it from, and whether another peer who writes to that table
> >   has already put that addr in the same pftable - but the actual behaviour
> >   might be hard to get Just Right. 
> > 
> The main problem with the using one pftable over mutliple sessions is that
> bgpd does not track what is added or removed. The idea is to dump all
> prefixes of a neighbor into one table. In the end the pf table and the
> routes of that neighbor are in sync. If you are using multiple neighbors
> as source for a table it is easy to get out of sync.
> What I'm wondering is why to use a pftable in that case. It is far easier
> to use a route label and let pf decide on the route label.
> The route label tracks the current active routes and so never gets out of
> sync.
> Instead of
> pass in from <IX> ...
> you can use
> pass in from route IX

  btw, this works like a dream lately.

  we *do* get messages to ring buffer of:

invalid address type: 4

  whenever pf parses one of the route rules in pf.conf (one host is 3.8 stable,
  one is 3.9-current from mar.19).  that isn't causing issues for us
  and i am thinking it might be my fault for not having a nuance right

  primarily my purpose in replying to this thread is to say that for
  anyone using pftables in pf/bgpd like i was using them, switch to route
  labels.  it makes your life easier.



[ openbsd 3.9-current GENERIC ( mar 15 ) // i386 ]

Reply via email to