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, which 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.

Virtual Service Router establishes IPoE session with a client on the same network or via Layer 2 devices relying on the DHCP protocol for IPv4 network and the DHCPv6 protocol for IPv6 network. Virtual Service Router also provides subscriber authentication through Radius servers.

Supported services & features

The Virtual Service Router’s IPoE server solution offers a wide range of features:

  • Multi-VRF support

  • RADIUS AAA support

  • DHCP relay mode

  • DHCP server mode

  • Monitoring

  • Hierarchical QoS

RADIUS AAA support

Virtual Service Router supports interacting with a RADIUS server in order to assure authentication, authorization and accounting (AAA) functions.

Subscriber authentication

The authentication is triggered by the DHCP first message sent by the subscriber. Upon receipt, the IPoE server generates username and password by extracting data from the message according to the configuration. Then, it sends the generated authentication credentials to the RADIUS server in an Access-Request packet. The RADIUS server receives the authentication data and authenticates the subscriber. If the authentication fails, the RADIUS server returns an Access-Reject packet and the IPoE server terminates the session with the subscriber terminal. If the authentication succeeds, the RADIUS server returns an Access-Accept packet with a set of attributes for the subscriber.

Unlike PPPoE, IPoE doesn’t require a subscriber login function. To identify the subscriber, it relies on the physical and logical information of the subscriber’s connection. In addition it can rely on data from the received triggering DHCP packets.

Support for multiple combinations is available by placing the target data between “{}”. The supported values are:

  • {vendor_class_id}: The vendor class ID (option 60) from the DHCPDISCOVER packet. Supported in DHCPv4 only.

  • {agent_circuit_id}: The agent circuit ID (option82 sub-option 1) from the DHCPDISCOVER packet. Supported in DHCPv4 only

  • {agent_remote_id}: The agent remote ID (option82 sub-option 2) from the DHCPDISCOVER packet. Supported in DHCPv4 only

  • {client_hwaddress}: The client’s hardware address.

  • {server_interface}: The server interface name from which the DHCP packet is received.

Here is an example mixing usage of option 60, client MAC address and name of interface:

router running ipoe-server# auth username user_{server_interface}_{client_hwaddress}_{vendor_class_id}
router running ipoe-server# auth password P4ssW0rD_{server_interface}

Once the session is established, the Virtual Service Router also supports sending user accounting information showing how much time, packets, bytes, and other resources were consumed during the session to a RADIUS accounting server.

RADIUS supported attributes

The following tables list the supported RADIUS attributes. A more detailed explanation for each attribute can be found in the sections below.

RADIUS standard-attributes support:

Number

Attribute name

AAA packet presence

1

User-Name

Access-Request, Access-Accept

2

User-Password

Access-Request

4

NAS-IP-Address

Access-Request, Accounting-Request

27

Session-Timeout

Access-Accept

28

Idle-Timeout

Access-Accept

30

Called-Station-Id

Access-Request

31

Calling-Station-Id

Access-Request

32

NAS-Identifier

Access-Request, Accounting-Request

61

NAS-Port-Type

Access-Request, Accounting-Request

85

Acct-Interim-Interval

Access-Accept

87

NAS-Port

Access-Request, Accounting-Request

6WIND vendor-specific RADIUS attributes:

Number

Attribute name

AAA packet presence

24

6WIND-qos-template-name

Access-Accept, COA

RADIUS standard-attributes support

User-Name

The user to be authenticated in the Access-Request. It may be sent in an Access-Accept packet, in which case Virtual Service Router will use this User-Name in all Accounting-Request packets for this session.

RFC 2865#section-5.1

User-Password

This attribute is sent in Access-Request packets. It contains the password generated by Virtual Service Router according to the configuration when authentication is enabled.

RFC 2865#section-5.2

NAS-IP-Address

This attribute indicates the identifying IP Address of Virtual Service Router. It is sent in Access-Request and Accounting-Request packets.

RFC 2865#section-5.4

Session-Timeout

This attribute sets the maximum number of seconds of service to be provided to the user before the Virtual Service Router terminates the session. Supported in DHCPv4 only.

RFC 2865#section-5.27

Idle-Timeout

This attribute defines the maximum number of consecutive seconds a user can remain connected without activity before the Virtual Service Router terminates the session. Supported in DHCPv4 only.

RFC 2865#section-5.28

Called-Station-Id

This attribute is included in the Access-Request and is set to the name of the IPoE server interface that received the user’s DHCP packet.

RFC 2865#section-5.30

Calling-Station-Id

This attribute is included in the Access-Request. It is set to the user’s MAC address.

RFC 2865#section-5.31

NAS-Identifier

This attribute contains a configured string identifying the Virtual Service Router. It is sent in Access-Request and Accounting-Request packets.

RFC 2865#section-5.32

NAS-Port-Type

This attribute indicates the type of the physical port of the NAS which is authenticating the user. It is sent in Access-Request and Accounting-Request packets.

RFC 2865#section-5.41

Acct-Interim-Interval

This attribute indicates the number of seconds between each interim update in seconds for the session.

RFC 2869#section-5.16

NAS-Port

This attribute indicates the physical port number of the NAS which is authenticating the user. It is used in Access-Request and Accounting-Request packets.

RFC 2865#section-5.5

6WIND vendor-specific RADIUS attributes

The following section defines the 6WIND proprietary RADIUS attributes. Note that a RADIUS attribute dictionary is provided with Virtual Service Router. The dictionary includes the attribute number, attribute name, attribute type and 6WIND vendor ID. So it may be loaded to RADIUS servers.

6WIND-qos-template-name

Type

string

Description

This attribute contains the name of an hierarchical QoS template to be applied to the user. The template has to be configured on the Virtual Service Router, otherwise the default template is applied. This attribute may be present in Access-Accept.

A FreeRADIUS configuration example

Here is a configuration file example with FreeRadius.

user_eth0_de:ed:02:f3:93:ec Cleartext-Password := "P4ssW0rD_eth0"
        User-Name = user_1,
        Session-Timeout = 2400,
        Idle-Timeout = 120,
        Acct-Interim-Interval = 60,
        6WIND-qos-template-name = premium-subscribers

Note

It’s necessary to include the 6WIND vendor-specific dictionary in the FreeRADIUS dictionary list for this example to work.

IPoE DHCP relay mode

The Virtual Service Router’s solution supports the use of IPoE server as a relay agent for both IPv4 and IPv6 networks. In this mode, Virtual Service Router forwards client requests to DHCP or DHCPv6 servers, and reciprocally retransmit server responses back to clients.

IPoE DHCP relay

The IPoE session is set up using a standard DHCP protocol, consisting of the DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and DHCPACK phases, and is maintained through DHCP lease renewals. The session will terminate when the IP address lease expires.

Supported relay agent options

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.

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.

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.

../../../_images/aafig-3bceff6ee792a45c42f0538af076ee660875ef71.svg

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.

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

IPoE DHCPv6 relay

When DHCPv6 clients start requesting IPv6 addresses, they transmit a DHCPv6SOLICIT message. This message uses a local multicast address ( ff02::1:2 RFC 8415#section-7.1) that target all DHCPv6 servers and relays on local subnet.

The Virtual Service Router’s solution supports the use of IPoE server as a DHCPv6 relay agent with the following restrictions :

  • clients must only have a unique IPv6 address

  • clients can only have a unique IPv6 prefix

  • clients with an expired prefix can not retrieve a new prefix

  • a client that releases or declines its IPv6 address lose its session even if there is a not expired prefix lease

  • DHCPv6CONFIRM are not supported. If one is received, Virtual Service Router’s solution behavior is undefined.

  • clients with multiple IPv6 addresses and/or multiple prefixes result in undefined behavior.

  • An explicit DHCPv6 server must be configured. There will be no fallback on local multicast address for DHCPv6 server.

Configuration

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

../../../_images/aafig-95f4047dc9d98b5af6096209091658aa2f56ab07.svg

The interfaces are configured as follows:

running config# / vrf main interface physical eth1
running physical eth1#! port pci-b0s4
running physical eth1# ipv6 address fd00:100::2/64
running physical eth1# /
running config# / vrf main interface physical eth2
running physical eth2#! port pci-b0s5
running physical eth2# ipv6 address 2001:db8:0:1::1
running physical eth2# /

A simple configuration would be the following :

router running config# / vrf main ipoe-server
router running ipoe-server# dhcpv6-relay
running dhcpv6-relay# server fd00:100::1
running dhcpv6-relay# interface eth2
running interface eth2#! agent-information
running agent-information# relay-address 2001:db8:0:1::1
running agent-information# link-address 2001:db8:0:1::1

DHCPv6 server can be configured either globally (like the last example) or by DHCPv6 relay interface (preferred if configured).

relay-address is IPv6 source address used for sending DHCPv6 relay message to DHCPv6 server.

See also

IPoE DHCP server mode

The Virtual Service Router’s solution also supports the use of the IPoE server as a basic DHCP server. Supported only in IPv4, in this mode the IPoE server doesn’t forward the DHCPDISCOVER messages to an external DHCP server to get the network configuration. Rather, it relies on the local configuration to create the DHCPOFFER message and sends it to the IPoE subscriber.

Here is a basic configuration example:

router running config# / vrf main ipoe-server
router running ipoe-server# dhcp-server interface eth1 router 10.0.0.1
router running ipoe-server# dhcp-server ip-pools-setup pool pool1 peer-pool 10.0.0.3-10.0.0.100
router running ipoe-server# dhcp-server ip-pools-setup default-local-ip 10.0.0.1
router running ipoe-server# dhcp-server ip4-pool pool1
router running ipoe-server# dhcp-server dns 10.0.0.2
router running ipoe-server# commit

Note

An interface is configured either in DHCP server mode or in DHCP relay mode, never in both modes.

Quality of Service Support

Virtual Service Router provides support for multi-level hierarchical quality of service for IPoE sessions. This feature allows latency and throughput optimization and ensures that each subscribers gets the appropriate network resources. This is achieved through classifying, policing and scheduling the traffic.

The QoS is configured in the CLI, triggered by RADIUS and dynamically applied by the IPoE server for each subscriber session.

The deployment of QoS involves two main components, an HTB based scheduler and an IPoE server QoS template:

  • The HTB scheduler:

    All subscriber queues will be organized in a tree structure scheduler that determines how available bandwidth is distributed among them.

    The user should first create the root queue as well as the default queue of this HTB scheduler in the global QoS context and associate it to the IPoE server interface, as described in the chapter scheduling.

    The user can also add inner static queues to suit his bandwidth redistribution and his different subscriber plans. This part of the scheduler is static and is called the base-scheduler, it is referenced by the scheduler-interface configuration node.

    When an IPoE session is established, all its queues will be appended dynamically as child queues to the base-scheduler according to IPoE server QoS template.

  • IPoE server QoS template:

    The IPoE server QoS template is a profile that provides queue models for BNG subscribers. A queue model allows the user to configure minimum guaranteed bandwidth, maximum authorized bandwidth, priority, traffic mark and other related QoS parameters.

    Once the subscriber authenticates to the network and its session is established, QoS queues will be dynamically created according to the queue models configured in its template. The template name must be received in the RADIUS Access-Accept packet via the 6WIND attribute 6WIND-qos-template-name. Please refer to 6WIND attributes section for more details.

Traffic classification:

Each queue can be associated with a different form of traffic like video, data, VOIP and so on. This traffic classification into the queues is achieved through the mark of the queue template. When a packet mark matches a queue mark, the packet is classified into the matching queue.

Restrictions:

  • Users can configure up to 255 queue marks.

  • Only egress is supported.

  • The sum of CIR bandwidth of all existing dynamic queues must not exceed the CIR bandwidth of the parent queue

  • Unlike the queue configuration in the global QoS context, it’s not possible to add a policer for a queue in the IPoE server QoS template.

  • Static inner queues can’t be assigned QoS classes.

Let’s consider the following example, where the service provider offers 2 subscriber plans premium and non-premium. Each plan provides its user with specific guaranteed bandwidth for voip and data traffic.

../../../_images/bng_qos.svg

Step 1: Configure the fast path limits

Set the maximum number of QoS policies to the number of the subscribers, and the maximum number of QoS classes to the number of subscribers times the maximum number of QoS queues per subscribers.

For instance, with 10K subscribers and 3 queues per subscriber, use the following fast path limits:

vsr running config# / system fast-path limits
vsr running limits# qos-max-classes 31500
vsr running limits# qos-max-policies 10500

Step 2: Configure the static base-scheduler

vsr running config# / qos
vsr running qos# scheduler scheduler-1
vsr running scheduler scheduler-1#! htb
vsr running htb# queue 1
vsr running queue 1#! bandwidth 40G
vsr running queue 1# ceiling 40G
vsr running queue 1# ceiling-priority 1
vsr running queue 1# child-queue 2
vsr running queue 1#! child-queue 3
vsr running queue 1#! child-queue 4
vsr running queue 1#! ..
vsr running htb#! queue 2
vsr running queue 2#! description "This is the static parent queue for premium subscribers queues"
vsr running queue 2#! bandwidth 30G
vsr running queue 2#! ceiling 40G
vsr running queue 2#! ceiling-priority 1
vsr running queue 2#! ..
vsr running htb#! queue 3
vsr running queue 3#! description "This is the static parent queue for non-premium subscribers queues"
vsr running queue 3#! bandwidth 10G
vsr running queue 3#! ceiling 40G
vsr running queue 3#! ceiling-priority 2
vsr running queue 3#! ..
vsr running htb#! queue 4
vsr running queue 4#! description "This is the default queue"
vsr running queue 4#! bandwidth 10K
vsr running queue 4# ceiling 40G
vsr running queue 4# ceiling-priority 9
vsr running queue 4# ..
vsr running htb# default-queue 4

Step 3: Add the base-scheduler to the IPoE server interface

vsr running config# vrf main interface physical eth1 qos egress scheduler scheduler-1

Step 4: Configure the templates

The base-scheduler is referenced by the interface on which it is set as an egress scheduler, as done in previous step. Here, it is eth1. The static-parent node references queue indexes in this base-scheduler.

vsr running config# / vrf main ipoe-server qos
vsr running qos# template premium-subscribers scheduler-interface eth1
vsr running qos#! template premium-subscribers queue prem static-parent 2
vsr running qos#! template premium-subscribers queue prem bandwidth 7M
vsr running qos# template premium-subscribers queue prem ceiling 2G
vsr running qos# template premium-subscribers queue prem-voip dynamic-parent prem
vsr running qos#! template premium-subscribers queue prem-voip bandwidth 5M
vsr running qos# template premium-subscribers queue prem-voip ceiling 2G
vsr running qos# template premium-subscribers queue prem-voip mark 0x1
vsr running qos# template premium-subscribers queue prem-data dynamic-parent prem
vsr running qos#! template premium-subscribers queue prem-data bandwidth 2M
vsr running qos# template premium-subscribers queue prem-data ceiling 2G
vsr running qos# template premium-subscribers queue prem-data mark 0x0

vsr running qos# template non-premium-subscribers scheduler-interface eth1
vsr running qos#! template non-premium-subscribers queue non-prem static-parent 3
vsr running qos#! template non-premium-subscribers queue non-prem bandwidth 4M
vsr running qos# template non-premium-subscribers queue non-prem ceiling 1G
vsr running qos# template non-premium-subscribers queue non-prem-voip dynamic-parent non-prem
vsr running qos#! template non-premium-subscribers queue non-prem-voip bandwidth 3M
vsr running qos# template non-premium-subscribers queue non-prem-voip ceiling 1G
vsr running qos# template non-premium-subscribers queue non-prem-voip mark 0x1
vsr running qos# template non-premium-subscribers queue non-prem-data dynamic-parent non-prem
vsr running qos#! template non-premium-subscribers queue non-prem-data bandwidth 1M
vsr running qos# template non-premium-subscribers queue non-prem-data ceiling 1G
vsr running qos# template non-premium-subscribers queue non-prem-data mark 0x0

vsr running qos# default-template non-premium-subscribers

Once the configuration in place, the RADIUS setup of a user should include its QoS template name, for instance, for a premium user the attribute is 6WIND-qos-template-name = premium-subscribers

If no attribute can be retrieved from RADIUS server, the default template is used (non-premium-subscribers).

Step 5: Configure the flow marking

In this example, the VOIP traffic has to be marked with 0x1. The other traffic has the mark 0x0 (equivalent to no mark).

The marking can be done using the IP packet filtering context.

Terminating an IPoE session

You can terminate an IPoE session by its username.

vsr> flush ipoe-server session vrf vrf1 username user_de:ed:02:60:0e:a3
OK.

See also

Please refer to IPoE server command reference for more details.

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