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

move loopback configuration to intfMgrd #3044

Closed
wants to merge 11 commits into from

Conversation

tylerlinp
Copy link
Contributor

- What I did
Sonic supports multiple loopback interfaces. Each loopback interfaces can belong to different Vrf.

- How I did it
IntfMgrd will take interface-config.service instead to handle loopback interface configuration.

- How to verify it
Pass vrf vs test cases and ansible test cases.

- Description for the changelog

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

@jleveque
Copy link
Contributor

Retest this please

@prsunny
Copy link
Contributor

prsunny commented Jun 20, 2019

Can you please look at the build failures. You may want to fix this file files/image_config/interfaces/interfaces.j2

@tylerlinp
Copy link
Contributor Author

Sorry, I made a mistake when merging.

@lguohan
Copy link
Collaborator

lguohan commented Jun 23, 2019

what is the pr for intfmgrd to support lo? we need both both into the buildimage at the same time.

@tylerlinp
Copy link
Contributor Author

tylerlinp commented Jun 25, 2019

what is the pr for intfmgrd to support lo? we need both both into the buildimage at the same time.

sonic-swss PR:
sonic-net/sonic-swss#943

@@ -9,13 +9,6 @@
# The loopback network interface
auto lo
iface lo inet loopback
# Use command 'ip addr list dev lo' to check all addresses
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tylerlinp @prsunny Any reason why the approach used for mgmt i/f being in the vrf can't be followed for lo? Not even sure that lo should be allowed to be in a vrf. How will redis work if lo is in a vrf?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tylerlinp @prsunny Any reason why the approach used for mgmt i/f being in the vrf can't be followed for lo? Not even sure that lo should be allowed to be in a vrf. How will redis work if lo is in a vrf?

All loopback interfaces map to device lo, that cause conflict when loopbacks belong to differents vrfs. I think lo shouldn't be add to a vrf, even though kernel don't restrict doing so. Some process which communicates locally may be affected. It is good to add a device for every loopback interface(LoopbackXXX), then lo keep original function. Then LoopbackXXX is add vrf/ip just like other l3 interface.

Copy link
Collaborator

@nikos-github nikos-github Jul 25, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I understand the issue. However, you are taking away the ability to further statically configure lo with this change. The right approach to follow would be to leave lo configuration where it is and make sure other loopbacks don't map to the same loopback device.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I understand the issue. However, you are taking away the ability to further statically configure lo with this change. The right approach to follow would be to leave lo configuration where it is and make sure other loopbacks don't map to the same loopback device.

What configuration do you mean? The ip addresses only config to kernel? If not add to ASIC, I think the addresses except 127.x.x.x & ::1 would be useless. If truely needed, maybe should filter configuration like LOOPBACK_INTERFACE|lo|1.1.1.1/32 and then add to interfaces.

@@ -9,13 +9,6 @@
# The loopback network interface
auto lo
iface lo inet loopback
# Use command 'ip addr list dev lo' to check all addresses
Copy link
Collaborator

@nikos-github nikos-github Jul 25, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I understand the issue. However, you are taking away the ability to further statically configure lo with this change. The right approach to follow would be to leave lo configuration where it is and make sure other loopbacks don't map to the same loopback device.

@shine4chen
Copy link
Contributor

@nikos-github This is the loopback device consideration which will add to upcoming vrf-hld-1.2.

  • Sonic must support multiple loopback interfaces and each loopback interface can belong to different vrf. Because linux kernel can only support one lo interface. We will use dummy interface instead of lo interface in linux kernel.

The following is the example to configure new loopback interface by using dummy interface

ip link add loopback1 type dummy
ip link set loopback1 up
ip link set dev loopback1 master Vrf_blue
ip address add 10.0.2.2/32 dev loopback1
  • In existing implementation interface-config.service takes care of loopback configuration. IntfMgrd will take interface-config.service instead to handle it.

@prsunny
Copy link
Contributor

prsunny commented Oct 9, 2019

retest this please

1 similar comment
@tylerlinp
Copy link
Contributor Author

retest this please

Tyler Li and others added 2 commits October 12, 2019 18:09
Merge branch 'master' into loopback, remove blank line
@tylerlinp
Copy link
Contributor Author

@prsunny It is better to merge this PR together with sonic-swss/943.

@prsunny
Copy link
Contributor

prsunny commented Nov 7, 2019

Yes @tylerlinp. We need to update swss submodule. Can you update this PR with submodule update?

@shine4chen
Copy link
Contributor

@prsunny this PR should be merged since PR 943 has been merged.

@tylerlinp
Copy link
Contributor Author

Yes @tylerlinp. We need to update swss submodule. Can you update this PR with submodule update?

OK, I will do it.

@prsunny
Copy link
Contributor

prsunny commented Nov 7, 2019

Ok great, I saw you updated the submodule. I'll close my PR #3720

Submodules update here:

85ff17d - 2019-11-07 : [VRF]: submit vrf feature (#943) [Tyler Li]
5604566 - 2019-11-06 : [vs_test] fix fdb test failed randomly (#1118) [Tyler Li]
038d994 - 2019-11-05 : [vnet]: Correct VNET route table size for BITMAP implementation (#1115) [Volodymyr Samotiy]
bb4e19c - 2019-11-04 : Not wait till kernel net_devices are created for all physical ports to (#1109) [Wenda Ni]
bab7b93 - 2019-11-02 : [portsorch] fix PortsOrch::allPortsReady() returns true when it should not (#1103) [Stepan Blyshchak]
5ab3f6b - 2019-10-31 : Updating pytest for sflow (#1095) [Sudharsan D.G]
d4ccdc3 - 2019-10-29 : Quote input strings before constructing a command line (#1098) [Qi Luo]
5516ec4 - 2019-10-29 : Check RIF/Port exists only for add entries (#1110) [Prince Sunny]
59440f2 - 2019-10-29 : Allow buffer profile apply after init (#1099) [Wenda Ni]

@tylerlinp
Copy link
Contributor Author

retest this please

@tylerlinp
Copy link
Contributor Author

@prsunny It seems that there is problem to build mock_tests when building normal image, not generate Makefile but want to make.

@prsunny
Copy link
Contributor

prsunny commented Nov 7, 2019

retest broadcom please

@prsunny
Copy link
Contributor

prsunny commented Nov 7, 2019

retest mellanox please

@prsunny
Copy link
Contributor

prsunny commented Nov 8, 2019

@tylerlinp , we are working on the build failure

@prsunny
Copy link
Contributor

prsunny commented Nov 8, 2019

@prsunny
Copy link
Contributor

prsunny commented Nov 9, 2019

@tylerlinp , can you update PR with this commit - sonic-net/sonic-swss#1123 ?

@shine4chen
Copy link
Contributor

retest broadcom please

@lguohan
Copy link
Collaborator

lguohan commented Nov 9, 2019

check #3733

@tylerlinp
Copy link
Contributor Author

The commits have been cherry-picked to PR #3733 which has been merged. That's great, so this PR can be closed directlly.

@tylerlinp
Copy link
Contributor Author

retest vs please

@prsunny
Copy link
Contributor

prsunny commented Nov 12, 2019

Closing in favor of #3733

@prsunny prsunny closed this Nov 12, 2019
lguohan pushed a commit that referenced this pull request Feb 9, 2024
…lly (#18079)

 788def1f - (HEAD -> 202205, origin/202205) Fix the Orchagent crash seen during Port channel OC test cases. (#3042) (#3044) (3 minutes ago) [mssonicbld]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants