Re: OpenBSD & OpenBGPD router replacement
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
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
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
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
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
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
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
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
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
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
