Junos OS

Expand all | Collapse all

Issue with MTU on LNS/CPE

Jump to Best Answer
  • 1.  Issue with MTU on LNS/CPE

     
    Posted 11-15-2018 03:45

    Hi,

     

    We have an issue where certain "Streamed" services only seem to work under a specific, specified MTU size. For example, a BT Home Viewing Box does not seem to function at all unless the MTU on the CPE is configured at 1432.

     

    So, as we may well require different MTU sizes for differing DSL subscribers we needed to configure this dynamically. So, I completed the following configuration on:

     

    LNS:

    set dynamic-profiles dyn-hex-lns-profile interfaces "$junos-interface-ifd-name" unit "$junos-interface-mtu"

     

    RADIUS:

    Framed-mtu = <size of MTU required>

     

    I confirmed the settings did indeed change with the followjgng command:

    run show subscribes username <username> extensive

     

    And I get the MTU showing in there as would be expected. However, the MTU on the actual CPE remains unchanged. So, this leads me to the following questions:

     

    1: Is the command above the corerct one for dynamically assigning MTU to subscribers?

    2: When looking at the output of "run show subscribers username <username> extensive, is the information shown what has been sent by the CPE after RADIUS assignment, or from the RADIUS before assigning to the CPE? (RADIUS sends to LNS which should forward dynamically).

    3: If the above is not the correct way to complete this, can someone please point me in the right direction for the configuration?

     

    Thanks



  • 2.  RE: Issue with MTU on LNS/CPE

     
    Posted 11-15-2018 03:53

    Initial LCP parameter is initiated b/w CPE and LAC based on MRU value. Lowest MRU is neogtiated.

    I don't think you can set CPE MTU from BRAS.

     

    Regards,
    Rahul Nayar



  • 3.  RE: Issue with MTU on LNS/CPE

     
    Posted 11-15-2018 03:56

    Hi,

     

    answers to your questions:

     

    1: Is the command above the corerct one for dynamically assigning MTU to subscribers?

     

    Yes > you're assigning framed MTU. Though case of L2TP/LNS, shouldn't be changing the default MTU.

     

    2: When looking at the output of "run show subscribers username <username> extensive, is the information shown what has been sent by the CPE after RADIUS assignment, or from the RADIUS before assigning to the CPE? (RADIUS sends to LNS which should forward dynamically).

     

    The o/p in >show subscribers username <username> extensive for  an active (state) subscriber meaning its successful session. This information is post getting all the attributes locally & or via radius. Remember, if you're returning an attribute from AAA for subscriber, radius/aaa has higher preference than what is configured locally.

     

    3: If the above is not the correct way to complete this, can someone please point me in the right direction for the configuration?

     

    from show subscribers username <username> extensive, get the o/p for the subscriber interface:

     

    > show interfaces si-0/0/0.xyz extensive
    > show ppp interface si-0/0/0.xyz extensive

     



  • 4.  RE: Issue with MTU on LNS/CPE

     
    Posted 11-15-2018 04:58

    Hi Rahul / Karan,

     

    Although the o/p from "run show subscribers username <username> extensive" shows the correct setting I put in the RADIUS VSA (Framed-mtu), the o/p from the "run show interfaces si-1/1/0.xxxxx extensive" shows the MTU as STILL being 1500 no matter what I set the CPE or the RADIUS too. Should that not change with what I configure the CPE too?

     

    Rahul: Could you please offer a bit more explanation for the MRU settings? For example:

     

    Are you saying that the LNS to CPE negotiate the MTU to the lowest setting (whichever is lower - CPE or LNS)?

     

    From the perspective of the Internet itself then the MSS takes over at that point, I would have thought,

     

    This MTU setting is not normally an issue, it is only if certain subscribers are utilising services (streaming it seems) and require a lower MTU....

     

    The ongoing issue is that we need to be able to supply CPE devices that will require no configuration from subscribers, as, being fickle, they may not subscribe to our services.



  • 5.  RE: Issue with MTU on LNS/CPE

     
    Posted 11-15-2018 05:29

    I had tested this a while ago and I believe its expected in case of L2TP/LNS.

    The base MTU for si-x/y/z is always 9192 & inet mtu in this case would be 1500.

     

    re0# run show interfaces si-1/0/0.0
      Logical interface si-1/0/0.0 (Index 321) (SNMP ifIndex 590)
        Flags: Up Point-To-Point SNMP-Traps Encapsulation: Adaptive-Services
        Input packets : 0
        Output packets: 0
        Protocol inet, MTU: 9192
        Max nh cache: 0, New hold nh limit: 0, Curr nh cnt: 0, Curr new hold cnt: 0, NH drop cnt: 0
          Flags: Sendbcast-pkt-to-re, Receive-options, Receive-TTL-Exceeded
     

    re0# run show subscribers
    Interface           IP Address/VLAN ID                      User Name                      LS:RI
    si-1/0/0.3221226232 10.xx.0.74                             karand@l2tp.net           default:default
     
    re0# run show subscribers extensive
    Type: L2TP
    User Name: karand@l2tp.net
    IP Address: 10.xx.0.74
    IP Netmask: 255.255.255.255
    Domain name server inet: 10.x.x.3 10.x.x.3
    Logical System: default
    Routing Instance: default
    Interface: si-1/0/0.3221226232
    Interface type: Dynamic
    Underlying Interface: si-1/0/0.3221226232
    Dynamic Profile Name: DYNAMIC-PROFILE-1
    Dynamic Profile Version: 1
    State: Active
    Radius Accounting ID: 12223
    Session ID: 12223
    PFE Flow ID: 848
    Login Time: 2018-08-23 14:05:46 IST
    IP Address Pool: dhcpv4
     
    re0# run show interfaces si-1/0/0.3221226232 extensive
     Logical interface si-1/0/0.3221226232 (Index 536871760) (SNMP ifIndex 200000848) (Generation 808)
        Flags: Encapsulation: Unspecified
        Bandwidth: 0
        Traffic statistics:
         Input  bytes  :                 1104
         Output bytes  :                  192
         Input  packets:                   24
         Output packets:                   24
        Transit statistics:
         Input  bytes  :                 1104                    0 bps
         Output bytes  :                  192                    0 bps
         Input  packets:                   24                    0 pps
         Output packets:                   24                    0 pps
        Protocol inet, MTU: 1500        <<<<<<<<<<<
        Max nh cache: 0, New hold nh limit: 0, Curr nh cnt: 0, Curr new hold cnt: 0, NH drop cnt: 0
        Generation: 0, Route table: 0
          Flags: Unnumbered
          Donor interface: lo0.0 (Index 324)
          Addresses, Flags: Is-Primary
            Destination: Unspecified, Local: 10.xx.0.1, Broadcast: Unspecified, Generation: 0
     
    re0# run show ppp interface si-1/0/0.3221226232 extensive
      Session si-1/0/0.3221226232, Type: PPP, Phase: Network
       Keepalive settings: Interval 30 seconds, Up-count 1, Down-count 3
       RE Keepalive statistics:
            LCP echo req Tx        : 0 (last sent: never)
            LCP echo req Rx        : 0 (last seen: never)
            LCP echo rep Tx        : 0
            LCP echo rep Rx        : 0
            LCP echo req timeout   : 0
            LCP Rx echo req Magic Num Failures: 0
            LCP Rx echo rep Magic Num Failures: 0
        LCP
          State: Opened
          Last started: 2018-08-23 14:05:46 IST
          Last completed: 2018-08-23 14:05:46 IST
          Negotiated options:
            Authentication protocol: pap, Magic number: 1581768641, Initial Advertised MRU: 1500
        Authentication: PAP
          State: Grant
          Last started: 2018-08-23 14:05:46 IST
          Last completed: 2018-08-23 14:05:46 IST
        IPCP
          State: Opened
          Last started: 2018-08-23 14:05:47 IST
          Last completed: 2018-08-23 14:05:47 IST
          Negotiated options:
            Local address: 10.xx.0.1, Remote address: 10.xx.0.74
          Negotiation mode: Passive
     
     
    re0# run ping 10.xx.0.74 size 1432 count 1
    PING 10.xx.0.74 (10.xx.0.74): 1432 data bytes
    1440 bytes from 10.xx.0.74: icmp_seq=0 ttl=64 time=1.348 ms
     
    --- 10.xx.0.74 ping statistics ---
    1 packets transmitted, 1 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 1.348/1.348/1.348/0.000 ms

    This packet consist of: IP + UDP + L2TP + PPP + IP + ICMP + DATA.

     


    Doesn't change in case if L2TP (and i'd try to return framed-mtu xxxx mtu from AAA)
    BTW, for tcp-mss, it aids to limit/aviod or say prevent packet fragmentation and to protect against packet loss that can occur when a packet must be fragmented to meet the MTU size.

     

    More info here:

    https://www.juniper.net/documentation/en_US/junos/topics/concept/pppoe-subscriber-access-mru-mtu-overview.html

     

     



  • 6.  RE: Issue with MTU on LNS/CPE

     
    Posted 11-15-2018 06:15

    Hi Karan,

     

    Thank you. I can confirm that I see the same..... so I guess, to re-phrase the original question:

     

    How can I affect the MTU on the CPE dynamically as I have tried the differing methods explained with no positive outcome... maybe I am missing something somewhere.....

     

    Is there a specific command I require to be able to set the MTU differently for separate subscribers?



  • 7.  RE: Issue with MTU on LNS/CPE

     
    Posted 11-15-2018 07:53

    As an add on, I can control the whole of PPP through the group-profile, that's not a problem.

     

    The group-profile options though affects ALL subscribers with the same MTU, whereas I need different MTU for different subscribers.

     

    According to Juniper documentation the dynamic command I mentioned within the dynamic-profile is supported from Junos 18 onwards.... but it doesn't seem to function as stated.


    Could I have some clarification on that please guys?



  • 8.  RE: Issue with MTU on LNS/CPE
    Best Answer

     
    Posted 11-16-2018 07:53

    Okay, I have found out the reason this does not work.

     

    It appears that this command is only available for "VLANS"..... The dynamic option is not available for DSL subscribers. I guess then that there is no way of controlling this 😞