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/
