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 <[email protected]>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) >> <[email protected]>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: [email protected] >>> [mailto:[email protected]] On Behalf Of Phil Pierotti >>> Sent: Sunday, June 06, 2010 05:56 >>> To: [email protected] >>> 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 [email protected] >>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >>> >> >> > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
