Junos OS

 View Only
last person joined: 2 days ago 

Ask questions and share experiences about Junos OS.
  • 1.  dhcpv6 relay and demux0

    Posted 08-23-2023 13:51

    I have an MX204 acting as a PPPoE BNG and I recently setup an eth sub-interface that is within a VRF and has a dhcp and dhcpv6 relay configuration.  This is functioning, however I noticed that the MX is creating a demux0 interface for the dhcpv6 subscriber when they come online.  I have other MX204s that are NOT PPPoE BNGs thus do not have "subscriber-management" enabled and they are not doing this.

    So my question is: is there anyway to force the MX to not create a demux0 interface for each dhcp subscriber and instead just share the underlying eth sub-if?

    The reason that this apparently matters is because v6 is not functioning correctly as a result.  I have router-advertisements enabled on the sub-interface for the v6 prefix and when the clients send an RS, the MX is not seeing them.  The "Solicits received" in "show ipv6 router-advertisements" is staying at 0.  I've done some troubleshooting and the issue seems to be the demux0 interface being created.  I believe those RS messages are arriving internally on the demux rather than the eth sub-interface itself.

    Every client on the eth sub-if is sharing a v4 /24 and a v6 /64 and the dhcp server is sending each client a PD.  For v4, I am using forward-only and for v6 I am tracking the binding so that the /56 PD route can be tracked and installed in the FIB.  I want the MX to act as a very basic DHCP helper relay and not do any demux logic.  The shaping and authentication is handled on a downstream fiber OLT.

    Again this config works completely fine with no demux0 being created in all  my other MX204s that do not have subscriber-management enabled, so I'm trying to figure out how to replicate that behavior on this MX which is currently acting as a PPPoE BNG on other interfaces.

    Here is the routing-instance configuration:

    instance-type vrf;
    routing-options {
        auto-export;
    }
    forwarding-options {
        dhcp-relay {
            dhcpv6 {
                group all {
                    active-server-group grp1;
                    interface et-0/0/0.200;
                }
                server-group {
                    grp1 {
                        <hidden>
                    }
                }
            }
            server-group {
                grp1 {
                    10.192.32.2;
                    10.192.32.6;
                }
            }
            group all {
                active-server-group grp1;
                overrides {
                    trust-option-82;
                }
                forward-only;
                interface et-0/0/0.200;
            }
        }
    }
    interface et-0/0/0.200;
    route-distinguisher <hidden>:702;
    vrf-import CGN-INET-2-IMPORT;
    vrf-export CGN-INET-2-EXPORT;
    vrf-table-label;



  • 2.  RE: dhcpv6 relay and demux0

    Posted 09-18-2023 00:09

    Hi Bro.

    I have same isssue. On the customer box, MX960 also created demux for DHCPv6 subscriber (MX960 is only Relay function). The v6 did not work normaly. I'm trying to use the same configurtion in my lab, but cannot replicate this issue. In my lab, no demux interface is created.

    Do you fix this issue ?




  • 3.  RE: dhcpv6 relay and demux0

    Posted 09-18-2023 17:09

    No, I've not fixed the issue and I am going to put in a different router just for dhcpv6 termination.

    Does the MX960 have subscriber-services enabled?  That is the only thing I can think that is triggering this behavior because I have other MX routers that work fine and don't create the demux interface, but all of those have subscriber-services disabled.




  • 4.  RE: dhcpv6 relay and demux0

    Posted 09-25-2023 01:54

    Yes, MX960 is enabled subcriber-manager feature. One WA, you can use the knob "forward-only" under dhcpv6 relay. It would not create the demux interface to manage binding.

    While troublshooting, we found that MX did not reply NS packet from client. And when you were unable to ping to MX, from client point of view, the NDP to MX was FAILED.