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

[SONIC] Management VRF design doc #226

Open
wants to merge 1 commit into
base: gh-pages
Choose a base branch
from

Conversation

vharish02
Copy link

This pull request has Management VRF design.

Signed-off-by: Harish Venkatraman Harish_Venkatraman@dell.com

This pull request has Management VRF design.

Signed-off-by: Harish Venkatraman <Harish_Venkatraman@dell.com>
@prsunny
Copy link
Contributor

prsunny commented Aug 7, 2018

Questions:

  1. For sflow type usecase, where sample packets received on FEP and forwarded to a collector via mgmt. port, how is this handled with the Mgmt VRF (l3mdev) approach?
  2. In general, does this require any Netlink related changes for l3mdev?

@shine4chen
Copy link
Contributor

@prsunny
I try to answer your two questions.

  1. I don't think sflow packet should be handled in mgmt vrf. It should be done in default vrf and other data-plane vrf.
  2. In linux 4.9 netlink has supported vrf master and slave notification.

mgmt traffic and data traffic. This is acheived by setting the vrfname to mgmt-vrf in the minigraph.py file as default setting.
The interfaces.j2 file checks for the vrfname tag to see if it is set to mgmt-vrf. If the vrfname is set then it creates the
mgmt-vrf configuration by executing the lniux commands. Debian 4.9 kernel does not support running services per VRF, by enabling
the tcp_l3mdev_accept=1 the services will work across all VRF's. Below diagram shows the flows of event for creating mgmt-vrf on
Copy link
Contributor

Choose a reason for hiding this comment

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

is this only for tcp, do we need udp_l3mdev_accept as well?

Copy link
Author

Choose a reason for hiding this comment

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

udp_l3mdev_accept is not there in 4.9 kernel need to backport the kernel code.

Copy link
Contributor

Choose a reason for hiding this comment

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

since snmpd must be accessible from mgmt network, this is a blocker for management vrf feature.

Copy link
Contributor

Choose a reason for hiding this comment

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

here is the kernel upstream patch. torvalds/linux@63a6fff

can you test it and take it to 4.9 kernel?

Copy link
Author

Choose a reason for hiding this comment

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

Sure will do

"MGMT_INTERFACE": {
"eth0|10.11.150.19/24": {
"gwaddr": "10.11.150.254"
"vrfname": "mgmt-vrf"

Choose a reason for hiding this comment

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

Please change to "vrf": "mgmt" or "vrf": "mgmt-vrf" to be consistent with the vrf proposal.

Copy link
Author

Choose a reason for hiding this comment

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

will do.

}

The vrfname if set to mgmt-vrf will program the linux kernel with the vrf configuration and create a mgmt-vrf for the mgmt
port eth0. If it is set to "None" then the mgmt-vrf will not be configured on the system. Management VRF will be enabled by default when SONiC boots.

Choose a reason for hiding this comment

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

Default configuration should be none or it will break existing deployments.

Copy link
Author

Choose a reason for hiding this comment

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

I believe the requirement was to bring up with mgmt-vrf, But this can be changed.

Choose a reason for hiding this comment

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

If no "vrfname": "mgmt-vrf" in config_db.json, mgmt vrf is enabled by default? I don't see mgmt vrf enabled without "vrfname" config or CLI "config vrf add mgmt" with 201911 image.

-----

By default, mgmt-vrf will be configured in Debian 4.9 kernel, when SONiC boots there will be isolation of traffic between
mgmt traffic and data traffic. This is acheived by setting the vrfname to mgmt-vrf in the minigraph.py file as default setting.

Choose a reason for hiding this comment

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

I believe minigraph.py is getting removed completely.

Copy link
Author

Choose a reason for hiding this comment

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

This if for phase-1 only. in phase 2 we will use config command to configure.

Flow
-----

By default, mgmt-vrf will be configured in Debian 4.9 kernel, when SONiC boots there will be isolation of traffic between

Choose a reason for hiding this comment

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

See above on why it can't be the default.

The config_db.json schema is updated to have the vrfname in MGMT_INTERFACE. The schema representation will look like below

"MGMT_INTERFACE": {
"eth0|10.11.150.19/24": {

Choose a reason for hiding this comment

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

Please outline in your design document how this will work when eth0 ip address and gateway are obtained via dhcp and not statically configured.

Copy link
Author

Choose a reason for hiding this comment

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

will update

}
}

The vrfname if set to mgmt-vrf will program the linux kernel with the vrf configuration and create a mgmt-vrf for the mgmt

Choose a reason for hiding this comment

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

How will the old vrf cleanup happen if user specifies in config_db.json a new vrf for mgmt and does a config reload?

Copy link
Author

Choose a reason for hiding this comment

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

Thereis a scirpt to cleanup the old vrf.

| 6 | Enable DHCP services to run in Management VRF context | | |
| | ˇ Dhcpd | | |
| | ˇ Dhcrelay – Default VRF support | | |
| | ˇ dhclient | | |
Copy link
Contributor

Choose a reason for hiding this comment

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

it is unclear from the design doc that how dhclient can be running in management vrf context and what is the implication for that.

Copy link
Author

Choose a reason for hiding this comment

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

Will update.

-------

In this Phase mgmt-vrf feature will be enabled by default when SONiC boots with Debian 4.9 kernel, configuration of mgmt-vrf will be
done using linux commands.

Choose a reason for hiding this comment

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

Need to describe how DNS resolution will work with eth0 being in the mgmt vrf.

![](https://i.imgur.com/Ge6SNX4.png)


Phase-2

Choose a reason for hiding this comment

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

NTP and DNS need to work when eth0 is placed in the mgmt vrf in Phase-1.

Packet coming via Front end port All IP services listed in Table 1 should Treat the packet like any other data traffic.
be supported. To be sent out as per the routing table lookup

2.In band management
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is there an update to this document ? Apparently per "sonic-net/sonic-utilities#463" only the Management Port (eth0) is part of the management VRF. This description here seems to indicate that Front Panel/In-Band/Front End ports can be part of the management VRF.

show vrf config
show vrf brief
show vrf <vrfname>

Copy link
Collaborator

Choose a reason for hiding this comment

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

Adding some comments on behalf of the Dilip Kumar/VRF Team:

CLI Syntax in Mgmt VRF HLD Feedback/suggestions Notes
config vrf add mgmt config vrf add Vrf-mgmt VRF name should be prefixed by "Vrf"
config vrf del mgmt config vrf del Vrf-mgmt  
config interface ip add eth0 ip/mask gatewayIP config interface ip add eth0 <IP/Mask> The default GW must be configured as a regular static IP route command (ip route add 0.0.0.0/0 GW)
config interface ip remove eth0 ip/mask    
     
show mgmt-vrf show vrf Vrf-mgmt [--verbose] This command should display the data from ConfigDB instead from kernel, like for other VRFs
show mgmt-vrf routes show ip route vrf Vrf-mgmt This should display routes from Zebra instead from Kernel. Behavior should be similar to other user VRFs

Introduction
------------

Management VRF is a subset of VRF (virtual routing tables and forwarding) and provides a separation between the out-of-band management network and the in-band data plane network. For all VRFs, the main routing table is the default table for all of the data plane switch ports. With management VRF, a second table, mgmt, is used for routing through the Ethernet ports of the switch. The following design for mgmt-vrf uses the l3mdev approach for implementating mgmt-vrf on SONiC.
Copy link
Contributor

Choose a reason for hiding this comment

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

Need some changes in wording as the current one is similar to https://docs.cumulusnetworks.com/cumulus-linux/Layer-3/Management-VRF

To be sent out as per the routing table lookup To be sent out as per the routing table lookup
Dest IP = FEP IP in Default VRF Dest IP ≠ FEP IP in Default VRF

Packet coming via mgmt. port Packet dropped Packet dropped

Choose a reason for hiding this comment

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

Confusing. Line 40 is also "Packet coming via mgmt. port", why the actions are different.

Copy link
Contributor

Choose a reason for hiding this comment

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

The table is not formatted well. There are two scenarios discussed:

Packets coming with 1) Dest IP == Mgmt IP; 2) Dest IP == front-end-port IP. A line with "------------------" should be drawn below line 45

https://github.com/Azure/SONiC/pull/226/files/310de5a9d649481e23ec3b048cbe90242c6e063f#r367057554

}

The vrfname if set to mgmt-vrf will program the linux kernel with the vrf configuration and create a mgmt-vrf for the mgmt
port eth0. If it is set to "None" then the mgmt-vrf will not be configured on the system. Management VRF will be enabled by default when SONiC boots.

Choose a reason for hiding this comment

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

If no "vrfname": "mgmt-vrf" in config_db.json, mgmt vrf is enabled by default? I don't see mgmt vrf enabled without "vrfname" config or CLI "config vrf add mgmt" with 201911 image.

@prsunny
Copy link
Contributor

prsunny commented Apr 16, 2020

Revised document is available at - #603

Copy link
Contributor

@rajkumar38 rajkumar38 left a comment

Choose a reason for hiding this comment

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

A general question. Does SWSS 00-copp.config.json will be applicable to traffic received on in-band-mgmt interface ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants