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.

Sign up for GitHub

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

Jump to bottom

DHCP relay for IPv6 HLD #765

Merged
merged 1 commit into from
Jul 1, 2021
Merged

DHCP relay for IPv6 HLD #765

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
155 changes: 155 additions & 0 deletions doc/DHCPv6_Relay/DHCPv6_Relay_HLD.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,155 @@
# DHCP Relay for IPv6 HLD

# High Level Design Document

#### Rev 0.1

# Table of Contents
- [DHCP Relay for IPv6 HLD](#dhcp-relay-for-ipv6-hld)
- [High Level Design Document](#high-level-design-document)
- [Rev 0.1](#rev-01)
- [Table of Contents](#table-of-contents)
- [List of Tables](#list-of-tables)
- [List of Figures](#list-of-figures)
- [Revision](#revision)
- [About this Manual](#about-this-manual)
- [Scope](#scope)
- [Definitions/Abbreviation](#definitionsabbreviation)
- [1 Requirements Overview](#1-requirements-overview)
- [1.1 Functional requirements](#11-functional-requirements)
- [1.2 Configuration and Management Requirements](#12-configuration-and-management-requirements)
- [2 Modules design](#2-modules-design)
- [2.1 DHCP Relay for IPv6 build and runtime dependencies](#21-dhcp-relay-for-ipv6-build-and-runtime-dependencies)
- [2.2 DHCP Relay for IPv6 process in dhcp-relay container](#22-dhcp-relay-for-ipv6-process-in-dhcp-relay-container)
- [2.3 DHCP Monitor](#23-dhcp-monitor)
- [3 CLI](#3-cli)
- [4 Init flow](#4-init-flow)

# List of Tables
* [Table 1: Abbreviations](#definitionsabbreviation)

# List of Figures
* [DHCPv6 Diagram](#2-modules-design)
* [DHCPv6 init flow](#4-init-flow)

# Revision
| Rev | Date | Author | Change Description |
|:---:|:--------:|:---------------:|------------------------------------|
| 0.1 | 03/04 | Shlomi Bitton | Initial version |

# About this Manual
This document provides an overview of the implementation and integration of DHCP Relay for IPv6 feature in SONiC.

# Scope
This document describes the high level design of the DHCP Relay for IPv6 feature in SONiC.

# Definitions/Abbreviation
| Abbreviation | Description |
|---------------|-------------------------------------------|
| DHCP | Dynamic Host Configuration Protocol |

# 1 Requirements Overview

## 1.1 Functional Requirements

DHCP Relay for IPv6 feature in SONiC should meet the following high-level functional requirements:

- Give the support for relaying DHCP packets from downstream networks to upstream networks using IPv6 addresses.
Copy link

Choose a reason for hiding this comment

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

One more requirement here is to support RFC:6936 option 79 as part of DHCPv6 relay functionality.

Copy link
Collaborator

Choose a reason for hiding this comment

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

But this is out of the scope of this HLD. this HLD is to cover only existing functionality on top of IPv6.
Any additional requirements should come with a new HLD to cover the new requirements.
@tahmed-dev do you agree?

- Provide the functionality as a seperate process running on dhcp-relay docker container.
- Relaying messages to multiple unicast and multicast addresses.

## 1.2 Configuration and Management Requirements

- DHCPv6 trap should be enabled through the COPP manager when the DHCP relay feature is enabled and vice versa.
- Downstream network is the VLAN interface with the relay configuration. Global IPv6 address is required to be configured on that interface.
Copy link

Choose a reason for hiding this comment

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

Can the downstream interface be a physical L3 interfaces or PortChannel L3 interface (with out VLAN)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

On the scope of this HLD, the downsteam network designed to be a Vlan interface.

- Config DB schema should meet the following format:
```
{
Copy link

Choose a reason for hiding this comment

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

This is not finalized yer, however the idea is to have DHCP in a separate feature table instead of being property of Vlan. Something as follows:

    "DHCP": {
        "downlink-intf-i": {
            "dhcpv4_servers": ["dhcp-server-0", "dhcp-server-1", ...., "dhcp-server-n-1"],
            "dhcpv6_servers": ["dhcp-server-0", "dhcp-server-1", ...., "dhcp-server-n-1"]
        }
    }

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Currently it is implemented in a way supervisord on dhcp_relay docker is taking the data by the 'dhcp_servers' on the Vlan interface.
To adapt this new approach all needed is to change the template to this schema.

"VLAN": {
"Vlan1000": {
"dhcp_servers": [
"192.0.0.1",
"192.0.0.2",
],
"dhcpv6_servers": [
"21da:d3:0:2f3b::7",
"21da:d3:0:2f3b::6",
],
"vlanid": "1000"
}
}
}
```

# 2 Modules design

![DHCPv6 Diagram](/doc/DHCPv6_Relay/diagram.png)

## 2.1 DHCP Relay for IPv6 build and runtime dependencies

The DHCP Relay for IPv6 feature, same as the IPv4 version, will be based on the open source project 'isc-dhcp'.

## 2.2 DHCP Relay for IPv6 process in dhcp-relay container

A new process will run in parallel to the other process for IPv4 support.
The new process will listen to DHCP packets for IPv6 and forward them to the relevant interface according to the configuration.
For example, from the configuration described on the previous section, the following daemon will start:
```
admin@sonic:/# /usr/sbin/dhcrelay -6 -d --name-alias-map-file /tmp/port-name-alias-map.txt -l Vlan1000 -u 21da:d3:0:2f3b::7%Ethernet28 -u 21da:d3:0:2f3b::6%Ethernet28
Copy link

Choose a reason for hiding this comment

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

The new process will read config data from config db and will not rely on cli.

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 sure, this instance is taken from config DB data, by the template generated for supervisord on dhcp_realy docker.

Copy link

Choose a reason for hiding this comment

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

Is it mandatory to specify the upstream interface along with the DHCPv6 server address? The server may not be directly connected to the L3 relay - for example, we could have an IPv6 route to the DHCPv6 server. Will that scenario work? What happens if the IPv6 addresses are removed/re-configured to different upstream interface? Will that require restart of DHCP docker?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For the user this configuration is transparent, same as the IPv4 implementation, isc-dhcp-relay will try to relay DHCP packets to all configured servers, the kernel will determine if to send the packet or not depending on the route available in the kernel.
If the server is not directly connected to the L3 interface the DHCP_FORWARD message will be transmitted, if another relay is on the other side, it will forward the message again until it will reach the server and vise versa.
if the IPv6 addresses are removed/re-configured on the L3 up link interfaces than yes, a restart of the service is required.

```

## 2.3 DHCP Monitor

The existing DHCP monitor will be enhanced in order to support monitoring for DHCP IPv6 as well.
Copy link

Choose a reason for hiding this comment

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

DHCP counters will be part of the new DHCPv6 relay.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So with the new approach the DHCP monitor application will be removed?

Copy link

Choose a reason for hiding this comment

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

Is there any support for DHCPv6 relay counters ? These will help a lot for debugging.

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 there is, the DHCP monitor application is now supporting monitor for these counters as well.
Please check the PR of the implementation.

Copy link

Choose a reason for hiding this comment

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

Is there any support for DHCPv6 relay counters ? These will help a lot for debugging.

Yes, there will be native support in the app to pull counters. Please have a look at PR:787

Copy link

Choose a reason for hiding this comment

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

Yes there is, the DHCP monitor application is now supporting monitor for these counters as well.
Please check the PR of the implementation.

the dhcpmon will not exist in DHCPv6 world, rather its functionality will be in the new SONiC DHCPv6 RA.

Copy link
Contributor Author

@shlomibitton shlomibitton Jun 25, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

@tahmed-dev Can you please elaborate why the dhcpmon will not exist?
Same as the IPv4 implementation of this monitor, we can check inconsistency in received and transmitted packets.
for received SOLICIT/REQUEST packets we expect to see a RELAY-FORWARD packet transmitted.
for received RELAY-REPLY packets we expect to see ADVERTISE/REPLY packet transmitted.

Copy link

Choose a reason for hiding this comment

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

@shlomibitton The driving force to have a monitoring application (dhcpmon) was that ISC DHCP does not integrate well with SONIiC infra and its counters were not readily available via telemetry.. With the new DHCPv6 RA, it will integrate with the SONiC redis db and its counters will be available via telemetry and cli. So, we thought about eliminating it.

One might argue that the monitoring app would still capture anomalies in DHCPv6 behavior as it is external to it. I am not sure if this is a design pattern we would like to follow as if we end with every app having a shadow app that monitors it, one can image the number of app would grow...

Also, dhcpmon is launching per interface which is inefficient to have a process for every interface that has dhcp relay enabled.

Please comment on PR:787

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@tahmed-dev thanks for the explanation.
On this case, what do you suggest to use as a monitor application with the isc-dhcp-relay package on this case?
This HLD is based on this implementation and we would like to have some kind of a monitor right?
On the other HLD on 'counters' section all I can see is the approach to keep the number of each message type but that's about it.

Copy link

Choose a reason for hiding this comment

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

@shlomibitton counters will be available via telemetry. The cloud would alert on counters if incrementing. Also, we can alternatively add checks similar to dhcpmon monitoring check and print to syslog. I believe Telemetry is maturing now and so the former solution should be adopted.

For this HLD, it is fine to have dhcpmon changes for the time being. This HLD and the accompanying code will be reverted once the new solution is merged.


## 3 CLI

The existing CLI will be enhanced to support configuring DHCP IPv6 along with the IPv4 support.

**config vlan dhcp_relay add**

Usage:
```
config vlan dhcp_relay add <vlan_id> <dhcp_relay_destination_ip>
```
Example:
```
admin@sonic:~$ sudo config vlan dhcp_relay add 1000 21da:d3:0:2f3b::7
Added DHCP relay destination address 21da:d3:0:2f3b::7 to Vlan1000
Restarting DHCP relay service...
```

**config vlan dhcp_relay delete**

Usage:
```
config vlan dhcp_relay del <vlan-id> <dhcp_relay_destination_ip>
```
Example:
```
admin@sonic:~$ sudo config vlan dhcp_relay del 1000 21da:d3:0:2f3b::7
Removed DHCP relay destination address 21da:d3:0:2f3b::7 from Vlan1000
Restarting DHCP relay service...
```

**show vlan brief**

Usage:
```
show vlan brief
```
Example:
```
admin@sonic:~$ show vlan brief
+-----------+----------------------+------------+----------------+-----------------------+-------------+
| VLAN ID | IP Address | Ports | Port Tagging | DHCP Helper Address | Proxy ARP |
+===========+======================+============+================+=======================+=============+
| 1000 | 21da:d3:0:2f3b::6/96 | Ethernet28 | untagged | 21da:d3:0:2f3b::6 | disabled |
| | | | | 21da:d3:0:2f3b::7 | |
+-----------+----------------------+------------+----------------+-----------------------+-------------+
```

## 4 Init flow

![DHCPv6 init flow](/doc/DHCPv6_Relay/init.svg)

Binary file added doc/DHCPv6_Relay/diagram.png
View file
Open in desktop
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
3 changes: 3 additions & 0 deletions doc/DHCPv6_Relay/init.svg
View file
Open in desktop
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.