|
my homie dhall posted:yeah, what I'd like to have is a proxy/VIP service that lives across multiple nodes and have traffic be able to land on any of them and get forwarded to correct service. This sounds like the text-book problem that consistent hashing was created to solve. Old way, you have 4 buckets that ECMP hash into. If one bucket dies, all existing flows are re-hashed for 3 buckets, net result? <33% of your flows will end up at the same place, so almost all of your TCP sessions will need to be reestablished. With consistent hashing (supported by Juniper and Arista, and Cisco, and Quagga/Bird/Exabgp and I'm sure others) if one bucket dies, only those flows (25%) are interrupted. Your network team should be able to enable this feature assuming they are using enterprise gear. Yes it needs to be enabled everywhere, but I'd be surprised if it weren't already enabled by default in most places. You will also need to run BGP on your LBs as well. And this is probably something the network team is a bit more nervous about given how touchy business can be about service outages.
|
#
?
May 13, 2021 01:37
|
|
|
|
| # ? May 19, 2024 18:25 |
|
|
yah chash is cool as hell
|
|
#
?
May 13, 2021 02:01
|
|
|
network engineers: ecmp the hash buckets on your bgp interface so the l3 anycast will route under all circumstances me, an aws networking expert: how is connetcion formed. how paket get delievered
|
|
#
?
May 13, 2021 03:07
|
|
|
Nomnom Cookie posted:network engineers: ecmp the hash buckets on your bgp interface so the l3 anycast will route under all circumstances i think they have a managed service for that
|
|
#
?
May 13, 2021 05:13
|
|
|
Nomnom Cookie posted:network engineers: ecmp the hash buckets on your bgp interface so the l3 anycast will route under all circumstances
|
|
#
?
May 13, 2021 11:37
|
|
|
Nomnom Cookie posted:network engineers: ecmp the hash buckets on your bgp interface so the l3 anycast will route under all circumstances
|
|
#
?
May 13, 2021 12:45
|
|
|
SamDabbers posted:What kind of service are you running on those VIPs? This is probably better accomplished at the application layer to direct traffic to different IPs rather than this "anycast TCP" at the network layer. Your network peeps are correct to the motivation is not for any specific application, but for building something like ELB on-prem, so you have some pool of servers holding a bunch of VIPs fronting the backends of various teams who need load balancing. you definitely need VIPs, but it'd also be nice if a node failing over breaking all existing connections wasn't a thing, which it would be without some kind of connection state sharing. the fact that you don't need consistent hashing in the network if you solve this problem is just a bonus I guess but given the reaction from everyone here perhaps asking for chashing + tolerating mass connection death might be a more rational way to go
|
|
#
?
May 13, 2021 13:18
|
|
|
Bored Online posted:i think they have a managed service for that “a” managed service, you are clearly not an aws networking expert. there are so, so many ways to give aws money and if you really try I’m pretty sure it’s possible to get charged a dozen times for the same packet
|
|
#
?
May 13, 2021 14:13
|
|
|
my homie dhall posted:but given the reaction from everyone here perhaps asking for chashing + tolerating mass connection death might be a more rational way to go https://en.m.wikipedia.org/wiki/Fallacies_of_distributed_computing See #1
|
|
#
?
May 13, 2021 21:44
|
|
|
so i'm kind of out of my depth on this, but what you were talking about kinda reminded me of google's maglev system: https://storage.googleapis.com/pub-tools-public-publication-data/pdf/44824.pdf
|
|
#
?
May 14, 2021 02:36
|
|
|
cheque_some posted:so i'm kind of out of my depth on this, but what you were talking about kinda reminded me of google's maglev system: https://storage.googleapis.com/pub-tools-public-publication-data/pdf/44824.pdf yeah maglev is one implementation, the others that I know about are katran and glb director. I was hoping there might be a more accessible thing to play around with
|
|
#
?
May 14, 2021 13:34
|
|
|
my homie dhall posted:yeah maglev is one implementation, the others that I know about are katran and glb director. I was hoping there might be a more accessible thing to play around with Check out XDP/Cilium https://cilium.io/blog/2020/06/22/cilium-18
|
|
#
?
May 15, 2021 06:18
|
|
|
my homie dhall posted:yeah maglev is one implementation, the others that I know about are katran and glb director. I was hoping there might be a more accessible thing to play around with maybe it’s better to just use google cloud load balancers (and having some type of hybrid direct connection to google cloud to keep the rest of your poo poo on your own metal) instead of trying to reinvent a janky clone of it
|
|
#
?
May 15, 2021 21:39
|
|
|
You will never accomplish your goal of having TCP connections not die when a node fails and I'm pretty sure your use case is trivially accomplished with GSLB
|
|
#
?
May 16, 2021 09:04
|
|
|
i was going to jump on oVirt for an open source HCI for our next POP but apparently red hat is going to focus on openstack in future instead of this. anyone have any opinions about hypervisors and sans for me to look at? ideally open source with paid support
|
|
#
?
May 21, 2021 10:54
|
|
|
abigserve posted:You will never accomplish your goal of having TCP connections not die when a node fails and I'm pretty sure your use case is trivially accomplished with GSLB so which nodes are we talking about here? intermediate loadbalancers, the destination nodes, or something else? i'm hoping its obvious that without serious effort you're not migrating a tcp connect connection from destination A to destination B, but you can build a system that manages stateful l4 routing decisions that is tolerant of node loss.
|
|
#
?
May 22, 2021 03:04
|
|
|
finally moved all our remaining bgp off our ancient 6500 platforms this week. the poor old dears have been screaming about the size of the bgp table for ages now
|
|
#
?
Jun 3, 2021 10:26
|
|
|
my stepdads beer posted:finally moved all our remaining bgp off our ancient 6500 platforms this week. the poor old dears have been screaming about the size of the bgp table for ages now whatdya move to
|
|
#
?
Jun 3, 2021 10:29
|
|
|
lots of mx204s. they are great so far. much prefer working with lots of little routers instead of a few big ones tbh
|
|
#
?
Jun 3, 2021 10:33
|
|
|
hey im routin over heah
|
|
#
?
Jun 3, 2021 10:35
|
|
|
im layer3 switching
|
|
#
?
Jun 3, 2021 10:37
|
|
|
my stepdads beer posted:lots of mx204s. they are great so far. much prefer working with lots of little routers instead of a few big ones tbh juniper rules and cisco drools
|
|
#
?
Jun 3, 2021 10:43
|
|
|
whats the plan for dealing with v6 bgp tables? is it just we'll figure it out when we get to it?
|
|
#
?
Jun 4, 2021 00:17
|
|
|
the v6 table is much smaller currently https://bgp.potaroo.net/v6/as2.0/index.html check out that curve though
|
|
#
?
Jun 4, 2021 01:30
|
|
|
aww! routers! I remember those.
|
|
#
?
Jun 4, 2021 02:05
|
|
|
Asymmetric POSTer posted:juniper rules and cisco drools juniper has much better price/perf and price/features ratios. cisco however has the old adage "nobody was ever fired for buying a cisco" and that’s why 90% of my employer’s enterprise networking business is still cisco juniper utterly wipes the floor with them in education and service provider though on account of the equivalent cisco boxes being four or five times the price and questionably functional. the 6800s were a mistake on the same scale as my posting
|
|
#
?
Jun 4, 2021 02:20
|
|
|
Kazinsal posted:"nobody was ever fired for buying a cisco" haha you would at Fastly! we dont use routers
|
|
#
?
Jun 4, 2021 02:26
|
|
|
Jonny 290 posted:haha you would at Fastly! we dont use routers I applaud your networking team for freeing themselves from the shackles of conventional hardware and embracing the software defined chaos and making it work
|
|
#
?
Jun 4, 2021 02:30
|
|
|
at least commodity hardware doesnt just run out of room for the v4 routing tables im looking at you brocade
|
|
#
?
Jun 4, 2021 02:33
|
|
|
Kazinsal posted:I applaud your networking team for freeing themselves from the shackles of conventional hardware and embracing the software defined chaos and making it work Yeah, it was a day 1 thing. our founder didn't want to gently caress with Cisco leases or purchases and all the attendant trappings so we just run all our transits and peering into Juniper switches, each cache machine gets a line to each switch, and we do all the BGP right on the boxes with bird. It lets us do some pretty wild poo poo and yeah, scales big
|
|
#
?
Jun 4, 2021 02:35
|
|
|
Jonny 290 posted:aww! routers! I remember those. things are going to get interesting when pci 5 is available. pci 3/4 isn't fast enough yet
|
|
#
?
Jun 4, 2021 03:22
|
|
|
Jonny 290 posted:Yeah, it was a day 1 thing. our founder didn't want to gently caress with Cisco leases or purchases and all the attendant trappings so we just run all our transits and peering into Juniper switches, each cache machine gets a line to each switch, and we do all the BGP right on the boxes with bird. It lets us do some pretty wild poo poo and yeah, scales big https://forums.somethingawful.com/showthread.php?threadid=3932301
|
|
#
?
Jun 4, 2021 03:44
|
|
|
Jonny 290 posted:Yeah, it was a day 1 thing. our founder didn't want to gently caress with Cisco leases or purchases and all the attendant trappings so we just run all our transits and peering into Juniper switches, each cache machine gets a line to each switch, and we do all the BGP right on the boxes with bird. It lets us do some pretty wild poo poo and yeah, scales big I remember reading cloud flare was big on this too
|
|
#
?
Jun 4, 2021 04:01
|
|
|
i have unifi install =D 5 aps.... hundreds of clients... wow!
|
|
#
?
Jun 4, 2021 07:01
|
|
|
Kazinsal posted:juniper has much better price/perf and price/features ratios. cisco however has the old adage "nobody was ever fired for buying a cisco" and that’s why 90% of my employer’s enterprise networking business is still cisco also junos is good and ios is really really bad
|
|
#
?
Jun 4, 2021 07:57
|
|
|
Jonny 290 posted:Yeah, it was a day 1 thing. our founder didn't want to gently caress with Cisco leases or purchases and all the attendant trappings so we just run all our transits and peering into Juniper switches, each cache machine gets a line to each switch, and we do all the BGP right on the boxes with bird. It lets us do some pretty wild poo poo and yeah, scales big 
|
|
#
?
Jun 4, 2021 07:57
|
|
|
You should be writing your own network OS, pleb.
|
|
#
?
Jun 4, 2021 14:08
|
|
|
The 6500 was the last good platform cisco ever made, along with the tank of the closet - the 3750G Had one of those bad boys running at Darwin in a literal workshop for 5 years, went up to replace it and found the thing covered in dust, like it was literally brown. Still worked. The 6800 would have sunk any other company it was that bad
|
|
#
?
Jun 5, 2021 11:37
|
|
|
Jonny 290 posted:Yeah, it was a day 1 thing. our founder didn't want to gently caress with Cisco leases or purchases and all the attendant trappings so we just run all our transits and peering into Juniper switches, each cache machine gets a line to each switch, and we do all the BGP right on the boxes with bird. It lets us do some pretty wild poo poo and yeah, scales big One of the edu isps here does this as well
|
|
#
?
Jun 5, 2021 11:39
|
|
|
|
| # ? May 19, 2024 18:25 |
|
|
what was so bad about the 6800? just seems like a beefier 6500?
|
|
#
?
Jun 5, 2021 12:06
|
|