IPoE, as well as Client-VLAN and DHCP Option 82

In this article I will describe what the Internet access technology IPoE is, which actually does not exist. And also I will tell about the Client-VLAN scheme and about 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 technologies of Internet access 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 flows inside the tunnel. The main difference between these protocols is that they work at different levels of the OSI network model. PPPoE operates at the second (link) level, adding special tags that identify a specific tunnel in Ethernet frames. PPTP operates at the third (network) level, packaging 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 over Ethernet, roughly speaking, is a regular LAN. The subscriber is given at best a static or dynamic white IP address, at worst a gray IP with NAT. Access control in this case can be done using IP-MAC bindings on access switches or BRAS or allocating VLAN for each subscriber (the so-called Client-VLAN).

Client-VLAN

When using Client-VLAN technology, the problem arises: how to save IP-addresses? After all, if you think about it, each client should be assigned a / 30 subnet. In fact, the problem is easily solved. I give 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 subnet 192.0.2.0/24 is recommended by the IANA for use in the examples.

This is a classic Cisco ip unnumbered Linux implementation. The IP gateway (192.0.2.1) hangs on the loopback interface, is made unreachable for the entire subnet, so that the packets go only to the hosts for which routing is registered. Next, the VLAN rises and the routing is written to a specific host (mask / 32) from the src gateway. And you can do 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 IP is 192.0.2.101/24.
')

Proxy_arp

Another problem you may encounter is that there is no connection 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 this, since they are in different vlans. The proxy_arp technology serves to solve this problem. Its essence is that the router, when receiving ARP requests from the interface, will check whether it has the requested IP on other interfaces. If there is, then in response to an ARP request, it will issue its MAC. Thus, the packets will be sent to the router, which will take care of their delivery. The proxy_arp for a specific interface is enabled 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 simplifies network configuration on the subscriber side to zero. Stuck patchkord and you're online. Only the question arises: how does DHCP know to whom to issue which address? You can identify by MAC, especially if you are already using IP-MAC bindings. But MAC bindings are fraught with frequent support calls, since Subscribers sometimes change equipment. The extension of the protocol DHCP - Option 82 will help to cope with this problem. Option 82 contains two fields:

• Agent Circuit ID — The DHCP Relay port number on which the DHCP request arrived.
• Agent Remote ID is a certain identifier of DHCP Relay itself.

At the same time, access switches to which subscribers are directly connected act as DHCP relays. The Agent Remote ID is usually used as a switch MAC (by default in D-Link). Option 82 is supported by a wide range of equipment, including those typical for the 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, option 82 is added and the request is no longer transmitted by Broadcast, but directly to the DHCP server, i.e. This is a full DHCP Relay. dhcp_local_relay works for specific VLANs, but the query is not actually relaits, and option 82 is simply added to it.
Basic dhcp_relay settings on D-Link:

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

  enable dhcp_local_relay
 config dhcp_local_relay vlan 101 state enable 

Finally, I will provide the 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 given 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 {
	 # no option 82
	 # write to the log the given 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 - IP of the subscriber connected to the switch with MAC 0: c: 29: ec: 23: 64, on port 1
 # MAC address left, taken from VMWare virtuals
 # 192.168.0.0/24 - switch management subnet, DHCP requests will come from addresses on this subnet
 # these two subnets should be combined into one shared-network for proper operation

 shared-network test {

 subnet 192.0.2.0 netmask 255.255.255.0 {

	 # define class

	 class "v101" {

		 # determine the 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 in Agent Remote ID (ie, 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 issue IP class

	 pool {
		 range 192.0.2.101;
		 allow members of "v101";
	 }
 }

 subnet 192.168.0.0 netmask 255.255.255.0 {
 }

 }