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 somewhere. 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. -- jared [ openbsd 3.9-current GENERIC ( mar 15 ) // i386 ]
