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 <tom.sm...@wirelessconnect.eu> 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 <max.cl...@gmail.com> 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 <arnaud.brand--o...@tib.cc> > > 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. >
