[c-nsp] 7206 L2TP and Gigawords
Gerald Krause
gk at ax.tc
Wed Jan 19 22:35:15 EST 2011
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: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Gerald Krause
> Sent: January-19-11 9:51 PM
> To: cisco-nsp at puck.nether.net
> 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
> <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/
>>
>
> _______________________________________________
> 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/
>
>
More information about the cisco-nsp
mailing list