[yang] interface: add missing mac_addr leaf

[bradh352]

Why I did it

YANG configuration verification fails during config replace.

How I did it

mac_addr support was added in the INTERFACE, PORTCHANNEL_INTERFACE, and VLAN_INTERFACE tables by sonic-net/sonic-swss#814 in 2020 but the YANG models were never updated to reflect that change. Updated yang model to reflect change.

How to verify it

Add mac_addr to the various INTERFACE tables then run config replace and it succeeds.

Work item tracking

Which release branch to backport (provide reason below if selected)

• 201811
• 201911
• 202006
• 202012
• 202106
• 202111
• 202205
• 202211
• 202305
• 202411

Marked all releases that contained the change.

Tested branch (Please provide the tested image version)

master as of 20241109

Description for the changelog

YANG INTERFACE: add missing mac_addr leaf

Link to config_db schema for YANG module changes

There is no actual INTERFACE section in the docs (there probably should be).

A picture of a cute animal (not mandatory but encouraged)

Fixes #14253
Signed-off-by: Brad House (@bradh352)

[bradh352]

test failures are unrelated to this PR

[bradh352]

/AzurePipelines run Azure.sonic-buildimage

[azure-pipelines]

Commenter does not have sufficient privileges for PR 20968 in repo sonic-net/sonic-buildimage

[dgsudharsan]

Can you please add this config to sample_config_db.json as well us update the schema in Configuration.md?
In addition can you please add a test case covering MAC address with capital hex letters to see if it pass?

[bradh352]

@dgsudharsan I guess I'll need to break out an INTERFACE section since such a thing doesn't exist in the current docs and try to migrate the other info into there.

[bradh352]

@dgsudharsan ready for review

[dgsudharsan]

@bradh352 I think there is some problem with the diff in configuration.md. Due to formatting, it is showing a huge diff which will be very hard to manage especially when we plan to cherry-pick changes to different branches. Can you please ensure the diff shows only the changed content?

[bradh352]

@dgsudharsan I thought you might say that. I'm really frustrated with the markdown format used (inconsistently and incorrectly) in that doc, so I fixed a lot of it. It was worth a shot to clean it up and actually make, say, the Table of Contents links actually work. Oh well. I'll revert that stuff and just keep the changes relevant to this PR.

[bradh352]

@dgsudharsan hopefully that's acceptable now, please review

[bradh352]

found a couple minor bugs, one unexpected as I didn't realize the double-conversion flow for the sample db. those should be corrected now.

[bradh352]

@dgsudharsan I moved the most important parts of my markdown cleanup into PR #21072 it would be great if that could be merged. I provided the links to render mine vs original, you'll see the table of contents works on mine.

[bradh352]

rebased to force rebuild to see if build general sonic CI build/test issues have been resolved

[bradh352]

@dgsudharsan @qiluo-msft please merge

[mssonicbld]

/azp run Azure.sonic-buildimage

[bradh352]

@ganglyu

LGTM @prsunny Could you please review this PR? Do we really need the MAC address?

This isn't adding a feature for mac addresses, just letting YANG know about something that already exists.

Also, the use case for setting mac addresses is for pure layer3 environments (e.g. VXLAN EVPN - BGP). If you have 2 switches wired together with dual ports (for redundancy), you need each port to have a different mac address otherwise you have mac conflicts. At least on my Trident3 switches, every port defaults to the same system-wide mac address. So it is necessary.

[wen587]

Is it good to support from now for mac_address? Do we need to backport? It will break YANG validation if we add mac_address in INTERFACE for the past releases.

[bradh352]

@wen587

Is it good to support from now for mac_address? Do we need to backport? It will break YANG validation if we add mac_address in INTERFACE for the past releases.

not sure how it would break yang validation, if someone is using mac_addr currently they aren't doing any yang validation at all since yang would reject. But I don't honestly care if its backported or not.

[prsunny]

this should be an optional field.

[bradh352]

This doesn't have the mandatory true; attribute and also doesn't have a default value .... so it is therefore optional as far as I am aware.

What am I missing here?

[mssonicbld]

/azp run Azure.sonic-buildimage

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).