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

  • Rate limiting

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.

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

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

  • {client_tagX_vlan_id}/{client_tagX_qinq_id}: For dynamic VLANs, this is the tag’s id in decimal, where X is the VLAN or QINQ order in the Ethernet frame. It starts at 1 which is the order of the outer tag. Supported in DHCPv4 only.

  • {agent_circuit_id}: Agent circuit ID (option 82 sub-option 1). Supported in DHCPv4 only.

  • {agent_remote_id}: Agent remote ID (option 82 sub-option 2 for DHCPv4, option 37 for DHCPv6). Only the first occurence of DHCPv6 option 37 in the packet can be used. Its data size must be lower than 256, and the enterprise number is ignored.

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

vsr running ipoe-server# auth username user_{server_interface}_{client_hwaddress}_{vendor_class_id}
vsr 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

8

Framed-IP-Address

Access-Accept

22

Framed-Route

Access-Accept

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

1

6WIND-AVPair

Access-Accept

7

6WIND-limit

Access-Accept, COA

24

6WIND-qos-template-name

Access-Accept, COA

25

6WIND-LI-Action

Access-Accept, COA

26

6WIND-LI-Identifier

Access-Accept, COA

27

6WIND-LI-Mediation-Device-IP

Access-Accept, COA

28

6WIND-LI-Mediation-Device-Port

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

Framed-IP-Address

This attribute indicates the address to be configured for the user. Only supported when IPoE server is in DHCP server mode.

RFC 2865#section-5.8

Framed-Route

A static IPv4 route provided by RADIUS server to install in Virtual Service Router routing table for the IPoE user.

RFC 2865#section-5.22

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-limit

Type

string

Description

This is the Traffic Limiting IPv4 attribute, IPoE server supports the basic rate-limiting QoS policy which means that if the rate-limit parameters are exceeded, the traffic is dropped. the attribute is a string with the following format “type=cir cbs eir ebs unit”.

  • type: can take either “in” for ingress or “out” for egress.

  • cir: Committed Information Rate.

  • cbs: Committed Burst Size.

  • eir: Excess Information Rate.

  • ebs: Excess Burst Size.

  • unit: in pps or bps. The unit could also be set in kilo (kbps/kpps), in mega (mpps/mbps) or in giga (gpps/gbps).

Example: “in=10 10 10 10 kpps”.

This attribute may be present in Access-Accept or CoA packets.

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.

6WIND-AVPair

All of the sub-attributes described below are of a type referred to as 6WIND-AVPair, consisting of a vendor type of 1 and an ASCII string as an Attribute-Specific value. This string is of the form Attr=Value with Attr being a string containing the name of the 6WIND-AVPair attribute and Value being the value whose expected format will depend on Attr.

For example, l3vrf=abc as a value to a 6WIND-AVPair sub-attribute represents an l3vrf attribute with a value of abc.

Note

Only the first = character serves as a delimiter. For example a 6WIND-AVPair sub-attribute with a value of l3vrf=abc=123 represents an l3vrf attribute with a value of abc=123.

6WIND-LI-Action

Type

integer

Description

This attribute contains the desired Lawful Interception state for the user. The 6WIND RADIUS dictionary defines two symbolic values as follow :

  • Enable = 1

  • Disable = 0

This attribute may be present in Access-Accept or CoA packets.

6WIND-LI-Identifier

Type

integer

Description

This attribute contains the Lawful Interception session identifier for the mediation device. This attribute may be present in Access-Accept or CoA packets.

6WIND-LI-Mediation-Device-IP

Type

string

Description

This attribute contains the IPv4 address or the IPv6 address of the mediation device. This attribute may be present in Access-Accept or CoA packets.

6WIND-LI-Mediation-Device-Port

Type

integer

Description

This attribute contains the UDP port on which mediation device is listening. This attribute may be present in Access-Accept or CoA packets.

l3vrf

Used to specify the name of an L3VRF to which the IPoE session should be attached.

The value must be an ASCII string containing the name of the target L3VRF.

Example:

  • l3vrf=user6-l3vrf

This attribute should only be specified once. If specified multiple times, only one of the attributes will be selected depending on how the attributes are ordered in the Access-Accept response.

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
        6WIND-AVPair = "l3vrf=user_1-l3vrf"

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:

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

Then the IPoE functionality itself:

vsr running config# / vrf main ipoe-server
vsr running ipoe-server# enabled true
vsr running ipoe-server# log-level warning
vsr running ipoe-server# dhcp-relay interface eth1
vsr running interface eth1#! router 10.1.1.1
vsr running interface eth1#! server 172.16.0.1
vsr running interface eth1#! server 172.16.0.2
vsr running interface eth1#! agent-information
vsr running agent-information#! relay-address 10.2.1.1
vsr running agent-information# trusted-circuit false
vsr running agent-information# remote-id global ETH1-XVZ4
vsr running agent-information# link-selection 10.1.1.1
vsr running agent-information# ..
vsr running interface eth1# ..
vsr running dhcp-relay# interface eth2
vsr running interface eth2#! router 10.1.2.1
vsr running interface eth2#! server 172.16.0.1
vsr running interface eth2#! server 172.16.0.2
vsr running interface eth2#! agent-information
vsr running agent-information#! relay-address 10.2.2.1
vsr running agent-information# trusted-circuit false
vsr running agent-information# remote-id global ETH2-XVZ4
vsr running agent-information# link-selection 10.1.2.1
vsr 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:

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

It is possible to set the VRF through which the DHCP server is reachable with dhcp-relay interface <ifname> server-vrf <vrf_name>. When doing so, the IPs of the DHCP server must be reachable through the server-vrf VRF.

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 supported with the following behaviour : If a DHCPv6CONFIRM is received and there is no corresponding session, ipoe server will send a DHCPv6REPLY with the status code DHCPv6NotOnLink. If a DHCPv6CONFIRM is received and there is a corresponding session, ipoe server will relay this packet to the DHCPv6 server. If the DHCPv6 server respond with a DHCPv6REPLY with the status code DHCPv6NotOnLink, the latter will be relayed to the client and the session will be terminated, otherwise the packet will be relayed and the session will continue to live.

  • If a DHCPv6 server gives multiple addresses and/or multiple prefixes to the client ( either because the client requested multiple addresses/prefixes through some IA of the same type or because the server gives multiple addresses/prefixes in an unique IA), the first address and the first prefix will be relayed to the client (other IA_NA/IA_PD requested by the client will contain DHCPv6NoAddrsAvail/DHCPv6NoPrefixAvail) and the other leases will be released in an unique DHCPv6RELEASE message.

  • 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 :

vsr running config# / vrf main ipoe-server
vsr 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.

It is possible to set the VRF through which the DHCPv6 server is reachable with dhcpv6-relay interface <ifname> server-vrf <vrf_name>. When doing so, the IPv6s of the DHCPv6 server must be reachable through the server-vrf VRF.

See also

IPoE DHCP server mode

The Virtual Service Router’s solution supports using the IPoE server as a DHCP server. Supported in IPv4 or IPv6, in this mode the IPoE server does not forward IPoE subscriber DHCP messages to an external DHCP server for network configuration. Instead, it generates the DHCP reply locally and sends it directly to the IPoE subscriber.

IPoE DHCP server

In this mode, the IPoE server behaves as a basic DHCP server. Besides, creating and monitoring subscribers IPoE sessions, the IPoE server assigns IP addresses, DNS servers, and other related options to IPoE subscribers.

Establishing an IPoE session requires the completion of a four-message exchange between the subscriber and the IPoE server according to the DHCP protocol. For more information about the DHCP protocol, please consult RFC 2131.

Establishing an IPoE session:

  • A client sends a DHCPDISCOVER message.

  • Upon receiving the DHCPDISCOVER message, the IPoE server creates an IPoE session.

  • If authentication is enabled, the IPoE server sends an Access-Request to a RADIUS server using the client’s data. If no Access-Accept is received, the IPoE server terminates the session. For more details refer to the RADIUS AAA support section.

  • The IPoE server generates a DHCPOFFER message. It sets the yiaddr field to an available IP address from the configuration pool. Other DHCP options may be included.

  • The client responds with a DHCPREQUEST based on the received DHCPOFFER.

  • If the DHCPREQUEST is valid, the IPoE server sends a DHCPACK message.

  • The IPoE server activates the session and starts sending Accounting-Request messages to the RADIUS server.

Maintaining an IPoE session:

  • The session remains active as long as the client sends DHCPREQUEST messages to renew its lease.

Terminating an IPoE session

  • The Virtual Service Router terminates an IPoE session if it does not receive a DHCPREQUEST by the end of the assigned lease.

  • An IPoE subscriber can terminate its session by sending a DHCPRELEASE message.

  • The Virtual Service Router allows users to terminate a subscriber’s IPoE session using the command specified in the Rate limiting Support section.

Here is a basic configuration example for IPv4:

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

Note

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

IPoE DHCPv6 server

In this mode, the IPoE server behaves as a basic DHCPv6 server. Besides, creating and monitoring subscribers IPoE sessions, the IPoE server assigns IPv6 addresses, IPv6 delegated prefixes, DNS servers, and other options to IPoE subscribers based on the local configuration.

Establishing an IPoE session requires the completion of a four-message exchange between the subscriber and the IPoE server according to the DHCPv6 protocol. For more information about the DHCPv6 protocol, please consult RFC 8415.

Establishing an IPoE session:

  • The IPoE client sends a DHCPv6SOLICIT message. This message must include an IA_NA. If the client also needs a prefix, it must include an IA_PD.

  • Upon receiving the DHCPv6SOLICIT, the IPoE server creates an IPoE session.

  • If authentication is enabled, the IPoE server sends an Access-Request to a RADIUS server using the client’s data. If no Access-Accept is received, the IPoE server terminates the session. For more details, refer to RADIUS AAA support section.

  • The IPoE server generates a DHCPv6ADVERTISE message. This message includes the client identifier, a server identifier, the received IA_NA and IA_PD. The server adds an IA address option with an available IPv6 address from the local pool to the IA_NA option. It also adds an IA prefix option with a prefix from the delegated-prefix pool to the IA_PD option. Additional DHCPv6 options may be included.

  • The client responds with a DHCPv6REQUEST, containing the same information (IA_NA and IA_PD) from the DHCPv6ADVERTISE message.

  • If the DHCPv6REQUEST is valid, the IPoE server replies with a DHCPv6REPLY message that includes the client identifier, server identifier, IA_NA, IA_PD, and any other relevant DHCPv6 options.

  • the Virtual Service Router activates the session and starts sending Accounting-Request messages to the RADIUS server.

Maintaining an IPoE session:

  • The session remains active as long as the client periodically sends DHCPv6RENEW messages, including its IA_NA and IA_PD.

  • If the server misses the DHCPv6RENEW messages but receives a DHCPv6REBIND message with the same IA_NA and IA_PD, it renews the leases and keeps the session active.

Terminating an IPoE session:

  • The session is terminated if the server does not receive either a DHCPv6RENEW or a DHCPv6REBIND message before the IA_NA lease expires.

  • If the client sends a DHCPv6DECLINE message, the server releases the leases and ends the session.

  • The client can also terminate the session by sending a DHCPv6RELEASE message.

  • The Virtual Service Router provides an option to terminate a subscriber’s IPoE session using the command specified in the Rate limiting Support section.

Considerations

  • Currently, the IPoE server assigns one IPv6 address and one IPv6 prefix per subscriber. Support for multiple IPv6 addresses and prefixes is not available yet.

Here is a basic configuration example for IPv6:

vsr running config# / vrf main ipoe-server dhcpv6-server interface ntfp2
vsr running interface ntfp2#! / vrf main ipoe-server dhcpv6-server ip6-pools-setup pool pool1 prefix 2001:db8:0:1::/64 prefix-len 64
vsr running interface ntfp2# / vrf main ipoe-server dhcpv6-server ip6-pool pool1
vsr running interface ntfp2# / vrf main ipoe-server dhcpv6-server ipv6-prefix-delegation poolpd
vsr running interface ntfp2# / vrf main ipoe-server dhcpv6-server ip6-pools-setup prefix-delegation poolpd prefix 2001:db8:0:2::/48 prefix-len 64
vsr running interface ntfp2# / vrf main ipoe-server dhcpv6-server server-id dced:2ff:fe6c:c271
vsr running interface ntfp2# / vrf main ipoe-server dhcpv6-server ip6-dns server fc00:1::1
vsr running interface ntfp2# / vrf main ipoe-server dhcpv6-server ip6-dns search example.com
vsr running interface ntfp2# commit

Note

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

IPoE Dual-Stack Layer 2 Subscriber

A dual-stack layer 2 subscriber consists of one IPv4 single-stack IPoE session and one IPv6 single-stack IPoE session, both identified by a single MAC-based username. While these sessions are counted as two IPoE sessions, they are treated as one subscriber and share the same QoS configuration. However, RADIUS AAA services are handled separately for each IPoE session.

The dual-stack subscriber allows a device to have both an IP network configuration (address, router, etc.) and an IPv6 network configuration (obtained via IA_NA and IA_PD). When both IPoE sessions are terminated, the subscriber is disconnected.

A subscriber session is initiated when the IPoE server receives one of the following trigger packets:

  • DHCPDISCOVER message.

  • DHCPv6SOLICIT message.

Example of Dual-stack subscriber session establishment:

  • The IPoE server receives one of the trigger packets, such as a DHCPv6SOLICIT.

  • The IPoE server sends an Access-Request to RADIUS for the first session.

  • Upon receiving an Access-Accept, the IPoE server proceeds with the DHCPv6 four-packet exchange with the subscriber, as described in RFC 8415.

  • Once the session is established, the IPoE server generates an Acct-Session-Id and starts sending accounting messages.

  • When the IPoE server receives a DHCPDISCOVER from the subscriber, it sends a new Access-Request to RADIUS for the second session.

  • Upon receiving an Access-Accept, the IPoE server proceeds with the DHCP packet exchange with the subscriber, as described in RFC 2131.

  • The IPoE server then starts accounting for the second session using a new Acct-Session-Id.

Dual-stack layer 2 subscriber support is available in both relay and server modes.

Configuration example to support 4000 dual-stack subscribers in relay mode:

Interfaces configuration:

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

DHCP Relay configuration

vsr running config# / vrf main ipoe-server
vsr running ipoe-server# enabled true
vsr running ipoe-server# dhcp-relay
vsr running dhcp-relay# router 10.2.1.1
vsr running dhcp-relay# server 172.16.0.1
vsr running dhcp-relay# interface eth2
vsr running interface eth2#! agent-information
vsr running agent-information#! relay-address 10.2.1.1
vsr running agent-information# trusted-circuit false
vsr running agent-information# remote-id global ETH2-XVZ4

DHCPv6 Relay configuration

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

RADIUS AAA configuration

vsr running config# / vrf main ipoe-server
vsr running ipoe-server# auth
vsr running auth# username user_{server_interface}_{client_hwaddress}
vsr running auth# password P4ssW0rD_{server_interface}
vsr runnning auth# radius
vsr runnning radius# enabled true
vsr runnning radius# server address 10.210.0.1 auth-port 1812 acct-port 1813 secret secret123
vsr runnning radius# nas ip-address 10.175.0.1
vsr runnning radius# nas identifier accel-ppp

Dual-stack support enabling

vsr running config# / vrf main ipoe-server aggregated-sessions 2

Setting IPoE server limits

vsr running config# / vrf main ipoe-server limits max-session 8000

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-queues 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).

Note

Changes to existing templates, including the default template, are not automatically applied to active sessions. To apply the new configuration to active sessions, you may initiate the update via a RADIUS Change of Authorization (CoA) request. This ensures that the changes are dynamically applied without requiring a service restart.

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.

Rate limiting Support

In addition to hierarchical QoS, Virtual Service Router supports rate limiting. Rate limiting is applied on the IPoE interface, on ingress, egress, or both. Egress rate limiting should not be used concurrently with hierarchical QoS.

The rate limit is controlled by a policer, in charge of dropping traffic that does not fulfill a given traffic profile.

See also

The Static QoS Rate Limiting Section details how rate limiting works.

The rate limiting feature can be configured statically through the CLI:

vsr running config# / vrf main ipoe-server rate-limit
vsr running rate-limit# ingress bandwidth 100M
vsr running rate-limit# ingress burst 5M
vsr running rate-limit# ingress excess-bandwidth 20M
vsr running rate-limit# ingress excess-burst 1M
vsr running rate-limit# egress bandwidth 100M
vsr running rate-limit# egress burst 5M
vsr running rate-limit# egress excess-bandwidth 20M
vsr running rate-limit# egress excess-burst 1M
vsr running rate-limit# commit
Configuration committed.

It can also be configured through RADIUS: in this case, it overrides the static configuration, if any. The 6WIND-limit RADIUS attribute can be used at session establishment (Access-Accept), or by a change of authorization (CoA).

Note

In CLI configuration, the rate limits are always expressed in throughput and not in packets per second, as can be the case for the RADIUS attribute.

Lawful Interception

6WIND Virtual Service Router implements network equipment lawful intercept capability. The current Virtual Service Router version supports RADIUS based Lawful Interception.

RADIUS based Lawful Interception

The RADIUS-Based Lawful Interception feature provides a mean of conducting Lawful Interception of traffic data. Intercept requests are transmitted from the RADIUS server to the Virtual Service Router using Access-Accept packets or Change of Authorization (CoA) Request packets. Data traffic going to or from an intercepted IPoE session is duplicated then forwarded to a mediation device.

../../../_images/bng_lawful_interception.svg

Several RADIUS attributes are used to configure the Lawful Interception feature. For instance, 6WIND-LI-Action, 6WIND-LI-Identifier, 6WIND-LI-Mediation-Device-IP and 6WIND-LI-Mediation-Device-Port must be specified to activate the interception. See section 6WIND vendor-specific RADIUS attributes for more details.

Interception can be triggered either through Access-Accept packets or COA Request packets. When an intercept target initiates a connection, the RADIUS server receives an Access-Request packet and responds with an Access-Accept packet containing the four RADIUS attributes. On reception of the 6WIND-LI-Action attribute with value “Enable”, the Virtual Service Router initiates traffic data duplication at the beginning of the new session. The duplicated data is then forwarded to the mediation device specified by the 6WIND-LI-Mediation-Device-IP and 6WIND-LI-Mediation-Device-Port attributes. CoA-Request packets can be used to configure Lawful Interception on intercept targets with established sessions.

Important

The Lawful Interception module rejects CoA-Request packets that contain attributes other than the Acct-Session-ID and the four required Lawful Interception ones. Processed CoA-Requests are acknowledged by the Lawful Interception module with a CoA-ACK on success or rejected with a CoA-NAK when the passed attributes are invalid or incomplete. For an already established intercept session, a CoA-Request may only change a subset of the Lawful Interception attributes.

Intercepted data traffic is sent to mediation device encapsulated in UDP packet with the following header format:

0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        6WIND-LI-Identifier                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Session ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Data                               |
|                                                               |

Important

It is mandatory to use an interface handled by the fast path to send data traffic to the mediation device.

Note

The Mediation device should support UDP encapsulated packets with format described above.

Step 1: FreeRADIUS server configuration

Here is a configuration file example with FreeRadius to activate Lawful Interception for client_1 user :

client_1 Cleartext-Password := "test123"
        Acct-Interim-Interval = 15,
        6WIND-LI-Action = Enable,
        6WIND-LI-Identifier = 123456,
        6WIND-LI-Mediation-Device-IP = "10.175.0.2",
        6WIND-LI-Mediation-Device-Port = 8000

In order to deactivate Lawful Interception, RADIUS CoA can be configured with the following configuration block :

update coa {
    Acct-Session-Id = "%{Acct-Session-Id}"
    6WIND-LI-Action = Disable
}

Note

6WIND vendor-specific RADIUS dictionary defines the attributes used in the example. Therefore, it must be included in RADIUS server dictionary.

Step 2: Configure the fast path limit

Set the maximum number of running Lawful Interception, (by default 8). This value will be shared by all ppp-server and ipoe-server instances running on the Virtual Service Router.

vsr running config# / system fast-path limits
vsr running limits# lawful-interception-max 16

Step 3: Configure RADIUS interception for the IPoE server

Configure how to contact the mediation device with the following parameters:

  • VRF to use (by default, VRF where IPoE server is running)

  • source IPv4 address if 6WIND-LI-Mediation-Device-IP is an IPv4 address

  • source IPv6 address if 6WIND-LI-Mediation-Device-IP is an IPv6 address

If no source IP address with the same version as 6WIND-LI-Mediation-Device-IP, the system will choose the best available address.

vsr running config# / vrf main ipoe-server auth radius interception
vsr running interception# source-ipv4 10.50.0.1
vsr running interception# source-ipv6 fd00:50::1
vsr running interception# vrf data

Step 4: Show IPoE server lawful-interception state

vsr running config# show state vrf main ipoe-server auth radius interception
interception
    enabled true
    source-ipv4 10.50.0.1
    source-ipv6 fd00:50::1
    vrf data
    ..

Step 5: Show number of current Lawful Interception running

vsr running config# show fast-path table-usage | match lawful-interception
lawful-interception  0/8

Step 6: Show Lawful Interception global statistics

vsr running config# show fast-path statistics lawful-interception all
fast-path statistics
    lawful-interception
        output-packets 0
        dropped-no-next-hop 0
        dropped-duplication-failures 0
        dropped-prepend-failures 0
        ..
    ..

IPoE server statistics

The CLI provides statistics via the command show ipoe-server statistics:

vsr> show ipoe-server statistics vrf main
IPoE counters
active   : 5
starting : 0
delayed  : 0

This command also provides per interface and per dynamic-vlans sessions statistics using the subcommand sessions:

vsr> show ipoe-server statistics vrf main sessions
interface active starting finishing
========= ====== ======== =========
eth1           4        0         0
eth2           1        0         0

TOTAL          5        0         0

vsr> show ipoe-server statistics vrf main sessions interface eth1
vlans       active starting finishing
=====       ====== ======== =========
none             1        0         0
0x8100-2001      1        0         0
0x8100-2002      2        0         0

TOTAL            4        0         0

vsr> show ipoe-server statistics vrf main sessions interface eth1 vlans 0x8100-2002
vlans                   active starting finishing
=====                   ====== ======== =========
0x8100-2002                  1        0         0
0x8100-2002,0x88a8-1234      1        0         0

TOTAL                        2        0         0

Display IPoE sessions

The following command displays the list of IPoE sessions:

vsr> show ipoe-server session vrf main
interface username mac address       ip address    status uptime   l3vrf  vlans                   server
========= ======== ================= ==========    ====== ======   =====  =====                   ======
eth1      client_1 0c:d6:7d:3b:1d:c4 192.168.1.24  active 00:00:21 l3vrf1 0x8100-2001             172.16.0.1
eth1      client_2 0c:94:2c:91:12:d4 192.168.1.25  active 00:00:21 l3vrf2                         172.16.0.1
eth1      client_3 0c:94:05:c0:ef:78 192.168.2.150 active 00:00:21        0x8100-2002             172.16.0.2
eth1      client_4 0c:76:66:b9:7a:4c 192.168.1.32  active 00:00:20        0x8100-2002,0x88a8-1234 172.16.0.1
eth2      client_1 0c:34:64:85:ae:5d 192.168.2.157 active 00:00:20                                172.16.0.2

Match rules can be applied to the show ipoe-server session command. Each rule acts as a logical AND operation:

vsr> show ipoe-server session vrf main match interface eth2 username client_1
interface username mac address       ip address    status uptime   l3vrf vlans server
========= ======== ===========       ==========    ====== ======   ===== ===== ======
eth2      client_1 0c:34:64:85:ae:5d 192.168.2.157 active 00:00:20             172.16.0.2

More details about each session can be displayed using the details input parameter of the show ppp-server session command:

vsr> show ipoe-server session vrf main details match interface eth2 username client_1
*********************************
Interface: eth2
User name: client_1
MAC address: 0c:34:64:85:ae:5d
IP address: 192.168.2.157
Status: active
Up since: 00:00:22
l3vrf: none
Vlans: none
Server: 172.16.0.2
IPv6 delegated prefix: none
Inbound interface: eth2
Acct-Session-Id: 5853b29ee0b1d576
Circuit ID: none
Remote ID: none
QoS template: none
Incoming rate limit: none
Outgoing rate limit: none
*********************************

See also

Please refer to IPoE server command reference for more details.

Terminate IPoE sessions

You can terminate all IPoE sessions using flush ipoe-server session all:

vsr> flush ipoe-server session vrf main all
Sessions terminated: 5

Instead, if you want to terminate specific sessions, you can use match instead of all. Each match rule acts as a logical AND operation:

vsr> flush ipoe-server session vrf main match interface eth2 username client_1
Sessions terminated: 1

See also

Please refer to IPoE server command reference for more details.

Troubleshooting

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

Prevent service restart on configuration change

Some configuration nodes (identified in the YANG model by the change-implies-service-restart extension) require a service restart to be taken into account if their value is updated.

In production, this can be a problem because it would cause the active IPoE sessions to be closed.

A configuration node can be used to prevent the service restart:

vsr running config# vrf main ipoe-server
vsr running ipoe-server# prevent-restart-on-change true

If prevent-restart-on-change is set to true, a validation step done before applying the new configuration will refuse any update that would cause a service restart. In this case, a message is displayed to the user:

vsr running ipoe-server# qos enabled <?>
  true|false           Enable QoS setting through Radius.
                       Default: true, change implies service restart.
vsr running ipoe-server# qos enabled true
vsr running ipoe-server# commit
ERROR: Cannot apply ipoe-server p configuration while running: qos/enabled
Unset prevent-restart-on-change or restart the service.
ERROR: Failed to set running configuration.

To apply the requested changes, the service has to be stopped first, by setting enabled to false.

vsr running ipoe-server# enabled false
vsr running ipoe-server# commit
Configuration committed.
vsr running ipoe-server# enabled true
vsr running ipoe-server# qos enabled true
vsr running ipoe-server# commit
Configuration committed.