Description

In case of a fibre cut, dyn-ip clients will not get logged out as the client couldn’t send the disconnect message to the BNG.

In this case BNG should monitor the subscriber and delete the session when there is now incoming packets from the client.

Sometime you will notice that the session will not get deleted in BNG and when the fibre cut restores, same client wouldn’t be able to login to the BNG until we clear the old session.


Symptoms

 

You will notice the subscriber online even when there is a fibre cut and subscriber will not get logged out after idle time.

 

root@BNG> show subscribers user-name x.x.x.x extensive       

Interface            IP Address/VLAN ID           User Name           LS:RI

demux0.3221512664        x.x.x.x             x.x.x.x      default:default    

 

 

Customer has configured to monitor the session idle timeout by monitoring ingress traffic.

 

root@BNG> show configuration access profile  <profile-name>

accounting-order radius;

authentication-order radius;

radius {

  authentication-server [ x.x.x.x];

  accounting-server [ x.x.x.x];

  options {

    client-authentication-algorithm direct;

    client-accounting-algorithm direct;

    service-activation {

      dynamic-profile optional-at-login;

    }

  }

}

session-options {

  client-idle-timeout-ingress-only;

}

 

Also we can see that customer has the actual-transit-statistics knob as well. 

 

root@BNG> show configuration dynamic-profiles ip-demux-profile 

routing-instances {

  "$junos-routing-instance" {

    interface "$junos-interface-name";

    routing-options {

      access {

        route $junos-framed-route-ip-address-prefix {

          qualified-next-hop "$junos-interface-name";

          metric "$junos-framed-route-cost";

          preference "$junos-framed-route-distance";

        }

      }

    }

  }

}

interfaces {

  demux0 {

    unit "$junos-interface-unit" {

      actual-transit-statistics;

      proxy-arp;

      demux-options {

        underlying-interface "$junos-underlying-interface";

      }

      family inet {

        demux-source {

          $junos-subscriber-demux-ip-address;

        }

        filter {

          input "$junos-input-filter" precedence 50;

          output "$junos-output-filter" precedence 50;

        }

        unnumbered-address "$junos-loopback-interface";

      }

    }

  }

}

 

If you see the extensive output of the subscriber, you could see a large value as idle timeout.

 

root@BNG> show subscribers interface demux0.3221512664  extensive 

Type: DYN-IP

User Name: x.x.x.x

IP Address: x.x.x.x

Domain name server inet: x.x.x.x

Logical System: default

Routing Instance: default

Interface: demux0.3221512664

Interface type: Dynamic

Underlying Interface: demux0.915

Dynamic Profile Name: ip-demux-profile

Dynamic Profile Version: 1

MAC Address:xx:xx:xx:xx

Session Timeout (seconds): 605441

State: Active

Radius Accounting ID: 876809954

Session ID: 876809954

PFE Flow ID: 618754

VLAN Id: 915

Login Time: 2025-02-18 10:16:02 UTC

Service Sessions: 1

IPv4 Input Filter Name: 1000M-demux0.3221512664-in

IPv4 Output Filter Name: 1000M-demux0.3221512664-out

Accounting interval: 600

Dynamic configuration: 

 junos-input-filter: 1000M

 junos-input-ipv6-filter: 1000Mv6

 junos-output-filter: 1000M

 junos-output-ipv6-filter: 1000Mv6

 

 

Solution


When we check the configuration we could see that there is no idle timeout configured, and which will tent to take the default idle timeout which is too high.

Need to configure client-idle-timeout knob under under access profiles to adjust the idle timeout.


Example :


access {

  profile radius-profile {

    session-options {

      client-idle-timeout 10;

      client-idle-timeout-ingress-only;

    }

  }

}


Please refer KB37479 [juniper.net] & Session Options for Subscriber Access for more details.

Modification History

2025-03-12 : Article Created