Routing HTTP header injection for Maglev loadbalancing use? Easy active/hot-standby service

TLDR: Can the new HTTP header injection feature in Consul 1.11.0 beta be used by the Connect Maglev load balancing routing algorithm which consumes an HTTP header for deterministic routing? This would make for an easy active / hot-standby service set up.

It doesn’t seem like it based on the testing I’ve done so far, but would be nice if it could.

Some details on the use case I’m looking at:

  • I’m looking at using maglev load balancing algorithm to a connect service for consistent load balance hashing. Ideally, I’d like this connect service to act as a active/hot-standby cluster, so that n instances are available, but only 1 is consistently routed to at any given time as long as it stays healthy. I can do this with with maglev load balancing using an HTTP header that is constant – then all requests are routed to that instance. For this, the requesting app must ensure the appropriate maglev static HTTP header is added.

  • I see that in consul 1.11.0-beta3 HTTPHeaderModifiers for request and response headers has been added, which is a great feature. Ideally, I’d like to configure the static header that maglev would consume for consistent hashing in a service-resolver config kind by setting up a “RequestHeader” “Set” to inject that static header in a service-router config kind.

That way, service consuming apps don’t have to worry about setting a header, and if already improperly set, the header would be properly overwritten to maintain the desired active/hot-standby service routing.

  • I can use header injection to see maglev properly working by adding a response header with a value of envoy’s %UPSTREAM_REMOTE_ADDRESS% when I manually add a static maglev hashing header, for example, with curl.

  • However, if I add that same static maglev hashing header in a service-router config kind which should occur earlier in the consul traffic management than a service-resolver evaluation (routing → splitting → resolution), maglev consistent hashing doesn’t work. I’ve checked by tcpdump in the upstream service environment and do see that the maglev static hashing header was properly injected. It just seems like maglev doesn’t recognize it when it’s injected by the routing HTTPHeaderModifiers instead of manual header addition from the calling app.

  • The service I’m using is a subset, so maybe if I simplify a bit or try a few other things I can get it to work… But before I dump more time into playing around with it, wanted to check if HTTPHeaderModifier injection for maglev hashing consumption is even possible. Anyone know?



Hi @johnalotoski,

This sounds like an interesting use case. Off the top of my head I am not sure why this isn’t working.

Would it be too much trouble to ask you to provide some configuration/steps to reproduce your test environment so that we can investigate this further?


Hi Blake, sure, although it may take awhile, I’m a bit swamped at the moment.

I opened a ticket for this feature request here:
Easy active/hot-standby connect service clusters with maglev and header injection · Issue #11698 · hashicorp/consul · GitHub.

I’ll post more when I can get a bit unburied.