Feature request: interface ip addresses order

[EasyNetDev]

Description

Depending on how you give the commands in vtysh for ip addresses this is the order of the IPs installed on interface.
But as soon you save the configuration, the order in config is different, taking the ascending order of the IPs.
It could be nice to have an specific order of the IPs installed on the interface, for example for lo that can have public IP and private IP. In this case you want the public IP to be first in to be able to use GRT as a normal system to do updates for example.
At this moment Linux doesn't support multiple loopbacks, except dummy interfaces.

Version

FRRouting 10.1-dev (R02) on Linux(6.6.15-amd64).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
configured with:
    '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--sbindir=/usr/lib/frr' '--with-vtysh-pager=/usr/bin/pager' '--libdir=/usr/lib/x86_64-linux-gnu/frr' '--with-moduledir=/usr/lib/x86_64-linux-gnu/frr/modules' '--disable-dependency-tracking' '--enable-rpki' '--disable-scripting' '--enable-pim6d' '--with-libpam' '--enable-doc' '--enable-doc-html' '--enable-snmp' '--enable-fpm' '--disable-protobuf' '--disable-zeromq' '--enable-ospfapi' '--enable-bgp-vnc' '--enable-multipath=256' '--enable-user=frr' '--enable-group=frr' '--enable-vty-group=frrvty' '--enable-configfile-mask=0640' '--enable-logfile-mask=0640' 'build_alias=x86_64-linux-gnu' 'PYTHON=python3'

How to reproduce

Simple config:

R02# interface lo
R02#  description Loopback MPLS / BGP VPNv4 + VPNv6
R02#  ip address 89.A.B.2/32 label 01
R02#  ip address 10.100.2.1/32 label 02

Output in OS:

R02# ip a l lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet 89.A.B.2/32 brd 89.A.B.2 scope global 01
       valid_lft forever preferred_lft forever
    inet 10.100.2.1/32 brd 10.100.2.1 scope global 02
       valid_lft forever preferred_lft forever

In FRR:

interface lo
 description Loopback MPLS / BGP VPNv4 + VPNv6
 ip address 10.100.2.1/32 label 02
 ip address 89.A.B.2/32 label 01

As soon you load reload FRR it will set the order:

R02# ip a l lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet 10.100.2.1/32 brd 10.100.2.1 scope global 02
       valid_lft forever preferred_lft forever
    inet 89.A.B.2/32 brd 89.A.B.2 scope global 01
       valid_lft forever preferred_lft forever

Then you can't use anymore GRT to update your system, beacause the first IP will be 10.100.2.1.

Expected behavior

In FRR should be something like:

R02# interface lo
R02#  description Loopback MPLS / BGP VPNv4 + VPNv6
R02#  ip address 89.A.B.2/32 label 01
R02#  ip address 10.100.2.1/32 label 02
R02# show run
interface lo
 description Loopback MPLS / BGP VPNv4 + VPNv6
 ip address 89.A.B.2/32 label 01
 ip address 10.100.2.1/32 label 02

Actual behavior

In FRR is like this now:

R02# interface lo
R02#  description Loopback MPLS / BGP VPNv4 + VPNv6
R02#  ip address 89.A.B.2/32 label 01
R02#  ip address 10.100.2.1/32 label 02
R02# show run
interface lo
 description Loopback MPLS / BGP VPNv4 + VPNv6
 ip address 10.100.2.1/32 label 02
 ip address 89.A.B.2/32 label 01

Additional context

No response

Checklist

• I have searched the open issues for this bug.
• I have not included sensitive information in this report.

[ton31337]

Isn't something like adding secondary for ip address ... [secondary] would help here?

[EasyNetDev]

Isn't something like adding secondary for ip address ... [secondary] would help here?

Yes. Cisco has this feature.

[idryzhov]

@EasyNetDev can you please explain what is the end goal? You have two addresses from different subnets, how does their order affect anything?

[EasyNetDev]

@EasyNetDev can you please explain what is the end goal? You have two addresses from different subnets, how does their order affect anything?

Well I explained in the description. When you install 89.x.x.Y/32 IP address on lo as first address I will be able to use apt to update the system, because 89.x.x.Y/32 is the first IP in GRT.
GRT has a default route towards internet VRF and in internet I'm leaking 89.x.x.Y/32.
But if 10.100.2.1/32 is installed first, then all the traffic going out from GRT will have source as 10.100.2.1 instead 89.x.x.Y/32.

If in FRR I'm adding 89.x.x.Y/32 as first IP on interface, everything is fine. But as soon I'm restarting FRR, 10.100.2.1 is smaller than 89.x.x.Y and the order will be 10.100.2.1/32 first and also installed on lo.

If we could have secondary or keep the order of IP inserted then you will have 89.x.x.Y/32 as primary IP.

[idryzhov]

Is the default route installed by FRR? If yes, you can create a route-map with set src clause to set the preferred source address for the route. If not, I think there should be some way to set the address as well, for example, there's a src ADDRESS option in ip route add command.

[EasyNetDev]

Hi @idryzhov ,

Yes, the default route is installed in FRR:

ip route 0.0.0.0/0 internet nexthop-vrf internet
ipv6 route ::/0 internet nexthop-vrf internet

Ok, the route-map I can create with set src ADDRESS :

route-map rm-GRT-SRC permit 1000
 set src 89.X.X.0
exit

But at first glance, I have no clue where to apply this RM. In FRRouting documentation I can't find anything regarding set src ADDRESS:
https://docs.frrouting.org/en/latest/routemap.html
or
https://docs.frrouting.org/en/latest/zebra.html

R01(config)# ip route 0.0.0.0/0 internet nexthop-vrf internet
  <cr>
  (1-255)  Distance value for this route
  bfd      BFD monitoring
  color    SR-TE color
  label    Specify label(s) for this route
  table    Table to configure
  tag      Set tag for this route
  vrf      Specify the VRF

No options to add this RM to the route.

But, checking a little bit deeper in the Zebra documentation I've notice this:

ip protocol PROTOCOL route-map ROUTEMAP

Then:

R01(config)# ip protocol static route-map rm-GRT-SRC

I notice this using ip route show:

R01:/# ip r l
default nhid 7773582 dev internet proto static src 89.X.X.0 metric 20

But is not very clear in the documentation how to do it.

For a better tuning I used the RM like this:

ip prefix-list pl-DEFAULT-ROUTE description IPv4 Default Route
ip prefix-list pl-DEFAULT-ROUTE seq 5 permit 0.0.0.0/0
ipv6 prefix-list pl-DEFAULT-ROUTE description IPv6 Default Route
ipv6 prefix-list pl-DEFAULT-ROUTE seq 5 permit ::/0
!
route-map rm-GRT-SRC permit 1000
 match ip address prefix-list pl-DEFAULT-ROUTE
 set src 89.X.X.0
exit
!
route-map rm-GRT-SRC permit 1100
 match ipv6 address prefix-list pl-DEFAULT-ROUTE
 set src 2a00:X:X::1:1
exit
!
ip protocol static route-map rm-GRT-SRC
!
ipv6 protocol static route-map rm-GRT-SRC
!

Then is working for both IPv4 and IPv6:

default nhid 7776927 dev internet proto static src 2a00:X:X::1:1 metric 20 pref medium
default nhid 7773582 dev internet proto static src 89.X.X.0 metric 20

[ton31337]

Moved to https://github.com/FRRouting/frr/wiki/Feature-Requests.

[DennyAgussy]

Subject: Proposal: Adding setorder Keyword for Ordered IP Configuration

Hi everyone,
We'd like to propose the addition of a new keyword, "setorder", to the IP address configuration command. This keyword would allow users to specify the order in which IP addresses are applied to an interface, ensuring consistent behavior regardless of the order they are entered.

Motivation
Currently, the order in which IP addresses are configured on an interface can potentially impact functionality in some scenarios. With setorder, users can define a clear and predictable order for IP usage, eliminating this potential source of inconsistency.

Proposed Solution
The setorder keyword would be added as an optional parameter to the IP address configuration command. It would accept an integer value representing the desired order for that specific IP address. Lower values indicate a higher priority.

Example Configuration
R1# interface eth3
R1# ip address 89.A.B.2/32 setorder 5
R1# ip address 10.100.2.1/32 setorder 6
R1# ip address 16.16.2.1/32 setorder 3
R1# ip address 83.83.2.6/32
R1# ip address 63.63.2.6/32

In this example, the IP addresses would be applied in the following order (ascending setorder value):
16.16.2.1/32 (setorder 3)
89.A.B.2/32 (setorder 5)
10.100.2.1/32 (setorder 6)
The remaining two IP addresses (without setorder) would retain their current behavior.

Expected Output (After FRR Reload)
interface eth3
ip address 16.16.2.1/32 setorder 3
ip address 89.A.B.2/32 setorder 5
ip address 10.100.2.1/32 setorder 6
ip address 83.83.2.6/32
ip address 63.63.2.6/32

Is the proposed setorder solution acceptable for achieving predictable IP address order on interfaces? If not, please provide details on any concerns or alternative approaches you may have.

Thanks
Denny Agussy

[DennyAgussy]

Hi everyone

Subject:
Implemented the solution as mentioned in the previous reply(previous comment link). Added a new feature(keyword) setorder that sorts the IPs on the interface.

Introduction:
As per the issue mentioned about IP addresses not being maintained in the order in which they are assigned/configured on an interface, we have added a keyword, setorder, which allows us to control the order of the IPs on interfaces.

Feature Overview:
With this feature in place, we can control the order of IPs as needed, and when we restart FRR, the order will be restored according to our setorder parameter, which takes the next immediate integer as its value. Any other commands on an interface will not have their order changed in /etc/frr/frr.conf, except for the IPs with the setorder keyword. All other commands will follow the order in which they are configured.

Implementation Details:
The feature ensures that IPs on interfaces are configured according to the setorder parameter. When we restart FRR, this feature initiates by backing up /etc/frr/frr.conf to a temporary file before modifying the order within frr.conf. Subsequently, sorting occurs based on the setorder keyword and updates are pushed to /etc/frr/frr.conf. Now, the IPs are configured in the sorted order as specified.

Testing and Validation:
Required unit and functionality testing have been completed.

NOTE:
This feature works only when vtysh.conf "service integrated-vtysh-config"

For your reference:
Before restarting frr
interface eth0
ip address 2.2.3.178/24 setorder 5
ip address 3.1.3.178/24 setorder 5
ip address 45.46.8.7/24 setorder 4
ip address 55.65.8.7/24 setorder 1
ip address 76.75.3.9/24 setorder 2
exit

After restarting the frr
interface eth0
ip address 55.65.8.7/24 setorder 1
ip address 76.75.3.9/24 setorder 2
ip address 45.46.8.7/24 setorder 4
ip address 2.2.3.178/24 setorder 5
ip address 3.1.3.178/24 setorder 5
exit

The order in which they will be configered by zebra and ip's order in kernel
ip addr show eth0
562: eth0@if563: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:0c:0c:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 12.12.0.2/16 brd 12.12.255.255 scope global eth0
valid_lft forever preferred_lft forever
inet 55.65.8.7/24 brd 55.65.8.255 scope global eth0
valid_lft forever preferred_lft forever
inet 76.75.3.9/24 brd 76.75.3.255 scope global eth0
valid_lft forever preferred_lft forever
inet 45.46.8.7/24 brd 45.46.8.255 scope global eth0
valid_lft forever preferred_lft forever
inet 2.2.3.178/24 brd 2.2.3.255 scope global eth0
valid_lft forever preferred_lft forever
inet 3.1.3.178/24 brd 3.1.3.255 scope global eth0
valid_lft forever preferred_lft forever

Conclusion
Please reach out to me if any clarifications are required. Additionally, I have attached the patch file with the diff (master branch) below. We can also extend our support to integrate this feature with respect to IPv6, contingent upon the acceptance of the current patch.

Patch File:
setorder.zip

Thanks
Denny Agussy