[c-nsp] 7206 L2TP and Gigawords

Wed Jan 19 21:50:58 EST 2011

I stumbled upon this bug in SRD3 too an tried SRE2 but without success.
Does anyone get the Gigawords working with an NPE-G2 acting as LNS?

--
Gerald

Am 06.06.2010 11:14, schrieb Phil Pierotti:
> Hi Arie,
> 
> Also:
> 
> Checking the Bug Toolkit for that number you mentioned, it says that both
> SRD3 and SRD4 are impacted by this bug. But nothing in SR train is listed in
> the 'fixed-in' for this bug.
> 
> So the obvious question is, given that I need to upgrade - what's the
> recommended IOS for a 7206VXR with NPE-G1 acting as LAC/LNS, some MPLS and
> BGP, a little NAT and some IPSEC.
> 
> Thanks,
> PhiL P
> 
> 
> On Sun, Jun 6, 2010 at 6:54 PM, Phil Pierotti <phil.pierotti at gmail.com>wrote:
> 
>> HI Arie,
>>
>> Thanks for your help - details inline.
>>
>> Since I brought this session up this morning, I have downloaded 6.18GB of
>> LINUX ISOs for testing purposes, and then 'normal internet' use since then
>> as well, all in this same session.
>>
>> On Sun, Jun 6, 2010 at 4:52 PM, Arie Vayner (avayner) <avayner at cisco.com>wrote:
>>
>>> Phil,
>>>
>>> I have worked on this kind of an issue and we have CSCsw74470 for this
>>> one, which is integrated in SRD3 (I made sure, and it is there).
>>> The code to generate RADIUS gigawords is there, so this has to be
>>> something else...
>>>
>>> We need to identify if the problem is due to the info not being
>>> collected (i.e. the counters for the interface are 32-bit) or we just do
>>> not report it in RADIUS (so the info is there, and it's "just" not
>>> reported).
>>>
>>> Use these commands:
>>> sh int virtual-access #
>>>
>>>
>> Virtual-Access2.135 is up, line protocol is up
>>   Hardware is Virtual Access interface
>>   Interface is unnumbered. Using address of Loopback10 (??.??.??.??)
>>   MTU 1500 bytes, BW 149760 Kbit, DLY 100000 usec,
>>      reliability 255/255, txload 45/255, rxload 7/255
>>   Encapsulation PPP, LCP Open
>>   Open: IPCP
>>   PPPoVPDN vaccess, cloned from Virtual-Template6
>>   Vaccess status 0x0
>>   Protocol l2tp, tunnel id 55022, session id 6814
>>   Keepalive set (10 sec)
>>      2889718 packets input, 341932313 bytes
>>      4778457 packets output, 2503224921 bytes
>>   Last clearing of "show interface" counters never
>>
>>
>> Bytes Output reported is 2,503,224,921 or 2.5GB
>>
>> Clearly the problem is a counter wrap/not-being-collected problem.
>>
>>
>>> Look at the counter for a session that should be >4294967296 bytes
>>> in/out (2^32) - Does it overlap to 0, or keep counting beyond 2^32?
>>>
>>> Then, if the counters are >2^32 (which means we count fine, and just
>>> have a reporting issue), use:
>>>
>>> sh subscriber session username <username> detailed
>>>
>>> Look for the "AAA_id", which is a HEX number, and then use it with:
>>> sh aaa user <AAA_id> (in a 0xNNNN format).
>>>
>>> The pre-bytes-in/out field are used by Gigawords. If the counter should
>>> be more than 2^32, then pre-bytes-in/out should be >0.
>>>
>>
>> Interface:
>>   TTY Num = -1
>>   Stop Received = 0
>>   Byte/Packet Counts till Call Start:
>>     Start Bytes In = 0             Start Bytes Out = 0
>>     Start Paks  In = 0             Start Paks  Out = 0
>>   Byte/Packet Counts till Service Up:
>>     Pre Bytes In = 0             Pre Bytes Out = 0
>>     Pre Paks  In = 0             Pre Paks  Out = 0
>>   Cumulative Byte/Packet Counts :
>>     Bytes In = 342239526     Bytes Out = 2503793377
>>     Paks  In = 2891654       Paks  Out = 4780378
>>   StartTime = 09:59:17 AEST Jun 6 2010
>>   AuthenTime = 09:59:17 AEST Jun 6 2010
>>   Component = VPDN
>>
>> Pre-Bytes are zeros, but they should not be, so this confirms a
>> failure-to-collect problem.
>>
>>
>>>
>>> If all is still fine, look at debug radius...
>>>
>>>
>>> I would suggest to file a TAC case with the following findings, and
>>> maybe reference the above DDTS.... It could be something new...
>>>
>>> Arie
>>>
>>> -----Original Message-----
>>> From: cisco-nsp-bounces at puck.nether.net
>>> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Phil Pierotti
>>> Sent: Sunday, June 06, 2010 05:56
>>> To: cisco-nsp at puck.nether.net
>>> Subject: [c-nsp] 7206 L2TP and Gigawords
>>>
>>> Hi All,
>>>
>>> I'm running a 7206/G1 with AdvIP Services 12.2(33)SRD3 as an LNS.
>>>
>>> Sending periodic accounting updates every ten minutes.
>>>
>>> Running a download test to verify the LNS is sending RADIUS Gigawords
>>> attributes (52 and 53), backending against Freeradius.
>>>
>>> Looking at the freeradius detail log, it's obvious that my LNS is *not*
>>> generating Gigawords attributes.
>>>
>>> >From two successive interim updates, I clearly see byte-counter
>>> rollover and
>>> no packet-counter rollover (same user, same session):
>>>
>>>        Acct-Output-Octets = 3883719317
>>>        Acct-Output-Packets = 2592080
>>>
>>>        Acct-Output-Octets = 257083854
>>>        Acct-Output-Packets = 3036810
>>>
>>> And there's no gigawords attribute (Acct-Output-Gigawords, etc) being
>>> generated.
>>>
>>> According to Cisco: gigawords attributes are enabled by default (ie only
>>> the
>>> NO form of the command will show in the config).
>>> I've checked my config, I'm not NO'ing that (why would you?)
>>>
>>> So can anyone suggest why my LNS is not generating these attributes when
>>> they're needed?
>>>
>>> Thanks,
>>> Phil P
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>
>>
>>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 