[long-reading] I am struggling to get the working DHCP/subscriber administration connectivity on a Juniper MX router. Presently I used to be in a position to determine the working configuration for the DHCP pool to assign IP addresses to purchasers, however then I am caught on the IP connectivity points.
My configuration elements do look as following:
> present configuration entry address-assignment
pool ipoe {
household inet {
community 10.10.16.0/21;
vary vlan16 {
low 10.10.17.0;
excessive 10.10.22.255;
}
dhcp-attributes {
maximum-lease-time 600;
name-server {
1.1.1.1;
8.8.8.8;
}
router {
10.10.16.1;
}
possibility 150 ip-address 10.10.10.30;
}
}
}
> present configuration dynamic-profiles
DHCP {
routing-instances {
"$junos-routing-instance" {
interface "$junos-interface-name";
}
}
interfaces {
demux0 {
unit "$junos-interface-unit" {
no-traps;
proxy-arp;
demux-options {
underlying-interface "$junos-underlying-interface";
}
household inet {
mac-validate strict;
rpf-check fail-filter RPF-ALLOW-DHCP;
demux-source {
$junos-subscriber-ip-address;
}
unnumbered-address "$junos-loopback-interface";
}
}
}
}
}
VLAN-DHCP {
interfaces {
"$junos-interface-ifd-name" {
unit "$junos-interface-unit" {
demux-source inet;
no-traps;
proxy-arp unrestricted;
vlan-tags outer "$junos-vlan-id";
household inet {
unnumbered-address lo0.0 preferred-source-address 10.10.16.3;
}
}
}
}
}
> present configuration entry profile RAUTH
accounting-order radius;
authentication-order radius;
radius {
authentication-server 10.10.10.12;
accounting-server 10.10.10.12;
choices {
nas-identifier mx5;
}
}
radius-server {
10.10.10.12 {
port 1812;
accounting-port 1813;
secret "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"; ## SECRET-DATA
}
}
accounting {
order radius;
}
> present configuration system providers dhcp-local-server
pool-match-order {
ip-address-first;
}
authentication {
password soajigwecInFitEd;
username-include {
mac-address;
}
}
group default {
dynamic-profile DHCP;
interface ge-1/0/0.16;
}
> present configuration system providers subscriber-management
overrides {
no-unsolicited-ra;
}
allow;
> present configuration interfaces ge-1/0/0
description "-> clients and infrastructure";
flexible-vlan-tagging;
auto-configure {
vlan-ranges {
dynamic-profile VLAN-DHCP {
settle for dhcp-v4;
ranges {
16-16;
}
}
}
remove-when-no-subscribers;
}
encapsulation flexible-ethernet-services;
[...]
unit 16 {
description "Workplace Infrastructure, SIP Telephones";
vlan-id 16;
household inet {
filter {
enter office-and-sip;
}
service {
enter {
service-set nat-lan;
}
output {
service-set nat-lan;
}
}
handle 10.10.16.1/21;
}
household inet6 {
handle 2a09:d5c0::1/64;
}
}
This enables MX to efficiently present IP addresses on vlan 16 and one-directional connectivity for vlan 16 DHCP-enabled gadgets:
> present dhcp server binding
IP handle Session Id {Hardware} handle Expires State Interface
10.10.17.175 13930 00:1a:e8:23:99:1c 583 BOUND ge-1/0/0.16
10.10.17.174 13928 00:1b:0c:db:d1:6d 373 BOUND ge-1/0/0.16
10.10.17.169 13931 00:50:56:91:8a:6b 497 BOUND ge-1/0/0.16
10.10.17.170 13929 34:64:a9:69:06:4d 580 BOUND ge-1/0/0.16
What remains to be non-functional, is the bidirectional connectivity to those hosts: I am shocked to see, that, for example 10.10.17.169 is ready to ping any host in LAN or WAN efficiently, however this works just for DHCP-client-originating IP periods ! Au contraire, when some host in my LAN pings 10.10.17.169 and the seeion goes by way of the MX, the ICMP reply packets are misplaced on the MX. I’ve put in wireshark on 10.10.17.169 and the bizarre factor is that I can see pairs of ICMP-request/ICMP-reply in all of the instances mentioned – when 10.10.17.169 sends ICMP to, for instance, 10.10.10.2, and when 10.10.10.2 (a bunch subsequent to MX) sends ICMP to 10.10.17.169, however ICMP replies are seen solely when 10.10.17.169 initiates ICMP, – when 10.10.10.2 sends ICMP, it by no means will get ICMP replies.
I believe thats in all probability as a result of subscriber routes do look peculiar:
inet.0: 994598 locations, 1977204 routes (105 lively, 0 holddown, 1977094 hidden)
+ = Lively Route, - = Final Lively, * = Each
10.10.17.169/32 *[Access-internal/12] 04:54:10
Personal unicast
I can see that every subcriber has it is personal dynamic interfaces related:
> present subscribers
Interface IP Tackle/VLAN ID Consumer Identify LS:RI
demux0.3221231400 10.10.17.174 001b.0cdb.d16d default:default
demux0.3221231401 10.10.17.170 3464.a969.064d default:default
demux0.3221231402 10.10.17.175 001a.e823.991c default:default
demux0.3221231403 10.10.17.169 0050.5691.8a6b default:default
I supposed that rpoxy arp may clear up this, and, as you possibly can see above, I’ve it configured above, however nonetheless the connectivity is pseudo-unidirectional.