Re[2]: OpenBGPD && PF

[Sylwester S. Biernacki]

On Thursday, January 5, 2006, at 01:15:00, jared r r spiegel wrote:

>   one - if you are reloading pf ( pfctl -f /etc/pf.conf ), that will 
>         clear the table; but that's probably not your issue.
yeah, that's normal issue and that feature works as it should ;-)

>   two - if you have two peers, A and B, and both of them write to the
>         same pf table <IX>, i believe the following scenario is true:

> - 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 my bgpd.conf there is in that way - I use the same table to match
all prefixes which are gathered through IX peerings. In both cases
above no prefixes shouldn't deleted from pftable <IX>

> - 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 use a unique pftable per BGP peer ( and then just reference
>   each table in my pf rules in { braces } ) to avoid that
well... who knows the limit of rules in { braces } ? If you peer in IX
where you have ~50 peerings that's not a hard work to do it, but what
about 150 peerings (without route-servers) or more ?

>   could be this is fixed already and one of my peers is an old version?
>   ( 3.8 stable; 3.8 current dec.16; 3.8 current from oct.2 )
I've already checked that and it seems to have this behaviour on all
peerings, no matter if there is Cisco IOS, JunOS, Quagga or OpenBGPD,
so that's not that case.

-- 
Sylwester S. Biernacki <[EMAIL PROTECTED]>
X-NET, http://www.xnet.com.pl/