Re: OpenBSD & OpenBGPD router replacement

2018-12-18 Thread Max Clark
Tom,

The presentation was very interesting and it's given me a lot of food for
thought for another project. Fortunately for this application I don't need
to worry about fire walling at the BGP edge, just the router replacement
itself.

Max


On Tue, Dec 18, 2018 at 6:02 PM Tom Smyth 
wrote:

> Max,
>
> another thing to consider, is that with BGP feeds / Advertising
> you only have some control over which direction traffic enters / leaves
> the network, you may pefer one transit provider, but another network on the
> internet can prefer your second transit provider, so  you can have
> traffic that appears out of state...
>
> If you need stateful packet filtering  I would suggest stepping that
> protection
> back from your edge routers  ... disadvantage is you would need 4
> devices to do this
> but this would give you the redundancy you want from a Transit perspective
> and you would have the ability control  flow of traffic between your
> edge routers
> and your Stateful Firewalls
>
> Hope This Helps
>
> Tom Smyth
>
>
>
>
> On Wed, 19 Dec 2018 at 01:52, Max Clark  wrote:
> >
> > Thanks Arnaud - I understand that it's not a stateful protocol/failover.
> > It's interesting from the standpoint that if I lose a specific box acting
> > as a router I would recover and maintain the route via the affected
> > carrier. A few minutes of outage for carp and BGP to come up is better
> than
> > a prolonged outage until equipment is replaced.
> >
> > Max
> >
> >
> > On Tue, Dec 18, 2018 at 4:47 PM Arnaud BRAND 
> > wrote:
> >
> > > Hi Max,
> > >
> > > I would advise against using CARP for BGP peers.
> > > BGP is a stateful protocol and there's no bgpsyncd, so I don't think
> > > this
> > > will work.
> > >
> > > I would rather build two servers, and have 2 BGP sessions/fullfeeds,
> > > each
> > > on one 10G link in order to provide redundancy.
> > >
> > > Best regards
> > > Arnaud
> > >
> > > Le 2018-12-19 00:17, Max Clark a écrit :
> > > > Hello,
> > > >
> > > > I've been presented with an opportunity to greatly simplify upstream
> > > > networking within a datacenter. At this point I'm expecting to
> condense
> > > > down to two 10 Gbps full feed IPv4+IPv6 transit links plus a 10 Gbps
> > > > link
> > > > to the peering fabric. Total 95th percentile transit averages in the
> > > > 3-4
> > > > Gbps range with bursts into the 6-7 Gbps (outside of the rare DDoS
> then
> > > > everything just catches on fire until provider mitigation kicks in).
> > > >
> > > > With the exception of the full tables it's a pretty simple
> requirement.
> > > > There's plenty of options to purchase a new TOR device(s) that could
> > > > take
> > > > the full tables, but I'd just rather not commit the budget for it.
> Plus
> > > > this feels like the perfect time to do what I've wanted for a while,
> > > > and
> > > > deploy an OpenBSD & OpenBGPD edge.
> > > >
> > > > I should probably ask first - am I crazy?
> > > >
> > > > With that out of the way I could either land the fiber directly into
> > > > NICs
> > > > on an appropriately sized server, or I was thinking about landing the
> > > > transit links on a 10 Gbps L2 switch and using CARP to provide server
> > > > redundancy on my side (so each transit link would be part of VLAN
> with
> > > > two
> > > > servers connected, primary server would advertise the /30 to the
> > > > carrier
> > > > with BGPD, and secondary server could take over with heartbeat
> > > > failure). I
> > > > would use two interfaces on the server - one facing the Internet and
> > > > one
> > > > facing our equipment.
> > > >
> > > > Would the access switch in this configuration be a bad idea? Should I
> > > > keep
> > > > things directly homed on the server?
> > > >
> > > > And my last question - are there any specific NICs that I should look
> > > > for
> > > > and/or avoid when building this?
> > > >
> > > > Thanks!
> > > > Max
> > >
>
>
>
> --
> Kindest regards,
> Tom Smyth
>
> Mobile: +353 87 6193172
> The information contained in this E-mail is intended only for the
> confidential use of the named recipient. If the reader of this message
> is not the intended recipient or the person responsible for
> delivering it to the recipient, you are hereby notified that you have
> received this communication in error and that any review,
> dissemination or copying of this communication is strictly prohibited.
> If you have received this in error, please notify the sender
> immediately by telephone at the number above and erase the message
> You are requested to carry out your own virus check before
> opening any attachment.
>


Re: OpenBSD & OpenBGPD router replacement

2018-12-18 Thread Max Clark
Thanks Arnaud - I understand that it's not a stateful protocol/failover.
It's interesting from the standpoint that if I lose a specific box acting
as a router I would recover and maintain the route via the affected
carrier. A few minutes of outage for carp and BGP to come up is better than
a prolonged outage until equipment is replaced.

Max


On Tue, Dec 18, 2018 at 4:47 PM Arnaud BRAND 
wrote:

> Hi Max,
>
> I would advise against using CARP for BGP peers.
> BGP is a stateful protocol and there's no bgpsyncd, so I don't think
> this
> will work.
>
> I would rather build two servers, and have 2 BGP sessions/fullfeeds,
> each
> on one 10G link in order to provide redundancy.
>
> Best regards
> Arnaud
>
> Le 2018-12-19 00:17, Max Clark a écrit :
> > Hello,
> >
> > I've been presented with an opportunity to greatly simplify upstream
> > networking within a datacenter. At this point I'm expecting to condense
> > down to two 10 Gbps full feed IPv4+IPv6 transit links plus a 10 Gbps
> > link
> > to the peering fabric. Total 95th percentile transit averages in the
> > 3-4
> > Gbps range with bursts into the 6-7 Gbps (outside of the rare DDoS then
> > everything just catches on fire until provider mitigation kicks in).
> >
> > With the exception of the full tables it's a pretty simple requirement.
> > There's plenty of options to purchase a new TOR device(s) that could
> > take
> > the full tables, but I'd just rather not commit the budget for it. Plus
> > this feels like the perfect time to do what I've wanted for a while,
> > and
> > deploy an OpenBSD & OpenBGPD edge.
> >
> > I should probably ask first - am I crazy?
> >
> > With that out of the way I could either land the fiber directly into
> > NICs
> > on an appropriately sized server, or I was thinking about landing the
> > transit links on a 10 Gbps L2 switch and using CARP to provide server
> > redundancy on my side (so each transit link would be part of VLAN with
> > two
> > servers connected, primary server would advertise the /30 to the
> > carrier
> > with BGPD, and secondary server could take over with heartbeat
> > failure). I
> > would use two interfaces on the server - one facing the Internet and
> > one
> > facing our equipment.
> >
> > Would the access switch in this configuration be a bad idea? Should I
> > keep
> > things directly homed on the server?
> >
> > And my last question - are there any specific NICs that I should look
> > for
> > and/or avoid when building this?
> >
> > Thanks!
> > Max
>


OpenBSD & OpenBGPD router replacement

2018-12-18 Thread Max Clark
Hello,

I've been presented with an opportunity to greatly simplify upstream
networking within a datacenter. At this point I'm expecting to condense
down to two 10 Gbps full feed IPv4+IPv6 transit links plus a 10 Gbps link
to the peering fabric. Total 95th percentile transit averages in the 3-4
Gbps range with bursts into the 6-7 Gbps (outside of the rare DDoS then
everything just catches on fire until provider mitigation kicks in).

With the exception of the full tables it's a pretty simple requirement.
There's plenty of options to purchase a new TOR device(s) that could take
the full tables, but I'd just rather not commit the budget for it. Plus
this feels like the perfect time to do what I've wanted for a while, and
deploy an OpenBSD & OpenBGPD edge.

I should probably ask first - am I crazy?

With that out of the way I could either land the fiber directly into NICs
on an appropriately sized server, or I was thinking about landing the
transit links on a 10 Gbps L2 switch and using CARP to provide server
redundancy on my side (so each transit link would be part of VLAN with two
servers connected, primary server would advertise the /30 to the carrier
with BGPD, and secondary server could take over with heartbeat failure). I
would use two interfaces on the server - one facing the Internet and one
facing our equipment.

Would the access switch in this configuration be a bad idea? Should I keep
things directly homed on the server?

And my last question - are there any specific NICs that I should look for
and/or avoid when building this?

Thanks!
Max


Re: bgplgsh via telnet

2010-11-15 Thread Max Clark
Andy,

This is perfect thank you - I'm ended up using the following in the
daemontools supervise script:

#!/bin/sh
exec 21
exec envuidgid rviews tcpserver -vDRHl0 0 23 ptyrun /usr/bin/bgplgsh

Two more questions for you:

- is it possible to set a timeout on the tcpserver/ptyrun/bgplgsh
program? I want the server to disconnect the remote user after 30
seconds of inactivity.

- tcpserver has a -B option to display a banner - this seems to need
to be inline with the tcpserver execution. Do you know of a way to
include an external file? Or even better is there a way to have
ptyrun/bgplgsh display the motd?

Thanks,
Max


On Sat, Nov 13, 2010 at 10:25 AM, Andy Bradford
amb-sendok-1292264743.jngnackkodflmlhjh...@bradfords.org wrote:
 Thus said Max Clark on Sat, 13 Nov 2010 07:54:00 PST:

 I've  experimented  with  tcpserver  from the  ucspi  package  without
 success. How  do I  give access  to the  bgplgsh application  only via
 telnet?

 Probably because  you are missing a  tty. If you also  install ptyget[1]
 you might be able to accomplish it with something like:

 tcpserver -v 0 1234 ptyrun /usr/bin/login -f -u bgplg bgplg

 or maybe:

 tcpserver -u `id -u bgplg` -g `id -g bgplg` -v 0 1234 ptyrun
/usr/bin/bgplgsh

 Andy

 [1] http://cr.yp.to/software/ptyget-0.50.tar.gz



bgplgsh via telnet

2010-11-13 Thread Max Clark
Hello,

I am creating a public route server for our network. bgplgsh is the
ideal utility for what I need however I need to expose access to this
app via telnet. Newer versions of OpenBSD do not have a telnet daemon,
I've experimented with tcpserver from the ucspi package without
success. How do I give access to the bgplgsh application only via
telnet?

Thanks in advance,
Max



bgpldsh questions

2010-11-11 Thread Max Clark
Hello,

- is it possible to add a motd to the bgplgsh?

- what's the sanest way to enable telnet access to the bgplgsh?

Thanks in advance,
Max



openbgpd and prefix filters

2010-09-03 Thread Max Clark

Hello all,

We currently build and manage our prefix lists from IRRd sources 
(RADB/ALTDB) using automated scripts on our Cisco routers. Can openbgpd 
query an IRRd directly? How do I regularly update the prefix lists for 
our peers?


Thanks,
Max



Re: openbgpd and prefix filters

2010-09-03 Thread Max Clark

On 9/3/10 12:30 PM, Stuart Henderson wrote:

bgpctl irrfilter might do what you need. it runs offline,
pulls RPSL and generates filter files that you can list as an
include in bgpd.conf. currently it is hardcoded to fetch
from RADB.

you may or may not need to modify your RPSL to work with it.

also if you expect large filter sets, investigate cpu and
memory use (especially at 'bgpctl reload' time) and make sure
you're ok with how it works.


Thank you - next time I'll read the latest man page on the openbsd.org 
first :)


I'll play around with this with some different scenarios to explore 
system utilization. While individual filters should be relatively small 
were are going to have lots of them.


Thanks,
Max



Building a Centralized Authentication Server

2007-06-03 Thread Max Clark
Hi all,

I need to develop a secure way for our staff/outside contractors to be able
to securely connect (via SSH - rdesktop/vnc in the future) to our internal
and customer systems. We do need heterogeneous client system support (BSD,
Linux, Solaris, Windows, etc..?) with whatever solution is deployed.

The more time I have spent with this the more I believe that we need some
sort of SSO (Single Sign On) solution (something that supports a hardware
key token like RSA would be great). This is complicated by the perceived
requirement to install software on our customer's systems to support this
kind of integration.

As a stop gap I have been thinking about creating a dedicated user account
on a centralized server, creating SSH keys and pushing the public key out to
the remote systems for passwordless logins. Internal users would connect to
this system, sudo to the other account and then SSH (with the added feature
of being able to execute script and log the session).

The goal behind all of this of course is to provide secure connectivity to
remote systems in such a way that passwords to the remote systems are not
being disseminated to our internal users - so if a user's employment status
changes we don't have to run through the crazy password change scramble.

I pose this question to this list because of all places on the Internet I
know OpenBSD users to be the most paranoid with security and simple/elegant
solutions which is exactly what I need here. Am I over thinking this
problem? What would you recommend.

Thanks in advance,
Max



Re: Building a Centralized Authentication Server

2007-06-03 Thread Max Clark
On 6/3/07, Jeroen Massar [EMAIL PROTECTED] wrote:


 And then the evil user simply drops a backdoor binary on one of the
 machines.


Sure there is only so much you can do. We have to give some level of trust
to the user, this of course has to be balanced by an appropriate level of
prudence on our part. I am just looking for a solution for the 95-99% of the
users - that last 1-5% has to be dealt with in a different manner (i.e. the
FBI if they are that stupid).

-Max