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.
> > 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 ?
might not make as big an impact as you could be thinking; as they
just expand to individual rules:
$ unset RULES
$ RULES="$RULES\ntable <first> persist { 1.2.3.4/30 }"
$ RULES="$RULES\ntable <second> persist { 2.2.3.1/32 }"
$ RULES="$RULES\npass on lo0 inet from { <first> <second> } to any"
$ echo $RULES | pfctl -nvf-
table <first> persist { 1.2.3.4/30 }
table <second> persist { 2.2.3.1 }
pass on lo0 inet from <first> to any
pass on lo0 inet from <second> to any
$
my first reaction is that anything you're going to run BGP/pf on
in a ~50-~150+ scenario isn't going to care about whether pf.conf
works out to be 20 lines or 20,000 ( well, maybe 20,000 you'd notice
a little effect :).
> > 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.
i was probably unclear; sorry about that. i don't believe the nature
of the BGP process i'm peering with has anything to do with the cause;
but rather that i see that behaviour across each of the hosts of those
different revisions, so they all use the 'unique bgp table' method.
--
jared
[ openbsd 3.8 GENERIC ( dec 16 ) // i386 ]
