Concentrator Session Specific Stats
Moderators: Developers, Moderators
-
- Posts: 14
- Joined: Sat Aug 14, 2004 10:30 am
Concentrator Session Specific Stats
This post (listed below) hit very close to what I am looking for. But not quite.
I haven't seen anyone mention or post about detailed session stats. That or I am blind. Has this been done before?
The scenario is that management would like to see Lan-to-Lan details (not worried about client sessions so much). Trying to identify which agencies are pulling the most bandwidth.
The platform is a Cisco VPN Concentrator 3030.
http://www.raxnet.net/board/viewtopic.p ... ncentrator
I haven't seen anyone mention or post about detailed session stats. That or I am blind. Has this been done before?
The scenario is that management would like to see Lan-to-Lan details (not worried about client sessions so much). Trying to identify which agencies are pulling the most bandwidth.
The platform is a Cisco VPN Concentrator 3030.
http://www.raxnet.net/board/viewtopic.p ... ncentrator
-
- Posts: 14
- Joined: Sat Aug 14, 2004 10:30 am
Moving forward with my quest to have this ported into Cacti . . . I've successfully pulled the following from our Cisco VPN Concentrator running OS v4.0.1
.1.3.6.1.4.1.3076.2.1.2.17.2.1.3 - session username
.1.3.6.1.4.1.3076.2.1.2.17.2.1.5 - session type
.1.3.6.1.4.1.3076.2.1.2.17.2.1.6 - session protocol
.1.3.6.1.4.1.3076.2.1.2.17.2.1.9 - bytes tx
.1.3.6.1.4.1.3076.2.1.2.17.2.1.10 - bytes rx
.1.3.6.1.4.1.3076.2.1.2.17.2.1.12 - session group name
I am speculating .1.5 to be session type (lan-to-lan, client access, management) and really guessing at session protocol (.1.6) (l2tp, ipsec, ssl etc). The pattern is consistant enough to lead me to believe as much. Also, I am not concerned with session protocol at this point.
Under the OID I believe to be session type (.1.5) the values of importances are 16 for remote access (client access) and 15 for site-to-site (Lan-to-Lan).
For each index, session username (.1.3) Lan-to-Lan sessions only discloses the IP address of the remote peer. Same goes for session group name where it only shows the IP address of the remote peer.
For each index, session username (.1.3) client access, username shows the username (how bout that!) and group name shows the logged in group name (neat huh!).
Additional information learned through pawing through the message board lead me to a posting from jeanvav that lists session totals (thanks jeanvav). I've broken then down here:
.1.3.6.1.4.1.3076.2.1.2.17.1.7.0 (Lan-to-Lan session total)
.1.3.6.1.4.1.3076.2.1.2.17.1.8.0 (Management session total)
.1.3.6.1.4.1.3076.2.1.2.17.1.9.0 (Remote Access total)
.1.3.6.1.4.1.3076.2.1.2.17.1.1.0 (Total Sessions)
Here's the question(s):
1) Am I looking at a custom script that can distinguish between a Lan-to-Lan session and a Client Access session? Graphing of Lan-to-Lan sessions (I think) will be straight forward in that I can index my graphs based on the IP address. I'd have to because if the Concentrator was rebooted, it would reset the indexing completely. That is session indexes are not static. They change as sessions come and go.
2) How would I handle client sessions? Especially multiple logins for a single user? Because of that situation alone, I could not use the login name as a graph index.
Think i'll stop there.
Your comments, suggestions and opinions on this matter are greatly appreciated. Any insights as to what the best approach should be would hbe also appreciated.
Thanks in advance.
.1.3.6.1.4.1.3076.2.1.2.17.2.1.3 - session username
.1.3.6.1.4.1.3076.2.1.2.17.2.1.5 - session type
.1.3.6.1.4.1.3076.2.1.2.17.2.1.6 - session protocol
.1.3.6.1.4.1.3076.2.1.2.17.2.1.9 - bytes tx
.1.3.6.1.4.1.3076.2.1.2.17.2.1.10 - bytes rx
.1.3.6.1.4.1.3076.2.1.2.17.2.1.12 - session group name
I am speculating .1.5 to be session type (lan-to-lan, client access, management) and really guessing at session protocol (.1.6) (l2tp, ipsec, ssl etc). The pattern is consistant enough to lead me to believe as much. Also, I am not concerned with session protocol at this point.
Under the OID I believe to be session type (.1.5) the values of importances are 16 for remote access (client access) and 15 for site-to-site (Lan-to-Lan).
For each index, session username (.1.3) Lan-to-Lan sessions only discloses the IP address of the remote peer. Same goes for session group name where it only shows the IP address of the remote peer.
For each index, session username (.1.3) client access, username shows the username (how bout that!) and group name shows the logged in group name (neat huh!).
Additional information learned through pawing through the message board lead me to a posting from jeanvav that lists session totals (thanks jeanvav). I've broken then down here:
.1.3.6.1.4.1.3076.2.1.2.17.1.7.0 (Lan-to-Lan session total)
.1.3.6.1.4.1.3076.2.1.2.17.1.8.0 (Management session total)
.1.3.6.1.4.1.3076.2.1.2.17.1.9.0 (Remote Access total)
.1.3.6.1.4.1.3076.2.1.2.17.1.1.0 (Total Sessions)
Here's the question(s):
1) Am I looking at a custom script that can distinguish between a Lan-to-Lan session and a Client Access session? Graphing of Lan-to-Lan sessions (I think) will be straight forward in that I can index my graphs based on the IP address. I'd have to because if the Concentrator was rebooted, it would reset the indexing completely. That is session indexes are not static. They change as sessions come and go.
2) How would I handle client sessions? Especially multiple logins for a single user? Because of that situation alone, I could not use the login name as a graph index.
Think i'll stop there.
Your comments, suggestions and opinions on this matter are greatly appreciated. Any insights as to what the best approach should be would hbe also appreciated.
Thanks in advance.
-
- Posts: 14
- Joined: Sat Aug 14, 2004 10:30 am
Okay . . . think I successfully figured out the snmp_query via xml and can view the debug information for the device. However, when it comes to creating the graph under 'new graph', i select my entry and click 'save'. I choose my index key and save again and i am kicked back out to my previous screen. All nodes appear as though i've never attempted to create a graph. That is, the node I attempted to create is not 'greyed out' like all the other 20 or so hosts i've configured successfully.
When going into manage graphs I see the attempted data source. However, when i enter the graph settings it comes up with an error (after turning on graph debugging) that it can not find the .rrd file. Not sure what I am missing.
I've created a new query and have tried recycling the canned Data and Graph templates for Interface Traffic. Think I am missing something.
One thought occured to me is "what data-type does the snmp value get translated into?". That is I pull a value from the Concentrator but is it a string? an Int? an Unsigned Int? Does it matter? or is the data type defined by which template is used and what fields are assocated with the respective templates?
<yawn> night.
When going into manage graphs I see the attempted data source. However, when i enter the graph settings it comes up with an error (after turning on graph debugging) that it can not find the .rrd file. Not sure what I am missing.
I've created a new query and have tried recycling the canned Data and Graph templates for Interface Traffic. Think I am missing something.
One thought occured to me is "what data-type does the snmp value get translated into?". That is I pull a value from the Concentrator but is it a string? an Int? an Unsigned Int? Does it matter? or is the data type defined by which template is used and what fields are assocated with the respective templates?
<yawn> night.
-
- Posts: 14
- Joined: Sat Aug 14, 2004 10:30 am
In breif, I've found the error of my ways. Part of it was my newness to Cacti. After mapping out the packaged SNMP Interface - Traffic and referencing the manual, it became pretty clear what was required. (sigh)
The result? I believe we are successfully tracking Lan-to-Lan traffic. Need to watch it and make sure I am tracking things correctly. A post Ian replied to may have provided the solution for my question earlier with ever changing index values.
Once I am sure of my work, I will then investigate packaging and documenting things accordingly. Once that is done, I will post it for your drooling pleasure : )
The result? I believe we are successfully tracking Lan-to-Lan traffic. Need to watch it and make sure I am tracking things correctly. A post Ian replied to may have provided the solution for my question earlier with ever changing index values.
Once I am sure of my work, I will then investigate packaging and documenting things accordingly. Once that is done, I will post it for your drooling pleasure : )
-
- Posts: 14
- Joined: Sat Aug 14, 2004 10:30 am
Cacti is not following VPN sessions as they come and go over time and indexes change. I have implimented the suggestions on a post that resembles my situation but it requires a manual 'refresh' which isn't a realistic option for this scenario.
Will keep digging.
Will keep digging.
I think your on the right track.
Here's what I was able to determine doing some digging on my own:
These are actually being pulled from the ALTIGA-SESSION-STATS.MIB file. You can download it from Cisco and load it into your snmp mib table. Or snag it from mibDepot (http://www.mibdepot.com)
For User name, on Lan-2-Lan connections it'll be the remote IP address. Client connections would be the login ID.
For Protocol, acording to the MIB:
For Encryption type:
The problem, as you've already alluded to, is going to be figuring out which is which every time a VPN drops due to inactivity or far-side issues. For example, There's no gaurentee that index #4 is going to be the L2L session with Microsoft every time. This would be even more difficult if your allowing client systems to bring up user-VPNs via the Cisco client since these would make the indexes change even more frequently.
So you'd have to have Cacti index on something that doesn't change. User name might be a good place to start, so you can track by IP if it's a Lan2Lan session.
I know, I know you've already pointed a bunch of this out... I'm working through it is all.
... so for your two questions above;
.1.3.6.1.4.1.3076.2.1.2.17.4.1.14 (alActiveSessionDataPublicIpAddress)
and only graph my Lan 2 Lan sessions with that.
As for question #2. Multiple user logins... that'll be tricky. Perhaps the best way to do that would be either:
If you do what we do here, where there may be users with the same login information, but in different "user groups" for different departments, you could toss that into the mix:
1.3.6.1.4.1.3076.2.1.2.17.4.1.12
(alActiveSessionGroupName)
This would be another alternative way to snag Lan-2-Lan sessions as well.
hmm.
Here's what I was able to determine doing some digging on my own:
These are actually being pulled from the ALTIGA-SESSION-STATS.MIB file. You can download it from Cisco and load it into your snmp mib table. Or snag it from mibDepot (http://www.mibdepot.com)
Code: Select all
.1.3.6.1.4.1.3076.2.1.2.17.2.1.3 = Active Session UserName
.1.3.6.1.4.1.3076.2.1.2.17.2.1.4 = Active Session IP Address
.1.3.6.1.4.1.3076.2.1.2.17.2.1.5 = Active Session Protocol
.1.3.6.1.4.1.3076.2.1.2.17.2.1.6 = Active Session Encryption Type
.1.3.6.1.4.1.3076.2.1.2.17.2.1.9 = Active Session Octets Sent
.1.3.6.1.4.1.3076.2.1.2.17.2.1.10 = Active Session Octets Recieved
For Protocol, acording to the MIB:
Code: Select all
pptp (1)
l2tp (2)
ipsec (3)
http (4)
ftp (5)
telnet (6)
snmp (7)
tftp (8)
console (9)
debugTelnet (10)
debugConsole (11)
other (12)
ike (13)
l2tpOverIpSec (14)
ipsecLanToLan (15)
ipsecOverUdp (16)
ssh (17)
vcaLanToLan (18)
ipsecOverTcp (19)
pppoe (20)
ipsecOverNatT (21)
ipsecLan2LanOverNatT (22),
l2tpOverIpsecOverNatT (23)
Code: Select all
none (1)
des56 (2)
des40 (3)
des168 (4)
rc4Stateless40 (5)
rc4Statefull40 (6)
rc4Stateless128 (7)
rc4Statefull128 (8)
aes128 (9)
aes192 (10)
aes256 (11)
So you'd have to have Cacti index on something that doesn't change. User name might be a good place to start, so you can track by IP if it's a Lan2Lan session.
I know, I know you've already pointed a bunch of this out... I'm working through it is all.
... so for your two questions above;
for #1, I'd say that this would be easier than trying to figure it out in Cacti. Query a host using a snmp Agent that will proxy the read requests and massage the data to get what you want back out. But it's an inelegant solution. I would probably use:BitFlipper
1) Am I looking at a custom script that can distinguish between a Lan-to-Lan session and a Client Access session? Graphing of Lan-to-Lan sessions (I think) will be straight forward in that I can index my graphs based on the IP address. I'd have to because if the Concentrator was rebooted, it would reset the indexing completely. That is session indexes are not static. They change as sessions come and go.
2) How would I handle client sessions? Especially multiple logins for a single user? Because of that situation alone, I could not use the login name as a graph index.
.1.3.6.1.4.1.3076.2.1.2.17.4.1.14 (alActiveSessionDataPublicIpAddress)
and only graph my Lan 2 Lan sessions with that.
As for question #2. Multiple user logins... that'll be tricky. Perhaps the best way to do that would be either:
- A - multiple data source graphs, ala system load stats.
B - graph combined in/out stats per user (user.login1 + user.login2)
C - graph soley on remote IP address
If you do what we do here, where there may be users with the same login information, but in different "user groups" for different departments, you could toss that into the mix:
1.3.6.1.4.1.3076.2.1.2.17.4.1.12
(alActiveSessionGroupName)
This would be another alternative way to snag Lan-2-Lan sessions as well.
hmm.
Who is online
Users browsing this forum: No registered users and 1 guest