Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

T6222: VRRP show prefix for long rfc3768-compatibility interfaces allow prefix vrrp #3292

Merged
merged 1 commit into from
Apr 11, 2024

Conversation

sever-sever
Copy link
Member

@sever-sever sever-sever commented Apr 11, 2024

Change Summary

If we use rfc3768-compatibility with long interface names like eth1.100.200 it converts the VRRP interface name name to <interface>v<VRID><IP version>
For example eth2.100.200v10v4

The limit for interface name is 15 symbols and it causes that interface name is ignoring by keepalived

VMAC interface name 'eth2.100.200v10v4' too long or invalid characters - ignoring And it uses the default prefix vrrp for such cases. It works fine, but such interfaces are not displayed in the op-mode

Allow prefix vrrp for the op-mode for show interfaces

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Code style update (formatting, renaming)
  • Refactoring (no functional changes)
  • Migration from an old Vyatta component to vyos-1x, please link to related PR inside obsoleted component
  • Other (please describe):

Related Task(s)

Related PR(s)

Component(s) name

Proposed changes

How to test

set interfaces ethernet eth2 vif-s 100 vif-c 200 address '10.0.1.1/30'

set high-availability vrrp group FIRST address 203.0.113.1/24
set high-availability vrrp group FIRST interface 'eth2.100.200'
set high-availability vrrp group FIRST no-preempt
set high-availability vrrp group FIRST priority '250'
set high-availability vrrp group FIRST rfc3768-compatibility
set high-availability vrrp group FIRST vrid '10'

Before the fix we don't see interface with address 203.0.113.1

vyos@r4:~$ show interfaces 
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface     IP Address         MAC                VRF        MTU  S/L    Description
------------  -----------------  -----------------  -------  -----  -----  -------------
eth0          192.168.122.14/24  52:54:00:f1:fd:77  default   1500  u/u    WAN
eth1          -                  52:54:00:04:33:2b  default   1500  u/u    WAN
eth2          -                  52:54:00:40:2e:af  default   1500  u/u    sync
eth2.100      -                  52:54:00:40:2e:af  default   1500  u/u
eth2.100.200  10.0.1.1/30        52:54:00:40:2e:af  default   1500  u/u
eth3          -                  52:54:00:09:a4:b4  default   1500  A/D
eth4          -                  52:54:00:2c:51:09  default   1500  A/D
eth5          -                  52:54:00:f3:1d:e8  default   1500  A/D
lo            127.0.0.1/8        00:00:00:00:00:00  default  65536  u/u
              ::1/128
vti10         -                  n/a                default   1500  A/D
vyos@r4:~$ 

But actually address exits

vyos@r4:~$ ip addres show dev vrrp.10
49: vrrp.10@eth2.100.200: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:00:5e:00:01:0a brd ff:ff:ff:ff:ff:ff
    inet 203.0.113.1/24 scope global vrrp.10
       valid_lft forever preferred_lft forever
vyos@r4:~$ 

After the fix, the expected interface if showing with the prefix vrrp

vyos@r4:~$ show interfaces 
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface     IP Address         MAC                VRF        MTU  S/L    Description
------------  -----------------  -----------------  -------  -----  -----  -------------
eth0          192.168.122.14/24  52:54:00:f1:fd:77  default   1500  u/u    WAN
eth1          -                  52:54:00:04:33:2b  default   1500  u/u    WAN
eth2          -                  52:54:00:40:2e:af  default   1500  u/u    sync
eth2.100      -                  52:54:00:40:2e:af  default   1500  u/u
eth2.100.200  10.0.1.1/30        52:54:00:40:2e:af  default   1500  u/u
eth3          -                  52:54:00:09:a4:b4  default   1500  A/D
eth4          -                  52:54:00:2c:51:09  default   1500  A/D
eth5          -                  52:54:00:f3:1d:e8  default   1500  A/D
lo            127.0.0.1/8        00:00:00:00:00:00  default  65536  u/u
              ::1/128
vrrp.10       203.0.113.1/24     00:00:5e:00:01:0a  default   1500  u/u
vti10         -                  n/a                default   1500  A/D
vyos@r4:~$ 

Smoketest result

Checklist:

  • I have read the CONTRIBUTING document
  • I have linked this PR to one or more Phabricator Task(s)
  • I have run the components SMOKETESTS if applicable
  • My commit headlines contain a valid Task id
  • My change requires a change to the documentation
  • I have updated the documentation accordingly

If we use rfc3768-compatibility with long interface names like
eth1.100.200 it converts the VRRP interface name name
to `<interface>v<VRID><IP version>`
For example `eth2.100.200v10v4`

The limit for interface name is 15 symbols and it causes that
interface name is ignoring by keepalived

VMAC interface name 'eth2.100.200v10v4' too long or invalid characters - ignoring
And it uses the default prefix `vrrp` for such cases.
It works fine, but such interfaces are not displayed in the op-mode

Allow prefix `vrrp` for the op-mode for `show interfaces`
@vyosbot vyosbot requested review from a team, dmbaturin, sarthurdev, zdc, jestabro and c-po and removed request for a team April 11, 2024 09:22
@dmbaturin dmbaturin merged commit 00be89b into vyos:current Apr 11, 2024
9 checks passed
@dmbaturin
Copy link
Member

@Mergifyio backport sagitta

Copy link
Contributor

mergify bot commented Apr 11, 2024

backport sagitta

✅ Backports have been created

dmbaturin added a commit that referenced this pull request Apr 12, 2024
T6222: VRRP show prefix for long rfc3768-compatibility interfaces allow prefix vrrp (backport #3292)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging this pull request may close these issues.

2 participants