Problem with PPPoE MTU ASR9K

[Vladimir Miropolskyj]

Hello,

The problem with opening of many sites from mobile devices (Android to Google Play) is observed
the subscribers connected on PPPoE if on subscriber wi-fi a router on the WAN MTU 1500 interface
everything works as to correct such problem?

It is observed on absolutely different routers of different producers, the problem appeared after updating on IOS XR 5.1.3,
everything worked at IOS XR 5.1.0 normally,

now rolled away on 5.1.0 but is visible because of the FPD updating on 5.1.0 too doesn't work

Cisco IOS XR Software, Version 5.1.1[Default].

interface Bundle-Ether100
!
interface Bundle-Ether100.10
 service-policy type control subscriber PPP_PM
 pppoe enable bba-group intersat
 encapsulation ambiguous dot1q any
!
interface TenGigE0/0/2/1
 bundle id 100 mode on
!

===================================== ==========================================
                                      Existing Field Programmable Devices
                                      ==========================================
                                        HW                       Current SW Upg/
Location     Card Type                Version Type Subtype Inst   Version   Dng?
============ ======================== ======= ==== ======= ==== =========== ====
0/RSP0/CPU0  ASR9001-RP                 1.0   lc   fpga2   0       1.15     No 
                                              lc   cbc     0      22.114    No 
                                              lc   rommon  0       2.04     No 
--------------------------------------------------------------------------------
0/FT0/SP     ASR-9001-FAN               1.0   ft   cbc     7      24.115    No 
--------------------------------------------------------------------------------
0/0/CPU0     ASR9001-LC-S               1.0   lc   cbc     0      23.114    No 
                                              lc   fpga2   0       1.18     No 
                                              lc   fpga4   0       2.10     No 
                                              lc   rommon  0       2.03     No 
--------------------------------------------------------------------------------

[xthuijs · Accepted solution]

This probem statement is a bit too vague to give a sound answer or explanation, can you extrapolate a bit more and provide some show commands to us to see where the drops are happening (if there are drops) and in what direction.

Also have you configured for MSS adjust?

fact remains regardless of release, the pppoe only has 1492 by default unless we override it with config.

for sure, to prevent fragmentation, mss adjust is a great help already.

xander

[Vladimir Miropolskyj]

Hi xthuijs,

Yes earned after I added 

subscriber pta tcp mss-adjust 1280

Only I don't understand why before the IOS updating everything worked?

Thanks!

[xthuijs · Accepted solution]

hey vladimir,

I'd like to understand also :), but from the gist of it, it sounds liek you were hitting a frag issue there.

if you like to troubleshoot this a bit more, I am totally game, but if you are cool with this solution I am fine also.

cheers!

xander

[Vladimir Miropolskyj]

Hi xthuijs,

I will describe that was

There was IOS XR 5.1.1 - everything worked
I updated on IOS XR 5.1.3 - ceased to work
I rolled away on IOS XR 5.1.1 - again began to work
I updated on IOS XR 5.2 - ceased to work
I rolled away on IOS XR 5.1.1 - ceased to work I didn't adjust MSS adjust 1280 yet

Here is how that so, according to FPD is updated to the latest version when updated to 5.2

[xthuijs]

That is interesting Vladimir, the FPD's that are updated have little to do, on the linecard that is, with the forwarding.

This is what I am thinking, possibly it worked before because the packets that required fragmentation were punted to the control plane for sw fragmentation. This was working before fortunately, but since we have LC based subscribers in 512 some dynamics have changed in that punt path (handling).

If you have the problem, check the show controller np counters np all loc 0/X/cpu0 | i FRAG and see if that counter goes up, if so, we likely are hitting that issue.

Which merely means that we were in luck in older releases, because the sw frag path is not ideal (/actually not even truly supported for BNG :) I have SPP based frag coming out though as per popular request, but any case it is always better to prevent frag anyways (via mss adjust for instance or a higher nego'd MTU on the subscr interface).

But again, that is assuming that this issue is frag related :)

cheers!

xander

[Vladimir Miropolskyj]

Hi

RP/0/RSP0/CPU0:ASR9K-BNG#show controllers np counters all location 0/0/CPU0 | i FRAG
Tue Oct 28 22:37:20.408 YEKT
 842  IPV4_FRAG_NEEDED_PUNT                              384910158         101
 843  IPV4_FRAG_NEEDED_PUNT_EXCD                           7107087           0
RP/0/RSP0/CPU0:ASR9K-BNG#show controllers np counters all location 0/0/CPU0 | i FRAG
Tue Oct 28 22:37:23.647 YEKT
 842  IPV4_FRAG_NEEDED_PUNT                              384910538         117
 843  IPV4_FRAG_NEEDED_PUNT_EXCD                           7107087           0
RP/0/RSP0/CPU0:ASR9K-BNG#show controllers np counters all location 0/0/CPU0 | i FRAG
Tue Oct 28 22:39:55.508 YEKT
 842  IPV4_FRAG_NEEDED_PUNT                              384925502          99
 843  IPV4_FRAG_NEEDED_PUNT_EXCD                           7107087           0

[xthuijs]

Cool thaks for that Vladimir! that confirms our analysis!

fragmentation was the key indeed. I think we were "lucky" in the earlier release that it may have seemed to work. in fact you have even EXCD counts, which means that lpts policed the punted traffic due to excess rate.

If you really need fragmentation, but my advice is either to use the mssadjust or enlarge the MTU on the subscriber interface and negotiate a larger MRU, as opposed to leveraging CSCup20681 (522) which adds frag support for pppoe subs.

regards

xander