7. Interfaces
7.1. Overview
On the SR Linux, an interface is any physical or logical port through which packets can be sent to or received from other devices.
7.1.1. Interface types
The SR Linux supports the following interface types:
- LoopbackA loopback interface is a virtual interface that is always up, providing a stable source or destination from which packets can always be originated or received. The SR Linux supports up to 256 loopback interfaces system-wide, across all network-instances. Loopback interfaces are named loN, where N is 0 to 255.
- NetworkNetwork interfaces carry transit traffic, as well as originate and terminate control plane traffic and in-band management traffic.The physical ports in line cards installed in the SR Linux are network interfaces. A typical line card has a number of front-panel cages, each accepting a pluggable transceiver. Each transceiver may support a single channel or multiple channels, supporting one Ethernet port or multiple Ethernet ports, depending on the transceiver type and its breakout options.In the SR Linux CLI, each network interface has a name that indicates its type and its location in the chassis. The location is specified with a combination of slot number and port number, using the following formats:ethernet-slot/portFor example, interface ethernet-2/1 refers to the line card in slot 2 of the SR Linux chassis, and port 1 on that line card.
- ManagementManagement interfaces are used for out-of-band management traffic. The SR Linux supports a single management interface named mgmt0.The mgmt0 interface supports the same functionality and defaults as a network interface, except for the following:
- Packets sent and received on the mgmt0 interface are processed completely in software.
- The mgmt0 interface does not support multiple output queues, so there is no output traffic differentiation based on forwarding class.
- The mgmt0 interface does not support pluggable optics. It is a fixed 10/100/1000-BaseT copper port.
- Integrated routing and bridging (IRB)IRB interfaces enable inter-subnet forwarding. Network instances of type mac-vrf are associated with a network instance of type ip-vrf via an IRB interface.
On the SR Linux, each loopback, network, management, and IRB interface can be subdivided into one or more subinterfaces. See Subinterfaces.
7.1.2. Linux interface naming conventions
Every loopback, network, and management interface has an underlying interface in the Linux OS. These interfaces have names that adhere to Linux restrictions (maximum 15 characters and no slashes). The Linux interface name formats are as follows:
- Loopback interfaces: loN, where N is 0 to 255; for example, lo0
- Network interfaces: eslot-port-subinterface; for example, e4-2-1
- Management interface: mgmt0
7.2. Basic interface configuration example
The following example shows a configuration for interface basic parameters, including administratively enabling the interface, specifying a description, and setting the MTU. The settings apply to any subinterfaces on the port, unless overridden in the subinterface configuration.
Example:
7.3. Subinterfaces
7.3.1. Overview
On the SR Linux, each loopback, network, management, and IRB interface can be subdivided into one or more subinterfaces. A subinterface is a logical channel within its parent interface.
Traffic belonging to one subinterface can be distinguished from traffic belonging to other subinterfaces of the same port using encapsulation methods such as 802.1Q VLAN tags.
While each port can be considered a shared resource of the router that is usable by all network-instances, a subinterface can only be associated with one network-instance at a time. To move a subinterface from one network-instance to another, you must disassociate it from the first network-instance before associating it with the second network-instance. See Network-instances.
You can configure ACL policies to filter IPv4 and/or IPv6 packets entering or leaving a subinterface. See Access control lists.
The SR Linux supports policies for assigning traffic on a subinterface to forwarding classes or remarking traffic at egress before it leaves the router. DSCP classifier policies map incoming packets to the appropriate forwarding classes, and DSCP rewrite-rule policies mark outgoing packets with an appropriate DSCP value based on the forwarding class. See Quality of service.
7.3.2. Routed and bridged subinterfaces
SR Linux subinterfaces can be specified as type routed or bridged:
- Routed subinterfaces can be assigned to a network-instance of type mgmt, default, or ip-vrf.
- Bridged subinterfaces can be assigned to a network-instance of type mac-vrf.
Routed subinterfaces allow for configuration of IPv4 and IPv6 settings, and bridged subinterfaces allow for configuration of bridge table and VLAN ingress/egress mapping.
7.3.3. Subinterface naming conventions
The CLI name of a subinterface is the name of its parent interface followed by a dot (.) and an index number that is unique within the scope of the parent interface. For example, the subinterface named ethernet-2/1.0 is a subinterface of ethernet-2/1, and it has index number 0.
- Each loopback interface (loN) can only have one subinterface, and the index number can be in the range 0 to 255.
- Each network interface (ethernet-slot/port) where the vlan-tagging parameter is set to false can have one subinterface, and the index number can be in the range 0 to 9999.
- Each network interface where the vlan-tagging parameter is set to true can have up to 4096 subinterfaces (up ro 1024 of type routed and 3072 of type bridged) with each subinterface assigned a unique index number in the range 0 to 9999.
- The management interface (mgmt0) can only have one subinterface, with an index number of 0.
The Linux name of a subinterface adheres to Linux restrictions (maximum 15 characters and no slashes). For example, the subinterface named ethernet-2/1.0 has the Linux name e2-1.0.
7.3.4. Basic subinterface configuration example
For IPv4 packets to be sourced from a subinterface, the IPv4 address family must be enabled on the subinterface and the subinterface must be configured with an IPv4 address and prefix length that indicates the other IPv4 hosts reachable on the same subnet.
A subinterface can have up to 64 IPv4 prefixes assigned to it. One or more of these can be optionally configured as a primary candidate. Within the set of IPv4 prefixes configured as primary candidates, the lowest IPv4 address that does not fail duplicate address detection is selected as the primary address for the subinterface. The primary address is used by upper layer protocols that need to choose only one IPv4 address from which to source their messages, as well as for information about this interface displayed with the info from state command. If there is no suitable address in the set of IPv4 prefixes configured as primary candidates (or if no IPv4 prefix is configured as primary), a selection is made from the IPv4 prefixes not configured as primary candidates.
For IPv6 packets to be sourced from a subinterface, the IPv6 address family must be enabled on the subinterface, which must be configured with a global unicast IPv6 address and prefix length. The address can be configured statically or obtained from a DHCP server.
A subinterface can have up to 16 global unicast IPv6 addresses and prefixes assigned to it. One or more of these can be optionally configured as a primary candidate. Within the set of IPv6 prefixes configured as primary candidates, the lowest IPv6 address that does not fail duplicate address detection is selected as the primary address for the subinterface. The primary address is used by upper layer protocols that need to choose only one IPv6 address from which to source their messages, as well as for information about this interface displayed with the info from state command. If there is no suitable address in the set of IPv6 prefixes configured as primary candidates (or if no IPv6 prefix is configured as primary), a selection is made from the IPv6 prefixes not configured as primary candidates.
Example:
The following example shows basic parameters for a subinterface configuration, including IPv4 and IPv6 addresses and prefix lengths.
The configuration for subinterface 1 administratively enables the subinterface, specifies an ACL policy for input IPv4 traffic, and specifies a DSCP classifier policy that assigns input IPv4 traffic to a queue based on the 6-bit DSCP value in the IP header.
The configuration for subinterface 2 administratively enables the subinterface, and configures multiple IPv4 and IPv6 addresses and prefix lengths. The primary IPv4 address for the subinterface is selected from among the set of IPv4 prefixes configured as primary candidates; the selected IPv4 address is the numerically lowest address that does not fail duplicate address detection. The global unicast IPv6 address for the subinterface is selected from the IPv6 prefix configured as primary. The selected global unicast IPv6 address is the numerically lowest address that does not fail duplicate address detection.
7.3.5. Subinterface VLAN configuration example
When the vlan-tagging parameter is set to true for a network interface, the interface can accept ethertype 0x8100 frames with one or more VLAN tags. The interface can be configured with up to 4096 subinterfaces, each with a separate index number.
Example:
The following example enables VLAN tagging for an interface and configures two subinterfaces. Single-tagged packets received on subinterface ethernet-2/1.1 are encapsulated with VLAN ID 101.
7.3.6. Bridged subinterface configuration example
Bridged subinterfaces are associated with a mac-vrf network instance.
Example:
The following example shows the configuration for a bridged subinterface.
7.4. IRB interfaces
Integrated routing and bridging (IRB) interfaces enable inter-subnet forwarding. Network instances of type mac-vrf are associated with a network instance of type ip-vrf via an IRB interface.
On SR Linux, IRB interfaces are named irbN, where N is 0 to 255. Up to 4095 subinterfaces can be defined under an IRB interface. An ip-vrf network instance can have multiple IRB subinterfaces, while a mac-vrf network instance can refer to only one IRB subinterface.
IRB subinterfaces are type routed and cannot be configured as any other type.
IRB subinterfaces operate in the same way as other routed subinterfaces, including support for the following:
- IPv4 and IPv6 ACLs
- DSCP based QoS (input and output classifiers and rewrite rules)
- Static routes and BGP (IPv4 and IPv6 families)
- IP MTU (with the same range of valid values as Ethernet subinterfaces)
- All settings in the subinterface/ipv4 and subinterface/ipv6 containers. For IPv6, the IRB subinterface also gets an IPv6 link local address
- BFD
- Subinterface statistics
IRB interfaces do not support sFlow or VLAN tagging.
7.4.1. IRB interface configuration example
The following example configures an IRB interface. The IRB interface is operationally up when its admin-state is enabled, and its IRB subinterfaces are operationally up when associated with mac-vrf and ip-vrf network instances. At least one IPv4 or IPv6 address must be configured for the IRB subinterface to be operationally up.
7.5. Displaying interface information
7.5.1. Displaying interface status
Use the show interface command to display the operational state of configured interfaces.
Examples:
To display the status of all configured interfaces that have operational state up and their subinterfaces that also have operational state up:
To display summary information about interfaces that have operational state up or down:
To display summary information about a specific interface:
To display summary information about interfaces and subinterfaces that have operational state up or down:
To display summary information about a specific interface and its subinterfaces:
To display detailed information about a specific interface and its subinterfaces:
To display information about egress queues and Virtual Output Queues (VOQs) for a specific interface and its subinterfaces:
7.5.2. Displaying interface statistics
To display statistics for a specific interface, use the info from state command in candidate or running mode, or the info command in state mode.
Example:
7.5.2.1. Clearing interface statistics
You can clear the statistics counters for a specified interface.
Examples:
To clear queue statistics for an interface:
To clear statistics for a specified queue on an interface:
7.5.3. Viewing subinterface statistics
To display statistics for a specific subinterface, enter the context for the subinterface and use the info from state command.
Example:
7.5.3.1. Clearing subinterface statistics
You can clear the statistics counters for a specified subinterface.
Example:
7.6. LAG
A Link Aggregation Group (LAG), based on the IEEE 802.1ax standard (formerly 802.3ad), increases the bandwidth available between two network devices, depending on the number of links installed. A LAG also provides redundancy in the event that one or more links participating in the LAG fail. All physical links in a given LAG links combine to form one logical interface.
Packet sequencing is maintained for any given session. The hashing algorithm deployed by SR Linux is based on the type of traffic transported to ensure that all traffic in a flow remains in sequence, while providing effective load sharing across the links in the LAG.
LAGs can be either statically configured, or formed dynamically with Link Aggregation Control Protocol (LACP). Load sharing is executed in hardware, which provides line rate forwarding for all port types. A LAG can consist of ports of the same speed, as well as ports of mixed speed; however, the active links would be only those whose port speed matches the configured member-speed parameter for the LAG instance.
7.6.1. Min-link threshold
SR Linux supports configuring a min-link threshold for a LAG, which sets the minimum number of member links that must be active in order for the LAG to be operationally up. If the number of active links falls below this threshold, the entire LAG is brought operationally down.
If the min-link threshold is crossed, the active member links are maintained, including continuing to run LACP on links where it is configured, but the LAG is held out of forwarding state. Once the number of active links reaches or exceeds the min-link threshold, the LAG is brought back up operationally.
7.6.2. LACP
LACP, defined by the IEEE 802.3ad standard, specifies a method for two devices to establish and maintain LAGs. When LACP is enabled, SR Linux can automatically associate LACP-compatible ports into a LAG. All non-failing links in a LAG are active, and traffic is load-balanced across the active links.
When LACP is enabled, LACP changes are visible through traps and log messages logged against the LAG.
7.6.2.1. LACP fallback
LACP fallback allows one or more designated links of an LACP controlled LAG to go into forwarding mode if LACP is not yet operational after a configured timeout period.
SR Linux supports LACP fallback in static mode. In static mode, a single designated LAG member goes into forwarding mode if LACP is not operational after the timeout period.
LACP fallback is configured by selecting the mode and fallback timeout (seconds). If the LAG receives no PDUs and the timeout period expires, the configured fallback mode is enabled. If any member link in the LAG receives a PDU, the fallback mode is immediately disabled.
7.6.3. Configuring LAGs
To configure a LAG, you specify LAG parameters within the context of a LAG interface, then associate Ethernet interfaces with the LAG interface.
The MAC address of the LAG should be a unique value taken from the chassis MAC address pool.
Member links in the LAG can be associated statically or dynamically.
- Static links are explicitly associated with the LAG within the configuration of the LAG instance.
- Dynamic links are associated with the LAG using LACP.
A LAG instance can consist of static links only or dynamic links only.
If an Ethernet interface is associated with a LAG interface, the following parameters must be the same for all associated Ethernet ports:
- flow-control
- port-speed
- aggregate-id
Example:
The following example shows the configuration for a LAG consisting of three member links.
7.6.3.1. Configuring the min-link threshold
The min-link threshold specifies the minimum number of member links that must be active in order for the LAG to be operationally up. If the number of active links falls below this threshold, the entire LAG is brought operationally down.
Example:
The following example configures the min-link threshold for a LAG to be 4. If the number of active links in the LAG drops below 4, the LAG is taken operationally down.
After the LAG has been taken operationally down due to crossing the min-link threshold, if the number active links in the LAG subsequently reaches 4 or higher, the LAG is brought operationally up. The default for the min-link threshold is 0 (disabled).
7.6.3.2. Configuring LACP and LACP fallback
When LACP is enabled, SR Linux can automatically associate LACP-compatible ports into a LAG. LACP should be configured in ACTIVE mode only if LACP Fallback is also configured.
Example:
The following example configures LACP to run on an interface, which can dynamically become a member of a LAG:
In this example, the LACP interval is set to FAST, which causes LACP messages to be sent every second. The SLOW option for LACP interval causes LACP messages to be sent every 30 seconds.
Example:
The following example enables LACP fallback mode for a LAG, which allows a single designated LAG member to go into forwarding mode if LACP is not operational after the timeout period.
The LACP fallback timeout range is 4 to 3600 seconds when the LACP interval is FAST, and 90 to 3600 seconds when LACP interval is SLOW.
Example:
The following example enables LACP port priority. When LACP fallback is triggered in static mode, one of the member-links goes into a forwarding state which can be influenced using LACP port priority.
7.6.4. Displaying LAG interface statistics
To display statistics for a LAG interface, use the info from state command in candidate or running mode, or the info command in state mode.
Example:
7.6.4.1. Clearing LAG interface statistics
You can clear the statistics counters for a specified LAG interface.
Examples:
To clear statistics for a LAG interface and all member links:
7.7. DHCP relay
DHCP relay refers to the router’s ability to act as an intermediary between DHCP clients requesting configuration parameters, such as a network address, and DHCP servers when the DHCP clients and DHCP servers are not attached to the same broadcast domain, or do not share the same IPv6 link (in the case of DHCPv6).
SR Linux supports DHCP relay for IRB subinterfaces and Layer 3 subinterfaces. The DHCP servers must reside in the same IP-VRF network instance as the subinterface where the DHCP relay is enabled. SR Linux supports up to 8 DHCP or DHCPv6 servers. The DHCP relay maximum packet size (including option 82 and vendor-specific options) is capped at 1500 bytes to avoid fragmentation on the ethernet segment end attached to the DHCP server.
When DHCP relay is enabled for a subinterface, and a DHCP client initiates a request for configuration parameters, the router accepts the DHCP client’s request and relays it to the remote DHCP server, which sends back the configuration parameters. The router relays the configuration parameters to the client. Figure 1 shows an example of DHCP and DHCPv6 on IRB and Layer 3 subinterfaces.
SR Linux supports DHCP relay for IPv4 and IPv6. This guide refers to DHCP for IPv4 as DHCP, and DHCP for IPv6 as DHCPv6.
Figure 1: DHCP relay for IRB and Layer 3 subinterfaces
7.7.1. DHCP relay for IPv4
When DHCP relay is enabled, the router intercepts DHCP broadcast packets and unicasts them to a specified DHCP server for handling. By default, the source address for DHCP packets relayed to the server (GIADDR) is the IP address of the ingress subinterface where the DHCP relay agent is enabled, although a different GIADDR can be specified if necessary.
SR Linux supports DHCP option 82, the Relay Information Option, specified in RFC 3046, which allows the router to append information to DHCP requests relayed to the DHCP server, identifying where the original DHCP request came from. DHCP option 82 includes two sub-options: circuit-id and remote-id.
When configured to do so, SR Linux includes the following information in the circuit-id and remote-id sub-options of DHCP option 82:
- For circuit-id, the system_name/VRF_instance/sub-interface_id:vlan_id of the ingress subinterface where the relay agent is enabled that receives the DHCP Discover message from the DHCP client.
- For remote-id, the MAC address of the DHCP client.
Figure 2 shows an example of the discovery, offer, request, and acknowledgment (DORA) message flow that occurs when DHCP relay assigns an address to a DHCP client.
Figure 2: DHCP message flow for IPv4 address allocation
The DORA message flow shown in Figure 2 works as follows:
- The DHCP client sends a DHCP Discover (broadcast) message with the following values:
- DA = FF:FF:FF:FF:FF:FF (broadcast)
- SA= client MAC
- SIP = 0.0.0.0
- DIP = 255.255.255.255
- Source UDP port = 68
- Destination UDP port = 67
The DHCP payload has the following values:- Broadcast flag = 1 (broadcast) or 0 (unicast)
- Relay agent IP = 0.0.0.0
- Client MAC = mac1
- Parameter request list (option 55) which lists the required items from the DHCP server to be sent along with the IP address like subnet mask, router (gateway), and others
- The DHCP relay agent relays the DHCP Discover message towards the DHCP server (unicast). If configured to do so, information is added for the circuit ID and remote ID sub-options in DHCP option 82. The relayed packet is unicasted towards the DHCP server(s) with the following values:
- SIP = outgoing interface IP address by default.If the source-address is configured the relayed packet instead will have SIP = configured source-address
- UDP source port = 67
- UDP destination port = 67
The DHCP payload has the following values:- Broadcast = 1 (broadcast) or 0 (unicast)
- Relay agent IP (giaddr) = IP address of the ingress sub-interface where the relay agent is enabled
- Client MAC = mac1
- Relay agent information (option 82)
- The DHCP server assigns an IP address to the DCHP client, based on information in the GIADDR or in option 82, if configured to do so. The DHCP server sends a DHCP Offer message to the DHCP relay agent (unicast). The DHCP Offer message includes the IP address assigned to the DHCP client based on information in the GIADDR or in option 82.The DHCP Offer packet is unicasted with the following values:
- SIP = DHCP IP address
- DIP = giaddr
- UDP source port = 67
- UDP destination port = 67
The DHCP payload has the following values:- Broadcast flag = 1 (broadcast) or 0 (unicast).
- Your (client) IP = IP address assigned by DHCP server
- Agent IP = giaddr
- Client MAC = mac1
- DHCP identifier = DHCP server IP address
- Option 82 (echoed back, and based on DHCP server configuration)
- IP address Lease time (option 51)
- Subnet mask (option 1)
- Router (gateway) (option 3)
- Others (DNS, Renewal Time value, Rebinding Time value, and so on)
- The DHCP relay agent relays the DHCP Offer message to the DHCP client (either broadcast or unicast, based on the broadcast flag sent by the client).The DHCP Offer message is relayed from the DHCP server(s) towards the client with the following values:
- DA = FF:FF:FF:FF:FF:FF (broadcast) OR Client MAC(unicast)
- SIP = sub-interface IP address towards client where DHCP relay agent is enabled
- DIP = 255.255.255.255 (broadcast) OR Your (client) IP address (unicast)
- Source UDP port = 67
- Destination UDP port = 68.
The relay agent relays the DHCP Offer towards the client without option 82. It strips off option 82 if echoed back from DHCP server.The DHCP payload has the following values:- Broadcast flag = 1 (broadcast) or 0 (unicast).
- Your (client) IP = IP address assigned by DHCP server
- Agent IP = giaddr
- Client MAC = mac1
- DHCP identifier = DHCP server IP address
- Option 82 (echoed back, and based on DHCP server configuration)
- IP address Lease time (option 51)
- Subnet mask (option 1)
- Router (gateway) (option 3)
- Others (DNS, Renewal Time value, Rebinding Time value, and so on.)
- The DHCP client sends a DHCP request message (broadcast) with the following values:
- DA = FF:FF:FF:FF:FF:FF (broadcast)
- SA = client MAC
- SIP = 0.0.0.0
- DIP = 255.255.255.255
- Source UDP port = 68
- Destination UDP port = 67
The DHCP payload has the following values:- Broadcast flag = 1 (broadcast) or 0 (unicast).
- Relay agent IP = 0.0.0.0
- Client MAC = mac1
- DHCP server identifier = DHCP server IP address
- Requested IP (option 50)
- Parameter request list (option 55) that lists the required items from the DHCP server to be sent along with the IP address like subnet mask, router (gateway), and others
- The DHCP relay agent relays the DHCP Request message towards the DHCP server (unicast). The relayed packet is unicasted towards the DHCP server(s), with the following values:
- SIP = outgoing interface IP address by default. If source-address is configured, then the relayed packet will have SIP = configured source-address.
- UDP source port = 67
- UDP destination port = 67
The DHCP payload has the following values:- Broadcast flag = 1 (broadcast) or 0 (unicast).
- Relay agent IP = giaddr
- Client MAC = mac1
- DHCP identifier = DHCP server IP address
- Requested IP (option 50)
- Relay agent Information (option 82) if configured under dhcp-relay
- Parameter request list (option 55) that lists the required items from the DHCP server to be sent along with the IP address like subnet mask, router (gateway), and others
- Vendor specific option (if configured)
- The DHCP server sends a DHCP Ack message to the DHCP relay agent (unicast). The DHCP Ack packet is unicasted with the following values:
- SIP = DHCP IP address
- DIP = giaddr
- UDP source port = 67
- UDP destination port = 67
The DHCP payload has the following values:- Broadcast flag, either 1 (broadcast), or 0 (unicast)
- Your (client) IP = IP address assigned by DHCP server
- Agent IP = giaddr
- Client MAC = mac1
- DHCP identifier = DHCP server IP address
- Option 82 (echoed back and based on DHCP server configuration)
- IP address Lease time (option 51)
- Subnet mask (option 1)
- Router (gateway) (option 3)
- Others (DNS, Renewal Time value, Rebinding Time value, and so on.)
- Based on the broadcast flag sent by client, the DHCP Offer is relayed from the DHCP server(s) towards the client with the following values:
- DA = FF:FF:FF:FF:FF:FF (broadcast) OR Client MAC(unicast)
- SIP = sub-interface IP address towards client where DHCP relay agent is enabled
- DIP = 255.255.255.255 (broadcast) OR Your (client) IP address (unicast)
- Source UDP port = 67
- Destination UDP port = 68
The relay agent relays the DHCP Offer towards client without option 82. It strips off option 82 if echoed back from DHCP server.The DHCP payload has the following values:- Broadcast flag can be either 1 (broadcast), or 0 (unicast)
- Your (client) IP = IP address assigned by DHCP server
- Agent IP = giaddr
- Client MAC = mac1
- DHCP Server identifier (option 54) = DHCP server IP address
- IP address lease time (option 51)
- Subnet mask (option 1)
- Router (gateway) (option 3)
- Others (DNS, Renewal Time value, Rebinding Time value, and so on.)
When renewing or releasing an address, the DHCP client unicasts the DHCP Request or Release message to the DHCP server without involvement by the DHCP relay agent.
7.7.1.1. Configuring DHCP relay for IPv4
To configure DHCP relay for a subinterface:
- Configure the addresses of the DHCP servers.
- Optionally configure the source address for DHCP messages sent to the servers
- Configure whether information is added to the sub-options for DHCP option 82
Example:
The following example configures the DHCP relay agent on a subinterface. The example configures the IP addresses of the remote DHCP servers and specifies the address to be used as the GIADDR in packets sent to the servers
The circuit-id and remote-id options are configured, which causes the DHCP relay agent to include the system_name/VRF_instance/sub-interface_id:vlan_id in the circuit-id sub-option and the DHCP client MAC address in the remote-id sub-option of DHCP option 82.
7.7.1.2. Using the GIADDR as the source address for DHCP Discover/Request packets
By default, the SR Linux uses the IP address of the outgoing interface as the source address for Discover/Request packets sent to the DHCP server. This is not the desired behavior for some configurations, such as a firewall protecting the DHCP server that allows connections from a limited set of IP addresses. You can use the use-gi-addr-as-src-ip-addr parameter to cause the SR Linux to instead use the GIADDR as the source address for Discover/Request packets sent to the DHCP server.
Table 11 shows the GIADDR and source address combinations.
Table 11: GIADDR and source address combinations
gi-address parameter | use-gi-addr-as-src-ipaddr parameter | GIADDR in relayed packet | Source IP address in relayed packet |
Not configured (default) | False (default) | Primary IP addressof interface | IP address ofoutgoing interface |
Configured | False (default) | Configured GIADDR | IP address ofoutgoing interface |
Configured | True | Configured GIADDR | Configured GIADDR |
Not configured (default) | True | Primary IP addressof interface | Primary IP address ofinterface (because it ispicked as the GIADDR) |
Example:
In this example, the address specified with the gi-address parameter is used as the source address for Discover/Request packets sent to the DHCP server. If the gi-address parameter is not configured, then the default GIADDR (the primary IP address of the interface) is used.
7.7.1.3. Trusted and untrusted DHCP requests
If the DHCP relay agent receives a DHCP request and the downstream node added option 82 information or set the GIADDR to any value other than 0, the DHCP request is considered to be untrusted. By default, the router drops any untrusted DHCP request and discards the DHCP packets, as described in RFC 3046. SR Linux supports untrusted mode only.The DHCP relay agent discards DHCP packets traveling from the client to server side under the following conditions:
- The DHCP packet includes option 82.
- The DHCP packet has a GIADDR value that is not 0.
The DHCP relay agent discards DHCP packets traveling from the server to client side under the following conditions:
- The circuit-id or remote-id are not enabled on the relay interface, but are present in the packet.
- the GIADDR value in the DHCP packet does not match the GIADDR value on the relay interface.
- There is no matching entry in the cache.
7.7.2. DHCP relay for IPv6
DHCP relay for IPv6 works similarly to IPv4. However, in DHCPv6, the DHCP Discover, Offer, and Ack messages are replaced by Solicit messages sent by clients, and Advertise and Reply messages sent by servers.
The DHCPv6 relay agent relays messages between clients and remote servers using Relay-Forward (client-to-server) and Relay-Reply (server-to-client) message types. DHCP option 82 is replaced in DHCPv6 by Interface-Id (option 18) and Remote Identifier (option 37), appended by relay agents.
Figure 3 shows the DHCPv6 message flow. Figure 4 and Figure 5 show the renew and release flows.
Figure 3: DHCPv6 message flow for IPv6 address allocation
When assigning an address to a DHCP client, DHCP relay for IPv6 works as follows:
- The DHCPv6 client uses its link-local address as the source IPv6 address and IPv6 multicast address FF02::1:2 and MAC address 33:33:00:01:00:02 as destination IPv6 address/MAC address respectively for solicit/request messages and with the following UDP values:
- source UDP port = 546
- destination UDP port = 547
- The DHCPv6 relay agent uses a Relay-Forw message to relay the Solicit message towards the DHCPv6 server, using the outbound IPv6 address of the DHCPv6 relay agent as the source IPv6 address and with the following UDP values:
- Source UDP port = 547
- Destination UDP port = 547
- The DHCPv6 server replies to the relay agent an IP address to the DCHP client, based on information in the GIADDR or in option 82, if configured to do so, and with the following UDP values:
- Source UDP port = 547
- Destination UDP port = 547
- The DHCPv6 server replies to the relay agent with destination IPv6 address equal to DHCPv6 (RELAY-FW) source IPv6 address, and the following UDP values:
- Source UDP port = 547
- Destination UDP port = 547
- The DHCP relay agent relays the DHCP Offer message to the DHCP client (either broadcast or unicast, based on the broadcast flag sent by the client).
Figure 4: DHCPv6 renew message flow
Figure 5: DHCPv6 release message flow
7.7.2.1. Configuring DHCP relay for IPv6
To configure DHCP relay for a subinterface for IPv6:
- Configure the addresses of the DHCPv6 servers.
- Optionally configure the source IPv6 address for DHCP messages sent to the servers.
- Configure whether information is included in the Interface-Id (option 18) and Remote Identifier (option 37).
Example:
The following example configures the DHCPv6 relay agent on a subinterface. The example configures the IP addresses of the remote DHCPv6 servers and specifies the address to be used as the source IPv6 address in packets sent to the servers.
The circuit-id and remote-id options are configured, which causes the DHCP relay agent to include the system_name/VRF_instance/sub-interface_id:vlan_id in Interface-Id (option 18) DHCPv6 client MAC address in the Remote Identifier (option 37).
7.7.3. QoS for DHCP relay
Self-generated DHCP/DHCPv6 packets are mapped into forwarding class 4 (fc4), low drop probability level, and DSCP marking 34 (AF41).
7.7.4. DHCP relay operational down reasons
The DHCP relay agent can enter an operationally down state in the following scenarios:
- The DHCP relay admin state is down.
- The subinterface under which DHCP relay is configured is operationally down.
- All DHCP servers configured within the network instance are unreachable.
- The configured GIADDR for DHCP, or source-address for DHCPv6, does not match any of the configured IP addresses under the subinterface where DHCP relay is configured
- The IP address is deleted under the subinterface.
7.7.5. Displaying DHCP relay statistics
To display DHCP relay statistics, use the info from state command in candidate or running mode, or the info command in state mode.
IPv4 example:
IPv6 example:
7.7.5.1. Clearing DHCP relay statistics
You can clear the DHCP relay statistics counters for a specified subinterface.
Example: