Junos OS

Hi,

it appears that configuring the framed-mtu vsa on the RADIUS is not sending the mtu to the CPE.

I notice at the following URL:

https://www.juniper.net/documentation/en_US/junos/topics/reference/general/subscriber-management-predefined-variables-corresponding-radius.html

That there is a Junos command that could achieve this as follows:

$junos-interface-mtu

I don't know how to configure this on the LNS though. Does anyone know how to configure this?

Thanks

Read this doc you this option works only with 18.x junos . You can pass framed-mtu from radius that will be mapped to $junos-interface-mtu which can be configured for inet / inet6 address-family  like this

family inet { 
               mtu $junos-interface-mtu; 
               unnumbered-address lo0.0 preferred-source-address 100.0.0.1; 
            } 
            family inet6 { 
               mtu $junos-interface-mtu; 
               unnumbered-address lo0.0 preferred-source-address ::100.0.0.1; 
            } 

But you can not pass this option to CPE. 

P.S. for ppp (pppoe/l2tp) mru is negotiated with client , so we do not need this option... 

Thank you.

How is it that some ISPs can pass an MTU of 1500 and still have all internet access, yet I am having an issue where anything above 1492 causes problems?

Hi,

The  junos "framed-mtu" VSA is use case primarily for dynamic VLANs for DHCP/DHCPv6 or IPoE/IPv6oE and more like per-subscriber based mtu. So instead of manual provisioning of mtu for static IFL, with framed-vsa VSA subscriber IFL can specify MTU through its dynamic profile.

In case for PPPoE/L2TP, the MTU/MRU is negotiated during the LCP phase and mandates a MRU of 1492.
The PPPoE header = 6 octets, and PPP Protocol_ID = 2 octets total of 8 octets. (8 minus 1500 = 1492) hence PPP MTU must NOT be greater than 1492, unless both the PPPoE client and server have indicated the ability to support a larger MRU.
Per general standards, MRU/MTU negotiation during the LCP, client should honor/accept mtu/mru negotiated by server.

Ref to RFC:
https://tools.ietf.org/html/rfc4638#section-5.1
https://tools.ietf.org/html/rfc2516

Hi Karand 

thanks. Is there a way around this, say like enabling jumbo frames or is this likely to cause issues?

I am still a little confused.....

I obviously cannot go to another ISP and ask how they do this, but, we are in a testing phase currently and when I connect the CPE to our network I cannot get the CPE to show anything above 1492 (as per the white papers and your notes above)..... but when I connect to another ISP the CPE is showing as 1500 MTU, and this is not manually configured, this has to be being pushed to the CPE somehow and it is not 1492.....

Thanks

I have tried the following:

Set dynamic-profiles <profile-name> interfaces $junos-interface-ifd-name unit $junos-interface-unit ppp-options mru 1500

Set dynamic-profiles <profile-name> interfaces $junos-interface-ifd-name unit $junos-interface-unit ppp-options mtu 1500

This had an affect but not a good one......

So, I tried the following:

Set access group-profile <profile name> ppp ppp-options mru 1500    -----------  Maximum Receive Units

Set access group-profile <profile name> ppp ppp-options mtu 1500    -----------  Maximum Transmission Units

But the MTU on the CPE remains at 1492....

I will quit testing this for the moment as I now need to work on dual statck.... Another question coming:

I think I have found the issue (Maybe)..... Disable LCP Negotiation. I can't seem to find the command reference to complete this, does anyone know please?

Thanks

Okay, I have found out the following through trial and error:

LCP Negotiation = of - This means the upstream ISP LAC will negotiate MTU with the CPE (Not what we want)

LCP re-negotiation = on - This means the LNS will negotiate with the CPE (Exactly what we want)

So, now I have an MTU of 1500 at the CPE and the LNS.

So, the original question still stands..... I cannot access most websites with this MTU, yet, when I connect to a different provider other than ourselves it works fine at 1500? We must be missing something somewhere?

I have read something about ICMP Unreachables but we are not blocking any ICMP currently..... 

Okay, I think I have it.... MSS Clamping.... however, I can only find the configuration for a pp interface, but I am using an si interface..... anyone tell me how to do this for the LNS to CPE negotiation please?

I will close this as resolved.

mss clamping will be required on the PE interface. Given that our scenario indictaes the following route:

User --MTU1500--CPE --MTU1492 -- LNS (PE) (mss Clamping here?) (will then be 1492 - 40) -- Core (PE ) (MSS Clamping here?)

So, I guess my final question is....Where should I apply the tcp-mss clamping? On the LNS PE or the Core PE linked via eBGP to the upstream provider?

Problem solved. Here is the actual command I used for those that want to know:

I completed this command on the PE egress eBGP interface facing the upstream ISP:

Please note that MSS size works at TCP which  is hardware not software, so you must have the correct card (In our case MPC)

set interfaces xe-1/2/2 unit 0 family inet tcp-mss 1410