On Thu, Jan 05, 2006 at 06:46:54AM -0500, jared r r spiegel wrote:
> On Thu, Jan 05, 2006 at 03:18:22AM +0100, Sylwester S. Biernacki wrote:
> > On Thursday, January 5, 2006, at 01:15:00, jared r r spiegel wrote:
> > 
> > > - establish session with A and learn about 1.2.3.4/30; 1.2.3.4/30 is
> > >   written to pftable <IX>
> > > - establish session with B and learn about 1.2.3.4/30; 1.2.3.4/30 is
> > >   written to pftable <IX>, but it's already there, who cares; or maybe
> > >   it isn't written because it's already there
> > 
> > >   either way, pftable <IX> still has 1.2.3.4/30 in it.
> > In both cases
> > above no prefixes shouldn't deleted from pftable <IX>
> 
>   <nod>  was just additions up to that point
>  
> > > - A loses its route for 1.2.3.4/30 and thus you lose it out of the
> > > session.
> > >   with A, bgpd removes 1.2.3.4/30 from pftable <IX>
> > >   it's still valid via B, but it got removed when A lost it.
> > 
> > It may be - however command to remove prefix from pftable comes from
> > bgpd not pf, right ?
> 
>   i think so; pftable.c (bgpd) has ioctl functions that seem to be named
>   such that they imply they do just what i think they would <G>.
> 
>   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

and use something like in bgpd.conf

match from group IX set rtlabel IX


-- 
:wq Claudio

Reply via email to