Re: OpenBGPD PF

2006-04-05 Thread jared r r spiegel
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 ]


Re: OpenBGPD PF

2006-01-05 Thread jared r r spiegel
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 ]


Re: OpenBGPD PF

2006-01-05 Thread Claudio Jeker
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


Re: OpenBGPD PF

2006-01-04 Thread jared r r spiegel
On Wed, Jan 04, 2006 at 09:42:44PM +0100, Sylwester S. Biernacki wrote:
 
   What do you think about it? Any ideas what to look for?

  one - if you are reloading pf ( pfctl -f /etc/pf.conf ), that will 
clear the table; but that's probably not your issue.

  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.

- 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.

  i use a unique pftable per BGP peer ( and then just reference
  each table in my pf rules in { braces } ) to avoid that

  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 )

-- 

  jared

[ openbsd 3.8 GENERIC ( dec 16 ) // i386 ]