Indeed the story about Gigawords seems to be full of mysticism ;-). I've collected the following information so far, but I have still no clue how to get it working in any SRD or SRE release:
- it's "on" by default, and therefore you don't see it in the config, but... - ...if you disable this feature you'll see "no aaa accounting gigawords" in the config - regardless if it's currently enabled or disabled, when you enter the "(no)aaa accounting gigawords" command the router tells you it will take effect after the next reboot - some doc's state that this feature isn't supported in 12.2 - in a post from Oli some years ago, he mentioned that the Gigawords where send only when the counter really wraps and not before But I'll continue trying to get it working. -- Gerald Am 20.01.2011 11:52, schrieb Paul Stewart: > Well, we just turned it on around beginning of December... I'm told by our > folks that handle Radius internally that they are not getting negative > counters anymore (from counter wrap) and are seeing accounting updates every > hour. > > The weird thing that I do recall was that Gigawords was supposed to be on by > default according to some docs - but didn't see it in the configuration and > wanted to verify. When we added the command for gigawords into our > configuration, we got output back that said it would take effect upon reboot. > I do recall that up to that point we were *not* seeing 32 bit information in > Radius at all making me wonder how it is supposed to be working by default - > so in the next maint window we kicked the 7206VXR and now it's working. > > Honestly, haven't spent a lot of time on it.. we're migrating off the 7206VXR > into Juniper E series currently.... > > Let me know if I can be of any other assistance ;) > > Paul > > > -----Original Message----- > From: Gerald Krause [mailto:[email protected]] > Sent: January-19-11 10:35 PM > To: Paul Stewart > Cc: [email protected] > Subject: Re: [c-nsp] 7206 L2TP and Gigawords > > Hi Paul, > > that's interesting! :) > > I'am a little bit confused if any 12.2 version will support this feature > at all, because I just found this: > > http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfradat.html#wp1016587 > > Does your LNS sending these attributes by default in every STOP or > INTERIM Acct packet? Have you done any special configuration? > > -- > Gerald > > Am 20.01.2011 04:12, schrieb Paul Stewart: >> Yes, we're running it without any "known issues" on 12.2(33)SRD1 if that >> helps...;) >> >> Paul >> >> >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Gerald Krause >> Sent: January-19-11 9:51 PM >> To: [email protected] >> Subject: Re: [c-nsp] 7206 L2TP and Gigawords >> >> 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/ >> >> > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
