IPoE as well as Client-VLAN and DHCP Option 82

In this article, I will describe what IPoE Internet access technology is, which does not actually exist. I will also talk about the Client-VLAN scheme and the DHCP option 82 (DHCP Option 82), which have become an integral part of this non-existent technology. All this, of course, from a technical point of view and with examples of configs.

There are many Internet access technologies for end users. Two are especially popular in Russia: PPTP and PPPoE. In both cases, a PPP tunnel is created, authentication is performed, and subscriber IP traffic goes inside the tunnel. The main difference between these protocols is that they work at different levels of the OSI network model. PPPoE works at the second (link) level, adding special tags that identify a specific tunnel to Ethernet frames. PPTP works at the third (network) level, packing IP packets in GRE.

IPoE

IPoE is fundamentally different from PPTP and PPPoE. In general, this technology does not exist. There is no RFC, there are no standards describing it. The term itself was coined, most likely in Russia, and is abstract. It means the following: IP over Ethernet . The meaning is exactly the same as decryption - IP-traffic on top of Ethernet, roughly speaking, an ordinary LAN. The subscriber is given at best a static or dynamic white IP address, in the worst case a gray IP with NAT. Access control in this case can be carried out using IP-MAC bindings on access switches or on BRAS or by allocating VLAN for each subscriber (the so-called Client-VLAN).

Client-VLAN

When using Client-VLAN technology , a problem arises: how to save IP addresses? After all, if you think about it, each client needs to allocate / 30 subnets. In fact, the problem is easily solved. Here is an example for a Linux-based router:

ip route add unreachable 192.0.2.0/24
ip addr add 192.0.2.1/32 dev lo
vconfig add eth0 101
ip link set eth0.101 up
ip route add 192.0.2.101/32 dev eth0.101 src 192.0.2.1

The 192.0.2.0/24 subnet is recommended by IANA for use in the examples.

This is the classic Cisco  ip unnumbered in Linux implementation. The gateway IP (192.0.2.1) is hung on the loopback interface, it is done unreachablefor the entire subnet so that packets go only to hosts for which routing is registered. Next, the VLAN rises and the routing to a specific host (mask / 32) from the srcgateway is registered . And you can do it a little differently (this once again demonstrates the flexibility of Linux):

ip route add unreachable 192.0.2.0/24
vconfig add eth0 101
ip link set eth0.101 up
ip addr add 192.0.2.1/32 dev eth0.101
ip route add 192.0.2.101/32 dev eth0.101

Or so:

ip route add unreachable 192.0.2.0/24
vconfig add eth0 101
ip link set eth0.101 up
ip addr add 192.0.2.1/24 dev eth0.101
ip route del 192.0.2.0/24 dev eth0.101
ip route add 192.0.2.101/32 dev eth0.101

All these options work, you can choose the one in which the interfaces are displayed in the most convenient way. In all cases, the subscriber's IP is 192.0.2.101/24.

Proxy_arp

Another problem you may encounter is that there is no communication between subscribers in different VLANs and with IP from the same subnet. Indeed, the subscriber system sees that the destination IP address is on the same subnet as it, and sends ARP requests to determine the MAC, but nothing comes of it, because they are in different VLANs. To solve this problem, proxy_arp technology is used . Its essence is that the router, when receiving ARP requests from the interface, will check if it has the requested IP on other interfaces. If there is, then in response to the ARP request it will issue its MAC. In this way, packets will be sent to the router, which will take care of their delivery. Enable proxy_arp for a specific interface as follows:

sysctl net.ipv4.conf.eth0 / 101.proxy_arp = 1

or

echo 1> /proc/sys/net/ipv4/conf/eth0.101/proxy_arp

DHCP Option 82

When using IPoE, DHCP will simplify the configuration of the subscriber-side network to zero. I stuck the patch cord and you are online. Only the question arises: how does DHCP know to whom which address to issue? Can be identified by MAC, especially if you are already using IP-MAC bindings. But MAC bindings are fraught with frequent calls to support, as subscribers sometimes change equipment. The expansion of the DHCP protocol - Option 82 will help to cope with this problem . Option 82 contains two fields:

• Agent Circuit ID - the port number of the DHCP relay to which the DHCP request arrived.
• Agent Remote ID - a certain identifier of the DHCP relay itself.

In this case, access switches, to which subscribers are directly connected, usually act as DHCP relays. As the Agent Remote ID, the MAC of the switch is usually used (by default in D-Link). Option 82 is supported by a wide range of equipment, including those typical of Russian providers D-Link DES-3526/3028/3200.
There are two DHCP relay modes on D-Link switches: dhcp_relay and dhcp_local_relay. dhcp_relay works globally, for all ports and VLANs, while option 82 is added and the request is no longer transmitted as a broadcast, but directly to the DHCP server, i.e. This is a full DHCP relay. dhcp_local_relay works for specific VLANs, but the request is essentially not relevant, and option 82 is simply added to it.
Basic dhcp_relay settings on D-Link's:

enable dhcp_relay
config dhcp_relay option_82 state enable
config dhcp_relay add ipif System 192.168.0.1

192.168.0.1 - The IP address of the DHCP server available in the management VLAN.
Basic settings of dhcp_local_relay:

enable dhcp_local_relay
config dhcp_local_relay vlan 101 state enable

And finally, I’ll give a basic config for ISC's DHCP with comments:

# write to the log
log (info, "***");
if exists agent.circuit-id {
	# option 82 is present
	# write to the log the issued IP address, Agent Remote ID, Agent Circuit ID
	log (info, concat ("* Leased", binary-to-ascii (10.8, ".", leased-address), "(with opt82)"));
	log (info, concat ("* Remote-ID:", binary-to-ascii (16.8, ":", substring (option agent.remote-id, 2.6))));
	log (info, concat ("* Port:", binary-to-ascii (10.8, "", suffix (option agent.circuit-id, 1))));
} else {
	# option 82 no
	# write to the log the issued IP address
	log (info, concat ("* Leased", binary-to-ascii (10.8, ".", leased-address), "(without opt82)"));
}
log (info, "***");
# in this example 192.0.2.101/24 - the IP of the subscriber connected to the switch with MAC 0: c: 29: ec: 23: 64, on port 1
# MAC address is left, taken from VMWare virtual machine
# 192.168.0.0/24 - switch management subnet, DHCP requests will come from addresses in this subnet
# these two subnets should be combined into one shared-network for correct operation
shared-network test {
subnet 192.0.2.0 netmask 255.255.255.0 {
	# define a class
	class "v101" {
		# define conditions for compliance with the class:
		# Agent Circuit ID = 1, Agent Remote ID = 0: c: 29: ec: 23: 64
		# note - leading zeros are not written to Agent Remote ID (i.e. c instead of 0c, etc.)
		match if (binary-to-ascii (10.8, "", suffix (option agent.circuit-id, 1)) = "1") and
			(binary-to-ascii (16.8, ":", substring (option agent.remote-id, 2.6)) = "0: c: 29: ec: 23: 64");
	}
	# actually we give out to an IP class
	pool {
		range 192.0.2.101;
		allow members of "v101";
	}
}
subnet 192.168.0.0 netmask 255.255.255.0 {
}
}