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.
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}>]