specified Socket Reverse NAT tables size %d must not exceed

Error message

specified Socket Reverse NAT tables size %d must not exceed maximum %d

What it means

After the lower-bound check, NewConfig rejects a socket reverse NAT table size above option.LimitTableMax with this error (note the slightly different wording 'tables size'). BPF LRU hash maps have an upper bound the datapath relies on, so oversized values abort startup. Like its sibling check, it runs only once during NewConfig.

Source

Thrown at pkg/loadbalancer/config.go:441

	// Dynamically size the SockRevNat map if not set by the user.
	if cfg.LBSockRevNatEntries == 0 {
		getEntries := dcfg.GetDynamicSizeCalculator(log)
		cfg.LBSockRevNatEntries = getEntries(option.SockRevNATMapEntriesDefault, option.LimitTableAutoSockRevNatMin, option.LimitTableMax)
		log.Info("Option set by dynamic sizing",
			logfields.Option, LBSockRevNatEntriesName,
			logfields.Value, cfg.LBSockRevNatEntries,
		)
	}

	cfg.LBSockRevNatEntries = dcfg.AlignMapSizeForLRU(log, LBSockRevNatEntriesName, cfg.LBSockRevNatEntries)

	if cfg.LBSockRevNatEntries < option.LimitTableMin {
		return Config{}, fmt.Errorf("specified Socket Reverse NAT table size %d must be greater or equal to %d",
			cfg.LBSockRevNatEntries, option.LimitTableMin)
	}
	if cfg.LBSockRevNatEntries > option.LimitTableMax {
		return Config{}, fmt.Errorf("specified Socket Reverse NAT tables size %d must not exceed maximum %d",
			cfg.LBSockRevNatEntries, option.LimitTableMax)
	}

	// Use [cfg.LBMapEntries] for map size if not overridden.
	opts := []*int{
		&cfg.LBServiceMapEntries,
		&cfg.LBBackendMapEntries,
		&cfg.LBRevNatEntries,
		&cfg.LBAffinityMapEntries,
		&cfg.LBSourceRangeMapEntries,
		&cfg.LBMaglevMapEntries,
	}
	for _, opt := range opts {
		if *opt == 0 {
			*opt = cfg.LBMapEntries
		}
	}

View on GitHub (pinned to ac7b90affa)

Solutions

Lower --sock-revnat-maxEntries to at most option.LimitTableMax (the second %d in the message shows the cap)
Pick a size within [LimitTableMin, LimitTableMax]; the error prints both bounds across the two checks
Remove any memory-based multiplier that inflates the value, or clamp it in your provisioning script
Verify the rendered ConfigMap value before restarting the agent

Example fix

// before
sock-revnat-maxEntries: "100000000"
// after
sock-revnat-maxEntries: "65536"

Defensive patterns

Strategy: validation

Validate before calling

if v := cfg.LBSockRevNatEntries; v > option.LimitTableMax {
	return fmt.Errorf("sock rev NAT entries %d exceeds maximum %d", v, option.LimitTableMax)
}
// run after AlignMapSizeForLRU semantics are considered

Try / catch

if _, err := loadbalancer.NewConfig(log, uc, dcfg); err != nil {
	if strings.Contains(err.Error(), "must not exceed maximum") {
		log.Fatalf("lower --sock-revnat-maxEntries to <= the cap in the message: %v", err)
	}
	return err
}

Prevention

Cap memory-derived map sizing scripts at LimitTableMax
Do not confuse entries with bytes when sizing the socket rev NAT table
Clamp provisioning templates to the documented min/max range
Validate the rendered ConfigMap value before rollout

When it happens

Trigger: Calling NewConfig with LBSockRevNatEntries greater than option.LimitTableMax, e.g. --sock-revnat-maxEntries=100000000, or automation computing a huge size from host memory.

Common situations: Setting map sizes 'to be safe' with very large numbers; scripts sizing tables proportional to node memory without an upper clamp; confusing maxEntries units (entries vs bytes) leading to enormous values.

Related errors

AI-assisted analysis of cilium/cilium@ac7b90affa (2026-08-31). Data as JSON: /api/errors/619ba17d21d47bc9. Report an issue: GitHub.