Hello to everyone in the list,
I run small ISP. Currently I use Debian + Quagga Box for my BGP sessions.
It is a single box with tow full feeds (approximately 200K prefixes) 
from tow ISPs and tow sessions from the same ISPs with local prefixes 
(approximately 2,5K prefixes). The same box is doing traffic shaping, 
firewall and so on for DMZ and clients. The clients are only connected 
by Metro Ethernet links.
If I do not describe the current situation well please let me know, I 
will give more details.
I plan to change this setup with OpenBSD + OpenBGP boxes, one for each 
ISP with IBGP between them and third box for firewall and client 
connections, possibly the third box would be duplicated by another box 
with CARP. I am looking for the best redundancy I could get.
However I may be wrong in my plan...
As I am absolute beginner with OpenBSD I would be very happy for any 
ideas, advises or practical examples.
Thank you very much,
Ivo

Hi all,
Thanks for the replays.
I have my test setup running and for now I am very impressed by OpenBGP 
      performance.
I have some additional questions.
I use route-maps in my quagga setup, but i do not see this options in 
OpenBGP. How can I achieve something similar to this route-map for example:

 From quagga:

neighbor x.x.x.x route-map isp-bg-in in
neighbor x.x.x.x route-map isp-bg-out out
!
route-map isp-bg-in permit 10
  match as-path 55
  set local-preference 500
!
!Here I have list of AS numbers like:
! ip as-path access-list 55 permit _xxx_
!I prefer to send outgoing traffic through this neighbor to AS# in the 
!list.
!
route-map isp-bg-in permit 20
  set local-preference 300
!
!Here if there is no match it sets local preference the same as the 
!other ISP
!
route-map neterra-bg-out permit 10
  match ip address 15
  set as-path prepend MYAS MYAS MYAS MYAS MYAS
!
!Here I perpend my AS for some of my networks to this neighbor.
!
route-map neterra-bg-out permit 20
  match ip address 25
!
!Here I do not put perpend to the rest of my networks.

I have similar route-maps on my other neighbor with opposite meaning in 
order to achieve some load sharing.

Thank you very much.
Ivo

not having the route-map desaster was a design goal.

look at the filter language, it can do all you want.
there's a section about it in bgpd.conf(5) (yeah, opoosed to &(%$@, we 
have docs).

-- 
Henning Brauer, hb@bsws.de, henning@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

I do not argue, you have nice docs. But the syntax it is completely new 
for me so from time to time I am lost. I am sorry for wasting your time 
with stupid questions.
Thanks,
Ivo

If you are new to OpenBSD and OpenBGP then I would-

a) setup a test box not in your production path
b) request your providers set up second peer sessions each, with each
'second session' going to the test box
c) get comfy with OpenBSD and OpenBGP with those two full tables from
your peers, just like you will in future production.

d) throw a second test box in the mix, migrate one of the 'second
sessions' to that box.
e) mess around with CARP on the inside connections of these boxes to
your LAN

The nice thing about this path is the flexibility and non-intrusion into
your current production network while you get over your own learning
curve.

One possibility on your topology- consider a front-end router to each
provider (can be whatever type) and then put your two OBGPD boxes behind
them in a CARP setup and have your providers multihop their sessions to
that CARP address... now you can have BGP redundancy! Then continue
CARPing on the back end... now you have no single point of failure (in
that part of the topology.)

We've been testing that very setup (and actually placing the two OBGPD
route servers in two separate locations connected by Metro Ethernet) and
it has worked in testing flawlessly. We actually let the edge routers
peer (via IBGP obviously) with the CARP BGP address for next hop
forwarding (some of our edge routers have more than one upstream
connection)... each edge router gets one table from one inside peer,
making it's configuration/maintenance much simpler. You just make the
BGP config changes on the OBGPD box, and you don't have to change
anything in the edge routers...

Anyone else doing this or something similar?

Danno

Danno.appliedi.net/drupal/

-----Original Message-----
From: owner-misc@openbsd.org [mailto:owner-misc@openbsd.org] On Behalf
Of OpenBSD@BG1
Sent: Friday, March 02, 2007 3:16 AM
To: OpenBSD misc
Subject: Migrate to OpenBSD + OpenBGP

Hello to everyone in the list,
I run small ISP. Currently I use Debian + Quagga Box for my BGP
...
[ message continues ]

Hello,

actualy I'm using some Cisco equipment and one OpenBGPd Box to connect
the eBGP-Upstreams to my network. I want to replace this setup in the
next couple of month by two OpenBSD boxes. I planned to do it this way:

I want to connect some eBGP session to both boxes and an direct iBGP
link between the two servers. That's it on the world's side. To my
LAN-side I want to use vlans and above on them I want to run Carp for
failover. The internal routes to the VLANs I want do redistribute via
OSPF between the two boxes. This works fine apart of one bug in the
ospf-daemon when the carp-state changes and the local routes have to be
updated. But I'm confident that this will be fixed soon.

When this setup works fine and is tested well, I will configure pf in
combination with pfsync on the two boxes. For pfsync I want to user the
direct link, which runs iBGP und OSPF too.

I hope my thoughts will show you one possible setup. If there are better
and more gentle scenario to do the job, I would be glad if we can
discuss it here. I'm still learning :)

Regards

Falk

from http://archives.neohapsis.com/archives/openbsd/2007-02/1155.html,
it doesn't look like you are listing the carp interface in ospfd.conf,
but you use 'redistribute connected' instead.

I'm not sure ospfd knows to track carp status in that case; my
preference would be to lose the redist connected and explicitly list
the interfaces you want announced. 'interface carpXX { passive }'
worked nicely for me last time I tested the failover.

well, optimally, you have your two outside OpenBGPD boxes speak to both 
your upstreams each, and just use carp on the insider interface.

-- 
Henning Brauer, hb@bsws.de, henning@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam