In enterprise networks, many protocols like DHCP only communicate in a single layer 3 (or broadcast) domain. However, it may become unpractical to provision a unit running a service such as this in each individual subnet that they need to communicate with and service. In this case, UDP relay and DHCP relay can be used on an AOS unit to act as a relay and transmit the local layer 3 traffic from one domain to the domain the service resides in. This document covers the instances when you should use UDP relay and DHCP relay and how to configure and troubleshoot these features.
Sections Included in this Document
Hardware and Software Requirements
Configuration using the AOS Web Interface
Hardware and Software Requirements
UDP relay is available on all AOS platforms as shown in the AOS Feature Matrix - Product Feature Matrix. UDP relay and using the AOS unit as a DHCP server are mutually exclusive features.
As of Firmware version 18.03.01, DHCP relay was added on all AOS products. This feature can used in conjunction with the DHCP server feature.
For more information on Firmware Release naming concepts, please see AOS Firmware Release Naming Conventions.
UDP relay should be required when an application that is confined to a single broadcast domain/subnet must be forwarded to another device, like a server, in a different broadcast domain. Normally this application will utilize a Layer 2 multicast or broadcast method of communication which would not exit a broadcast domain and therefor could not reach the remote device. With UDP relay enabled, when these messages are received by the AOS unit, they are forwarded to a configured remote address substituting the source IP address as the AOS unit. When the remote device responds, the AOS unit receives the traffic and responds back to the original device. Consider the following example:
In the above network, the user's phone uses multicast communication to discover an Network Time Protocol (NTP) server in which to update its time with. However, the NTP server in the network is located on the 192.168.1.0/24 subnet. Without UDP relay, the phone's time server will never update because the multicast messages are not transmitted across the router's layer 3 interfaces. However, if UDP Relay is configured on the interface in the phone's subnet, the messages from the phone will be relayed to the NTP server. Once it responds, the router will relay the responses back to the phone and its time will update. This can be used with any messages that carry a UDP protocol.
DHCP is required in the same scenario as shown above, except with DHCP. DHCP uses broadcast messages to communicate between server and client which do not transmit across broadcast domains. With DHCP relay, these messages are received by the router and then sent as Unicast packets to the remote DHCP server.
While UDP relay can be used to relay DHCP as well, it is recommended to use DHCP relay because it requires less configuration and is capable of running in any VRF. DHCP Relay was introduced to AOS in version 18.03.01. You must be running this version or higher to utilize this feature.
Configuration using the AOS Web Interface
Currently AOS only support UDP Relay and DHCP Relay using IPv4.
To configure UDP relay, navigate to the "Data" section on the left menu in the AOS web interface. Here, click on "UDP Relay" and you will see the place to insert a UDP protocol to be forwarded as shown below:
Here, click the drop down to select the type of UDP protocol. By default, it is set to "specified" meaning that you will specify it by port number. There are many named protocols listed in the drop down menu to use instead of specified, like NTP. Using our original NTP example, NTP would be selected and then press "Add":
Once you have done this, on the same page there is a section called "IP Helper Address". Here, input the IP address that the traffic needs to be forwarded to and then select the drop down for which interface to apply this to. Once finished, press "Add" as shown below:
In this example, we are forwarding NTP to 10.10.10.1. Once this is configured, UDP should be functional.
Note that you can only have one IP Helper Address per interface.
At this time, DHCP relay can only be configured using the AOS CLI. Please navigate to the section Configuring DHCP Relay.
To initially verify configuration, make sure your selections are present after you press "Add" in both sections, and that the information is correct. To further verify the configuration, test the application to see if it is running correctly. If it is not functioning, see the section named Troubleshooting.
Currently AOS only support UDP Relay and DHCP Relay using IPv4.
Just as in the AOS Web Interface, there are two requirements to enable UDP relay: Selecting the UDP port to forward and adding an IP Helper Address to the applicable interface (the interface of which the application is used).
To enable UDP relay for a particular port, use the ip forward-protocol udp { <protocol name> | <UDP port number> | <range of UDP ports> } command:
(config)#ip forward-protocol udp ntp
(config)#ip forward-protocol udp 10000
The first command above enables UDP Relay for NTP packets received on that interface. It is important to note that this will only affect traffic that is destined for the router itself and not through traffic (multicast and broadcast traffic would technically be destined for the router). There are many more protocols that can be configured. For a full list, use the context sensitive help by typing ? after you put in the beginning of the command ip forward-protocol udp. The second command enables UDP Relay for UDP port 10000. The third command enables UDP relay for a range of ports from 20000 to 20002.
Remember that if "bootps" is used here, the DHCP server feature will not function nor be configurable. Similarly, if the AOS unit is already configured to be a DHCP server, the command to forward bootps will be rejected. ADTRAN recommends using the DHCP relay feature to forward DHCP.
Before the UDP traffic will be relayed, an IP helper address must be added to an interface this traffic will enter on, specifying an IP address to relay the traffic to. Use the interface level ip helper-address <ip address> command as shown below:
(config)#interface eth 0/1
(config-eth 0/1)#ip helper-address 10.10.10.1
Now all traffic that matches an ip forward-ptocol udp command from above that enters on Eth 0/1 will be relayed to 10.10.10.1.
To configure DHCP relay, use the interface level command ip dhcp relay destination <ip address> command:
(config)#interface eth 0/1
(config-Eth 0/1)#ip dhcp relay destination 10.10.10.1
The above configuration configures the router to relay all DHCP traffic received on the eth 0/1 interface to be relayed to 10.10.10.1. Note that this command can be enabled on an interface in a non-default VRF without extra configuration.
Below is an example of a sample configuration to enable UDP relay:
ip forward-protocol udp <input>
ip forward-protocol udp <input>
!
interface eth 0/1
ip helper-address <ip address>
To use the above configuration, insert your specific protocols or port numbers to be relayed (you can add as many lines of the ip forward-protocol udp command as you want) as well as the ip address which will be the ip helper-address. Note that you may have to also change the interface depending on the type and number.
Below is an example of a sample configuration to enable UDP relay:
(config)#interface eth 0/1
(config-Eth 0/1)#ip dhcp relay destination <ip address>
To use the above configuration, add the IP address of your DHCP server to the relay command. You may also have to specify a different interface to configure this on.
To verify the unit is configured properly, use the command show running-config | include forward-protocol :
#show running-config | include forward-protocol
ip forward-protocol udp ntp
ip forward-protocol udp 10000
ip forward-protocol udp 20000-20002
After verifying that the traffic to be relayed is specified properly, use the show running-config interface <type> <slot/port | number> | include helper command to confirm the helper-address is configured on the interface.
#show running-config interface eth 0/1 | include helper
ip helper-address 10.10.10.1
To verify that the traffic is being relayed properly, test the application. If it does not function correctly, proceed to the section below.
All troubleshooting must be done using the AOS CLI. If you need help accessing this guide, please see the document Accessing the Command Line Interface in AOS.
To troubleshoot UDP relay, use the debug ip udp command. Note that this may show a very verbose amount of traffic if there are a lot of UDP sessions routing to the unit. An example of the output if you were forwarding TFTP, which is UDP port 69, to another server with an IP address of 1.1.1.1 is shown below:
18:18:21: RX: src=172.22.68.48:54248, dst=10.19.233.1:69, 39 bytes
18:18:21: TX: src=172.22.68.48:54248, dst=1.1.1.1:69, 39 bytes
As you can see above, the packet from 172.22.68.48 was received using destination UDP port 69, and then you see the second message shows the destination changed to 1.1.1.1 with a destination of UDP 69. If the debug is not showing the traffic forwarded, check your configuration and make sure that the unit initiating the connection is communicating properly.
To troubleshoot DHCP relay, use the debug ip dhcp relay command. An example of the output is shown below:
2013.10.01 18:29:34 DHCP.RELAY relaying BootpRequest to 10.19.233.254
2013.10.01 18:29:34 DHCP.RELAY forwarding BootpReply to 10.19.233.28
As you can see from the above, the initial DHCP message is relayed to the configured server, 10.19.233.254 in this case. When it responds, we forward that reply back to the original client (in this case offering 10.19.233.28). If you do not see the first message, this could mean that the client is not correctly asking for DHCP, or the configuration is incorrect. Verify the configuration using this document again and, if needed, take a packet capture on the client.
If you do not see the second message indicating the server has replied, contact the administrator of the server the DHCP messages are being forwarded to.
If you see both messages above, but the client is still not getting an IP address, a packet capture on the client is needed.
For more information about configuring DHCP, please see the document Configuring DHCP in AOS.
For more information about multi-vrf operation, please see the document Configuring Multi-VRF in AOS.
