zebra: Allow redistribution events to pass reserved ranges

[donaldsharp]

If allow-reserved-ranges has been configured, allow the redistribution event to be passed up to the interested protocol.

I ran into this while playing with 224/4 flavors of static routes and was trying to get the static route into bgp. BGP was allowing network XXX statements for the routes. So I do not see much of a difference here.

[donaldsharp]

before we pull the trigger here in any direction, let's make sure we discuss this in tomorrows tech meeting.

[greptile-apps]

Greptile Overview

Greptile Summary

Modified zebra_check_addr() to respect the allow-reserved-ranges configuration for loopback (127.0.0.0/8) and Class D multicast (224.0.0.0/4) address ranges during route redistribution.

Key Changes:

• Split the validation logic to check allow-reserved-ranges config for 127.x.x.x and Class D addresses
• When allow-reserved-ranges is enabled, these previously-blocked ranges can now be redistributed to routing protocols (BGP, OSPF, etc.)
• Link-local addresses (169.254.0.0/16) remain blocked regardless of configuration
• Aligns zebra redistribution behavior with BGP's existing support for reserved ranges via network statements

Impact:

• Enables use cases like redistributing static routes in reserved ranges (e.g., 224/4) to BGP when allow-reserved-ranges is configured
• Maintains backward compatibility: default behavior (config disabled) unchanged
• Consistent with the documented purpose of allow-reserved-ranges feature

Confidence Score: 4/5

• This PR is safe to merge with minimal risk - it's a small, focused change with clear intent
• The change is straightforward and logically sound, properly gating reserved range support behind an existing configuration flag. The modification correctly splits the validation logic to allow 127.x.x.x and Class D addresses when allow-reserved-ranges is enabled while maintaining the block on link-local addresses. The implementation aligns with the documented purpose of the feature and maintains backward compatibility (default behavior unchanged). One minor consideration: the PR description mentions 224/4 and BGP network statements, and while the change is consistent with BGP's behavior, it would be valuable to verify Class D multicast redistribution is the intended use case, as the documentation doesn't explicitly mention enabling Class D ranges.
• No files require special attention - the single modified function is clean and the logic is correct

Important Files Changed

Filename	Overview
zebra/zebra_rib.c	Modified zebra_check_addr() to respect allow-reserved-ranges config for 127.x.x.x and Class D (224.x.x.x) addresses, enabling redistribution when configured

Sequence Diagram

sequenceDiagram
    participant Client as Protocol Client (BGP/OSPF/etc)
    participant Redistribute as zebra_redistribute_update()
    participant CheckAddr as zebra_check_addr()
    participant Config as allow-reserved-ranges Config
    
    Note over Redistribute: Route update received
    Redistribute->>CheckAddr: Check if address is valid for redistribution
    
    alt Address is 127.x.x.x or 224.x.x.x (Class D)
        CheckAddr->>Config: cmd_allow_reserved_ranges_get()
        
        alt allow-reserved-ranges enabled
            Config-->>CheckAddr: true
            CheckAddr-->>Redistribute: return 1 (valid)
            Redistribute->>Client: Send route update
        else allow-reserved-ranges disabled (default)
            Config-->>CheckAddr: false
            CheckAddr-->>Redistribute: return 0 (invalid)
            Note over Redistribute: Route filtered, not sent to client
        end
    else Address is link-local (169.254.x.x, non-Class E)
        CheckAddr-->>Redistribute: return 0 (always invalid)
        Note over Redistribute: Route filtered regardless of config
    else Other valid address
        CheckAddr-->>Redistribute: return 1 (valid)
        Redistribute->>Client: Send route update
    end

Loading

[ton31337]

LGTM, but can we have a topotest?

[riw777]

looks good

[donaldsharp]

topotest added