IPoE server

Overview

IPoE is a common method of enabling devices to connect to a network, inspired by the PPPoE protocol but offering a simpler approach. Similar to PPPoE, IPoE establishes a session between an end device and an ISP equipment, wich must remain active for the data to pass through. Unlike PPPoE, which inserts a special header between the Ethernet and IP layers to carry session information, IPoE allows the traffic to remain unaltered. As a result, the MTU stays the same because there is no additional header to reduce the available payload.

The IPoE session is set up using a standard DHCP handshake process, consisting of the DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and DHCPACK phases, and is maintained through DHCP lease renewals. The session will terminate if the DHCP exchanges cease, specifically when the IP address lease expires. To ensure that the session activities closely mirrors the activity of end devices, administrators should configure DHCP lease timers to last only a few minutes.

Advantages of Deploying an IPoE Design Over a Conventional DHCP Approach

Implementing IPoE technology on a network offers two key advantages when compared to a DHCP-only network design: in terms of IP address allocation and enhanced security.

Firstly, when operating in IPoE mode, DHCP distributes host addresses associated with a /32 mask. By contrast, in conventional DHCP designs, IP addresses and subnet masks are assigned within the local subnet , which sets the limit on the number of hosts that can simultaneously communicate with the network in its Ethernet domain. When demand increases, an important administrative task arises: the subnet and its pool of IP addresses must be reassigned. The main advantage of the 32-bit mask associated with IP addresses is that these addresses are not tied to a specific subnet. This simplifies network management by enabling a centralized global pool of IP addresses on the DHCP servers, which can grant leases to devices regardless of their geographical location.

Secondly, if the session expires, the end device is prevented from connecting to the network, even if it still retains its IP address from the expired DHCP lease. This is because the connectivity of the IPoE session relies on a route that is deleted at the end of the session. In a pure DHCP design, this level of security is not possible, as the relay agent router lacks the information needed to block traffic based on the DHCP lease status of individual IP addresses. In other terms, IPoE adds a layer of security by ensuring that only DHCP-authorized IP addresses are allowed network access.

IPoE DHCP relay

When DHCP clients start requesting IP addresses, they transmit a DHCPDISCOVER message. This message is a broadcast that targets all devices on the local subnet. Since routers inherently prevent broadcasts from reaching other subnets, the DHCP server must implicitly reside in the same local Ethernet domain, unless an intermediate delivery mechanism is in place.

In many large networks, it is neither possible nor efficient to have a DHCP server on every Ethernet segment. Organizations therefore prefer to have centralized DHCP servers serving multiple sites. Often, these servers are not on the same Layer 2 domain as the clients they serve. This is where the DHCP relay agent comes into play, acting as an intermediary to forward client broadcast requests to one or more servers, and reciprocally retransmit server responses back to clients. The Virtual Service Router’s IPoE server solution only supports the use of DHCP as a relay agent.

Note

IPoE has not been described in a specific standard. It takes advantage of the DHCP protocol and its relay agent function that are described in RFC 2131 and RFC 2132.

Configuration

By default, the IPoE server is disabled. Through the CLI you can enable an IPoE server on a given VRF.

Here is a configuration example, illustrated by the following figure, where an IPoE server is enabled over an Ethernet connection using the interface eth1 and eth2. The use of l3vrf is optional.

The interfaces are configured as follows:

router running config# / vrf main l3vrf vrf1
router running l3vrf vrf1#! table-id 10
router running l3vrf vrf1# interface physical eth1 ipv4 address 10.1.1.1/32
router running l3vrf vrf1#! interface physical eth1 port pci-b0s4
router running l3vrf vrf1# interface loopback agentvrf1 ipv4 address 10.2.1.1/32
router running l3vrf vrf1# /
router running config# vrf main l3vrf vrf2
router running l3vrf vrf2#! table-id 20
router running l3vrf vrf2# interface physical eth2 ipv4 address 10.1.2.1/32
router running l3vrf vrf2#! interface physical eth2 port pci-b0s5
router running l3vrf vrf2# interface loopback agentvrf2 ipv4 address 10.2.2.1/32
router running l3vrf vrf2# commit
Configuration committed.

Then the IPoE functionality itself:

router running config# / vrf main ipoe-server
router running ipoe-server# enabled true
router running ipoe-server# log-level warning
router running ipoe-server# dhcp-relay interface eth1
router running interface eth1#! router 10.1.1.1
router running interface eth1#! server 172.16.0.1
router running interface eth1#! server 172.16.0.2
router running interface eth1#! agent-information
router running agent-information#! relay-address 10.2.1.1
router running agent-information# trusted-circuit false
router running agent-information# remote-id global ETH1-XVZ4
router running agent-information# link-selection 10.1.1.1
router running agent-information# ..
router running interface eth1# ..
router running dhcp-relay# interface eth2
router running interface eth2#! router 10.1.2.1
router running interface eth2#! server 172.16.0.1
router running interface eth2#! server 172.16.0.2
router running interface eth2#! agent-information
router running agent-information#! relay-address 10.2.2.1
router running agent-information# trusted-circuit false
router running agent-information# remote-id global ETH2-XVZ4
router running agent-information# link-selection 10.1.2.1
router running agent-information# commit
Configuration committed.

The relay agent’s interface address is advertised to the clients as their default route gateway, via the router option. The interface uses a 32-bit mask, which is appropriate as there is no actual subnet associated with it. The address of the relay agent is specified by the relay-address, also known as GIADDR. The server IPs refer to the addresses of the DHCP servers. Details about relay-address, remote-id and link-selection utilization are provided later in the document.

The router option and the server list can be configured at both dhcp-relay and the interface level. If no specific interface value is set, the dhcp-relay setting is used by default. dhcp-relay options are the default values when no interface values are specified. For example, the above configuration is equivalent to the following one:

router running config# / vrf main ipoe-server
router running ipoe-server# enabled true
router running ipoe-server# log-level warning
router running ipoe-server# dhcp-relay
router running dhcp-relay# router 10.1.1.1
router running dhcp-relay# server 172.16.0.1
router running dhcp-relay# server 172.16.0.2
router running dhcp-relay# interface eth1
router running interface eth1#! agent-information
router running agent-information#! relay-address 10.2.1.1
router running agent-information# trusted-circuit false
router running agent-information# remote-id global ETH1-XVZ4
router running agent-information# link-selection 10.1.1.1
router running agent-information# ..
router running interface eth1# ..
router running ipoe-server# interface eth2
router running interface eth2#! router 10.1.2.1
router running interface eth2#! agent-information
router running agent-information#! relay-address 10.2.2.1
router running agent-information# trusted-circuit false
router running agent-information# remote-id global ETH2-XVZ4
router running agent-information# link-selection 10.1.2.1
router running agent-information# commit
Configuration committed.

See also

Please refer to IPoE server command reference for the complete list of supported options.

Agent Information: GIADDR and DHCP option 82

The DHCP relay agent writes the value of relay-address into the DHCP GIADDR header of the end device DHCP request and retransmits the packet to the designated servers from the relay-agent-address source IP address. If another relay agent subsequently receives this packet, the source IP address of the packet is changed, but the GIADDR header remains the same.

Known as “Relay Agent Information”, DHCP option 82, specified in RFC 3046, can provide additional context on the relay agent. If the DHCP request does not yet contain the GIADDR and option 82, the relay agent can optionally insert this information if either the remote-id or link-selection parameters are set.

The remote-id global option sets sub-option 2 of option 82. It globally identifies remote end devices through a specific string.

On the other hand, the link-selection option refers to sub-option 5 of option 82 which is detailed in RFC 3527. Its purpose is to provide the DHCP servers with the IP address of the IPoE server interface, especially when this address differs from the GIADDR.

The DHCP GIADDR header and DHCP option 82 can help DHCP servers determine the appropriate pool for IP address allocation. They are also frequently used to log the IP address locations.

The trusted-circuit parameter determines whether the relay agent should forward DHCP requests that already transited via a relay agent, either with a valid GIADDR header or with DHCP option 82. By default, the value is false, meaning these requests are considered as untrusted. This prevents the relay agent from forwarding DHCP requests containing authentic or fake information about the agent. If the paramater is set to true, incoming DHCP requests are accepted and forwarded, provided their GIADDR header does not spoof the local GIADDR value.

DHCP Client’s identification of the Router and Relay Agent

The DHCP option 54, referred to as the “Server Identifier”, is set by the DHCP server to include its own IP address in the responses it sends. A standard relay agent transmits this option unaltered. Subsequently, following the DHCP lease’s initialization, the DHCP client interacts directly with the DHCP server, bypassing the DHCP relay agent. However, since the IPoE relay is designed to forward all DHCP interactions to preserve IPoE sessions, it swaps the “Server Identifier” in option 54 with its own IP address. Inversely, the relay agent replaces the “Server Identifier” value in client requests with the real server IP. The router setting determines the IP address that the relay should present to clients via DHCP option 54. If this setting is undefined, the system automatically defaults to a local IP address.

The DHCP option 3, known as the “Router” option, serves to provide the end device with a default gateway. The router setting determines the value that is set in DHCP option 3. Any pre-existing option 3 value from the DHCP server is substituted with this router setting. If left unspecified, the relay agent retains the original value of option 3.

Multiple DHCP servers

The relay agent forwards incoming DHCP requests to one or more IP addresses, designated by the server parameter. When there are several DHCP servers, the relay agent may receive several DHCPOFFER responses to a single DHCPDISCOVER. It always chooses the first DHCPOFFER it receives and ignores the others, thus ensuring that devices receive only one DHCPOFFER. According to RFC 2131, a device is supposed to see all these DHCPOFFERs and select one of them. It indicates its choice by sending a DHCPREQUEST to the server defined in option 54 “Server identifier”. However, this is not possible with IPoE. This is because option 54 is modified to indicate the IP of the relay agent, making it difficult for the relay agent to recognize the device’s choice among all the DHCPOFFERs. Fortunately, this rarely poses an issue. Generally, all offers are similar so there is no real benefit in choosing one over the other. Moreover, when DHCP servers operate in active-passive mode, this specific behavior does not matter since just one DHCPOFFER is sent out. For active-active DHCP servers setup, the lease load distribution among servers is effectively unchanged since most DHCP clients nowadays constantly select the first DHCPOFFER they receive.

Considerations for IPoE Host Routing and ARP

The IPoE relay agent creates an individual /32 kernel route for every connected IPoE hosts, directing traffic to the IPoE server interface. It removes it at the session termination. This specific route allows the local Virtual Service Router to identify which interface corresponds to a particular host. Additionally, this route can be propagated across the network using dynamic routing protocols like BGP, OSPF, or IS-IS.

To communicate with the IPoE host situated behind the interface identified by the /32 route, the Virtual Service Router employs ARP, creating an IPv4 neighbor entry for each IPoE host. There is a default limitation on the number of IPv4 neighbor entries that the Virtual Service Router can handle. Consequently, it is crucial to synchronize the highest number of permitted ARP entries with the peak number of IPoE sessions.

For example, a configuration might allow a limit of 8192 ARP entries while limiting IPoE sessions to 7000. This excess in ARP entries ensures that there is adequate space for neighbors that are not connected via IPoE.

router running config# / system network-stack neighbor ipv4-max-entries 8192
router running config# / system fast-path limits ip4-max-neigh 8192
router running config# / vrf main ipoe-server limits max-session 7000

Caution

Unlike the /32 routes, the neighbor entries are not instantly removed when an IPoE session ends. Instead, they are periodically flushed if they become inactive. It is worth noting that when an IPoE client switches IP addresses, the old and new ARP entries temporarily coexist. During events like a manual migration of the IP address pool or a switch to an alternate DHCP server with a different IP range, IP addresses can change suddenly and massively. A lack of available neighbor entries could result in some sessions being disconnected from the network. If there is a risk of this situation occurring, consider allocating twice the usual ARP entry capacity for IPoE or using a common, synchronized IP pool on DHCP servers.

Security considerations

It is important to highlight that traffic among IPoE hosts is routed by default. To enhance security, consider implementing firewall rules, directly on the IPoE server Virtual Service Router, that restrict communication between hosts. The source and destination hosts can be located behind the same or different relay agents.

If an end device manually configures its IP address or keeps its IP address after the DHCP lease ends, it will not be able to connect to the network. This safeguard comes from the routing approach which adds or removes /32 routes in the relay agent based on IPoE sessions. This method only blocks returning traffic; incoming traffic from clients is still forwarded.

Troubleshooting

The following command displays the list of IPoE sessions:

router> show ipoe-server session vrf main
interface calling-sid       address       status uptime   server
========= ===========       =======       ====== ======   ======
eth1      0c:d6:7d:3b:1d:c4 192.168.1.24   active 00:00:21 172.16.0.1
eth1      0c:94:2c:91:12:d4 192.168.1.25   active 00:00:21 172.16.0.1
eth1      0c:94:05:c0:ef:78 192.168.2.150  active 00:00:21 172.16.0.2
eth1      0c:76:66:b9:7a:4c 192.168.1.32   active 00:00:20 172.16.0.1
eth2      0c:34:64:85:ae:5d 192.168.2.157  active 00:00:20 172.16.0.2

When set to the debug or info log-level, the IPoE server has the capability to log the details of DHCP packets. However, be cautious, as the amount of logged records can be important with a high number of sessions.

Sep 07 12:03:23 router ipoe-server-main[3873]: eth2:: send [DHCPv4 relay to 172.16.0.1 Request xid=7823462c ciaddr=192.168.1.91 giaddr=10.2.2.1 chaddr=0c:e8:e8:59:00:0e <Message-Type Request> <Client-ID 010ce8e859000e> <Vendor-Class 756468637020302e392e392d707265> <Request-List Subnet,Router,DNS,Host-Name,Domain-Name,17,Broadcast,40,41,NTP> <Relay-Agent {Agent-Circuit-ID eth2} {Agent-Remote-ID ETH1-XVZ5} {Link-Selection 10.1.2.1}>]
Sep 07 12:03:23 router ipoe-server-main[3873]: eth1:: recv [DHCPv4 Request xid=7102bca8 ciaddr=192.168.1.72 chaddr=0c:22:ae:3f:63:0c <Message-Type Request> <Client-ID 010c22ae3f630c> <Vendor-Class 756468637020302e392e392d707265> <Request-List Subnet,Router,DNS,Host-Name,Domain-Name,17,Broadcast,40,41,NTP>]
Sep 07 12:03:23 router ipoe-server-main[3873]: eth1:: send [DHCPv4 relay to 172.16.0.1 Request xid=7102bca8 ciaddr=192.168.1.72 giaddr=10.2.1.1 chaddr=0c:22:ae:3f:63:0c <Message-Type Request> <Client-ID 010c22ae3f630c> <Vendor-Class 756468637020302e392e392d707265> <Request-List Subnet,Router,DNS,Host-Name,Domain-Name,17,Broadcast,40,41,NTP> <Relay-Agent {Agent-Circuit-ID eth1} {Agent-Remote-ID ETH0-XVZ4} {Link-Selection 10.1.1.1}>]
Sep 07 12:03:23 router ipoe-server-main[3873]: eth1:: recv [DHCPv4 relay from 172.16.0.1 Ack xid=7102bca8 ciaddr=192.168.1.72 yiaddr=192.168.1.72 giaddr=10.2.1.1 chaddr=0c:22:ae:3f:63:0c <Message-Type Ack> <Subnet 255.0.0.0> <Domain-Name example.org> <Lease-Time 60> <Server-ID 172.16.0.1> <T1 30> <T2 52> <Client-ID 010c22ae3f630c> <Relay-Agent {Agent-Circuit-ID eth1} {Agent-Remote-ID ETH0-XVZ4} {Link-Selection 10.1.1.1}>]
Sep 07 12:03:23 router ipoe-server-main[3873]: eth1:: send [DHCPv4 Ack xid=7102bca8 ciaddr=192.168.1.72 yiaddr=192.168.1.72 chaddr=0c:22:ae:3f:63:0c <Message-Type Ack> <Server-ID 10.1.1.1> <Lease-Time 60> <T1 30> <T2 52> <Router 10.1.1.1> <Subnet 255.255.255.255> <Domain-Name example.org> <T2 52> <Client-ID 010c22ae3f630c>]
Sep 07 12:03:23 router ipoe-server-main[3873]: eth2:: recv [DHCPv4 relay from 172.16.0.1 Ack xid=7823462c ciaddr=192.168.1.91 yiaddr=192.168.1.91 giaddr=10.2.2.1 chaddr=0c:e8:e8:59:00:0e <Message-Type Ack> <Subnet 255.0.0.0> <Domain-Name example.org> <Lease-Time 60> <Server-ID 172.16.0.1> <T1 30> <T2 52> <Client-ID 010ce8e859000e> <Relay-Agent {Agent-Circuit-ID eth2} {Agent-Remote-ID ETH1-XVZ5} {Link-Selection 10.1.2.1>]
Sep 07 12:03:23 router ipoe-server-main[3873]: eth2:: send [DHCPv4 Ack xid=7823462c ciaddr=192.168.1.91 yiaddr=192.168.1.91 chaddr=0c:e8:e8:59:00:0e <Message-Type Ack> <Server-ID 10.1.1.1> <Lease-Time 60> <T1 30> <T2 52> <Router 10.1.1.1> <Subnet 255.255.255.255> <Domain-Name example.org> <T2 52> <Client-ID 010ce8e859000e>]
Sep 07 12:03:23 router ipoe-server-main[3873]: eth2:: recv [DHCPv4 Request xid=72e15da5 ciaddr=192.168.1.66 chaddr=0c:11:40:e1:80:ca <Message-Type Request> <Client-ID 010c1140e180ca> <Vendor-Class 756468637020302e392e392d707265> <Request-List Subnet,Router,DNS,Host-Name,Domain-Name,17,Broadcast,40,41,NTP>]
Sep 07 12:03:23 router ipoe-server-main[3873]: eth2:: send [DHCPv4 relay to 172.16.0.1 Request xid=72e15da5 ciaddr=192.168.1.66 giaddr=10.2.2.1 chaddr=0c:11:40:e1:80:ca <Message-Type Request> <Client-ID 010c1140e180ca> <Vendor-Class 756468637020302e392e392d707265> <Request-List Subnet,Router,DNS,Host-Name,Domain-Name,17,Broadcast,40,41,NTP> <Relay-Agent {Agent-Circuit-ID eth2} {Agent-Remote-ID ETH1-XVZ5} {Link-Selection 10.1.2.1}>]