10-23-2014 09:10 PM
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
--------------------------------------------------------------------------------
Solved! Go to Solution.
10-27-2014 05:46 AM
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
10-27-2014 08:51 PM
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
10-27-2014 05:46 AM
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
10-27-2014 08:30 PM
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!
10-27-2014 08:51 PM
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
10-27-2014 09:24 PM
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
10-28-2014 06:00 AM
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
10-28-2014 10:40 AM
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
10-28-2014 11:30 AM
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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: