Hello All,
We have been using our netapp primarily for NAS storage, but I am experimenting with iSCSI now for some specific applications. I managed to create a bit of a network issue recently when I tried enabling jumbo packets on my netapp and my test server. The iSCSI connection kept resyncing and was not stable. I think this was because I didn't create a separate vlan for the devices using jumbo packets. Upon further research, I found mention that some devices/ oses calculate the checksums differently and that can affect the max packet size. Does anyone have any recommendations for a packet size for both the netapp and for my linux servers? is 10240 a safe bet(max size supported by my switch) or should I use something like 9000 or 8192? Should I use a different packet size if I am connecting a target to a windows box? I would ideally like to make a jumbo packets vlan and just set all the devices on that vlan to a larger MTU, but I don't want to create a network traffic problem in the process.
Brent Ellis Systems Analyst/Consultant CAS Computing Services Group Boston University interi@bu.edu
We've always put our MTU size at 9000, because we're primarily database-oriented. However, I have no idea if Linux can support the larger jumbo frames. 9000 definitely works though, and lets 8k database or filesystem blocks fit within one frame, so there's no fragmentation.
Thanks, Matt
-- Matthew Zito Chief Scientist GridApp Systems P: 646-452-4090 mzito@gridapp.com http://www.gridapp.com
-----Original Message----- From: owner-toasters@mathworks.com on behalf of Brent Ellis Sent: Tue 2/26/2008 9:28 AM To: toasters@mathworks.com Subject: Jumbo Packets with netapp FAS3050
Hello All,
We have been using our netapp primarily for NAS storage, but I am experimenting with iSCSI now for some specific applications. I managed to create a bit of a network issue recently when I tried enabling jumbo packets on my netapp and my test server. The iSCSI connection kept resyncing and was not stable. I think this was because I didn't create a separate vlan for the devices using jumbo packets. Upon further research, I found mention that some devices/ oses calculate the checksums differently and that can affect the max packet size. Does anyone have any recommendations for a packet size for both the netapp and for my linux servers? is 10240 a safe bet(max size supported by my switch) or should I use something like 9000 or 8192? Should I use a different packet size if I am connecting a target to a windows box? I would ideally like to make a jumbo packets vlan and just set all the devices on that vlan to a larger MTU, but I don't want to create a network traffic problem in the process.
Brent Ellis Systems Analyst/Consultant CAS Computing Services Group Boston University interi@bu.edu
Even though the switch may support it, some switches still have problems with Jumbo Packets and can choke on the heavy traffic. I don't believe that the filer has an issue with MTU of 9000, but as Matt pointed out, I'd check the info on your linux distro as well.
________________________________
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Matthew Zito Sent: Tuesday, February 26, 2008 11:32 AM To: Brent Ellis; toasters@mathworks.com Subject: RE: Jumbo Packets with netapp FAS3050
We've always put our MTU size at 9000, because we're primarily database-oriented. However, I have no idea if Linux can support the larger jumbo frames. 9000 definitely works though, and lets 8k database or filesystem blocks fit within one frame, so there's no fragmentation.
Thanks, Matt
-- Matthew Zito Chief Scientist GridApp Systems P: 646-452-4090 mzito@gridapp.com http://www.gridapp.com
-----Original Message----- From: owner-toasters@mathworks.com on behalf of Brent Ellis Sent: Tue 2/26/2008 9:28 AM To: toasters@mathworks.com Subject: Jumbo Packets with netapp FAS3050
Hello All,
We have been using our netapp primarily for NAS storage, but I am experimenting with iSCSI now for some specific applications. I managed to create a bit of a network issue recently when I tried enabling jumbo packets on my netapp and my test server. The iSCSI connection kept resyncing and was not stable. I think this was because I didn't create a separate vlan for the devices using jumbo packets. Upon further research, I found mention that some devices/ oses calculate the checksums differently and that can affect the max packet size. Does anyone have any recommendations for a packet size for both the netapp and for my linux servers? is 10240 a safe bet(max size supported by my switch) or should I use something like 9000 or 8192? Should I use a different packet size if I am connecting a target to a windows box? I would ideally like to make a jumbo packets vlan and just set all the devices on that vlan to a larger MTU, but I don't want to create a network traffic problem in the process.
Brent Ellis Systems Analyst/Consultant CAS Computing Services Group Boston University interi@bu.edu
We have MTU set at 9000, and linux will definately support it if the NIC drivers are decent. We use MTU=9000 for our dedicated backup network to backup linux boxes. You should stop everything until you have a dedicated VLAN for iSCSI, as performance testing will hurt whatever public network you are on :)
I wouldn't use the 10xxx byte value, since most clients won't support that.. You should attempt to keep all MTU settings the same - ie keep the filer at 9000, and all iSCSI attached clients at 9000. It optimizes the network traffic.
HTH,
- Hadrian ________________________________________ From: owner-toasters@mathworks.com [owner-toasters@mathworks.com] On Behalf Of Glenn Walker [ggwalker@mindspring.com] Sent: Tuesday, February 26, 2008 6:24 PM To: Matthew Zito; Brent Ellis; toasters@mathworks.com Subject: RE: Jumbo Packets with netapp FAS3050
Even though the switch may support it, some switches still have problems with Jumbo Packets and can choke on the heavy traffic. I don't believe that the filer has an issue with MTU of 9000, but as Matt pointed out, I'd check the info on your linux distro as well.
________________________________ From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Matthew Zito Sent: Tuesday, February 26, 2008 11:32 AM To: Brent Ellis; toasters@mathworks.com Subject: RE: Jumbo Packets with netapp FAS3050
We've always put our MTU size at 9000, because we're primarily database-oriented. However, I have no idea if Linux can support the larger jumbo frames. 9000 definitely works though, and lets 8k database or filesystem blocks fit within one frame, so there's no fragmentation.
Thanks, Matt
-- Matthew Zito Chief Scientist GridApp Systems P: 646-452-4090 mzito@gridapp.com http://www.gridapp.com
-----Original Message----- From: owner-toasters@mathworks.com on behalf of Brent Ellis Sent: Tue 2/26/2008 9:28 AM To: toasters@mathworks.com Subject: Jumbo Packets with netapp FAS3050
Hello All,
We have been using our netapp primarily for NAS storage, but I am experimenting with iSCSI now for some specific applications. I managed to create a bit of a network issue recently when I tried enabling jumbo packets on my netapp and my test server. The iSCSI connection kept resyncing and was not stable. I think this was because I didn't create a separate vlan for the devices using jumbo packets. Upon further research, I found mention that some devices/ oses calculate the checksums differently and that can affect the max packet size. Does anyone have any recommendations for a packet size for both the netapp and for my linux servers? is 10240 a safe bet(max size supported by my switch) or should I use something like 9000 or 8192? Should I use a different packet size if I am connecting a target to a windows box? I would ideally like to make a jumbo packets vlan and just set all the devices on that vlan to a larger MTU, but I don't want to create a network traffic problem in the process.
Brent Ellis Systems Analyst/Consultant CAS Computing Services Group Boston University interi@bu.edu
On Wed, Feb 27, 2008 at 8:40 AM, Hadrian Baron Hadrian.Baron@vegas.com wrote:
I wouldn't use the 10xxx byte value, since most clients won't support that.. You should attempt to keep all MTU settings the same - ie keep the filer at 9000, and all iSCSI attached clients at 9000. It optimizes the network traffic.
HTH,
- Hadrian
Quick question to all the networking gurus on this list. Is there a performance impact if the filer and the clients have different MTU sizes defined. Also is there a way to check this. Our filers all have jumbo frame MTU set to 9000, but for some reason our solaris admin chose to set them on his side to 9194. ifstat on the filer interfaces don't show any errors/discards or retransmits. Example:
-- interface e4c (72 days, 8 hours, 38 minutes, 9 seconds) --
RECEIVE Frames/second: 2285 | Bytes/second: 2805k | Errors/minute: 0 Discards/minute: 0 | Total frames: 2946m | Total bytes: 5787g Total errors: 0 | Total discards: 31 | Multi/broadcast: 0 No buffers: 14 | Non-primary u/c: 0 | Tag drop: 0 Vlan tag drop: 0 | Vlan untag drop: 0 | CRC errors: 0 Runt frames: 0 | Fragment: 0 | Long frames: 0 Jabber: 0 | Alignment errors: 0 | Bus overruns: 17 Queue overflows: 0 | Xon: 0 | Xoff: 0 Jumbo: 734m | Reset: 0 | Reset1: 0 Reset2: 0 TRANSMIT Frames/second: 936 | Bytes/second: 5467k | Errors/minute: 0 Discards/minute: 0 | Total frames: 1187m | Total bytes: 7680g Total errors: 0 | Total discards: 0 | Multi/broadcast: 228k Queue overflows: 0 | No buffers: 0 | Max collisions: 0 Single collision: 0 | Multi collisions: 0 | Late collisions: 0 Timeout: 0 | Xon: 0 | Xoff: 0 Jumbo: 919m LINK_INFO Current state: up | Up to downs: 9 | Auto: on Speed: 1000m | Duplex: full | Flowcontrol: none
TIA -G
On 3/5/08 9:05 PM, "Sto Rage©" netbacker@gmail.com wrote:
Quick question to all the networking gurus on this list. Is there a performance impact if the filer and the clients have different MTU sizes defined. Also is there a way to check this. Our filers all have jumbo frame MTU set to 9000, but for some reason our solaris admin chose to set them on his side to 9194. ifstat on the filer interfaces don't show any errors/discards or retransmits. Example:
Yes, there's definitely a performance impact. Essentially, if one packet's 9100 and one's 9000, you've got 100 that's going to have to be split back into another packet. Your filer will give a response saying "MTU size is too big", please break it into chunks. I'm not sure if this only happens once / session, or per-packet, but if it happens per-packet it's a lot of extra overhead. Even if it's not, that extra 100 needs to go into a new packet, so you're getting overhead of splitting it into chunks and then overhead of re-assembling it on the destination.
Essentially... Yes. :) you want them all to match.
Thanks for the reply. Now my next question is does NetApp support a MTU size of 9194? It looks easier for me to change the NetApp end (just 1 cluser) instead of asking the Solaris admin to change on 18+ hosts. All the documents I have seen from NetApp seems to only suggest using 9000 as the default, where as all the SUN documents suggest 9194 as their default. Thanks once again -G
On Thu, Mar 6, 2008 at 11:26 PM, Nicholas Bernstein nick@nicholasbernstein.com wrote:
On 3/5/08 9:05 PM, "Sto Rage(c)" netbacker@gmail.com wrote:
Quick question to all the networking gurus on this list. Is there a performance impact if the filer and the clients have different MTU sizes defined. Also is there a way to check this. Our filers all have jumbo frame MTU set to 9000, but for some reason our solaris admin chose to set them on his side to 9194. ifstat on the filer interfaces don't show any errors/discards or retransmits. Example:
Yes, there's definitely a performance impact. Essentially, if one packet's 9100 and one's 9000, you've got 100 that's going to have to be split back into another packet. Your filer will give a response saying "MTU size is too big", please break it into chunks. I'm not sure if this only happens once / session, or per-packet, but if it happens per-packet it's a lot of extra overhead. Even if it's not, that extra 100 needs to go into a new packet, so you're getting overhead of splitting it into chunks and then overhead of re-assembling it on the destination.
Essentially... Yes. :) you want them all to match.
-- Nicholas Bernstein http://nicholasbernstein.com
I'm not sure, but if you run tcpdump* on the solaris box and connect to the netapp with both set to 9194, and you don't see any ICMP type 3 code 4 traffic, you're probably OK. You should also be able to see the actual packet lengths in ethereal, iirc.
-Nick
* output it to a file and open it in ethereal/wireshark.
On Fri, 2008-03-07 at 14:04 -0800, Sto Rage© wrote:
Thanks for the reply. Now my next question is does NetApp support a MTU size of 9194? It looks easier for me to change the NetApp end (just 1 cluser) instead of asking the Solaris admin to change on 18+ hosts. All the documents I have seen from NetApp seems to only suggest using 9000 as the default, where as all the SUN documents suggest 9194 as their default. Thanks once again -G
On Thu, Mar 6, 2008 at 11:26 PM, Nicholas Bernstein nick@nicholasbernstein.com wrote:
On 3/5/08 9:05 PM, "Sto Rage(c)" netbacker@gmail.com wrote:
Quick question to all the networking gurus on this list. Is there a performance impact if the filer and the clients have different MTU sizes defined. Also is there a way to check this. Our filers all have jumbo frame MTU set to 9000, but for some reason our solaris admin chose to set them on his side to 9194. ifstat on the filer interfaces don't show any errors/discards or retransmits. Example:
Yes, there's definitely a performance impact. Essentially, if one packet's 9100 and one's 9000, you've got 100 that's going to have to be split back into another packet. Your filer will give a response saying "MTU size is too big", please break it into chunks. I'm not sure if this only happens once / session, or per-packet, but if it happens per-packet it's a lot of extra overhead. Even if it's not, that extra 100 needs to go into a new packet, so you're getting overhead of splitting it into chunks and then overhead of re-assembling it on the destination.
Essentially... Yes. :) you want them all to match.
-- Nicholas Bernstein http://nicholasbernstein.com
Hi,
We're in progress to configure vol autoresizing on some of our systems. One central aspect of this configuration should be to get an information about the processed autoresizing action, to track what's going on on the affected volume. At the moment I see the only possibilty to get the threshold information of neary full and full volumes (by default 95% & 98%). By default, I just see the log on the console and so in /etc/messages, but non is send via snmp etc.
Is it possible to monitor the autoresizing action or is there a way to implement a notfication for autoresizing?
I'm thinking of user defined traps or something like that. Has anyone experiences with implementing vol autoresize?
Cheers Andreas
I have the same problem because I have many thin-provisioned LUNs. You are correct in that there is no SNMP notification for autosize. I opened a ticket with NetApp and the reply was:
"First, if you have DFM, you can create a custom alert for notification. Second, you can create a custom trap using SNMP, and that would alert you as well.
There is some information on creating custom SNMP traps in the Network Management Guide, Chapter 5: http://now.netapp.com/NOW/knowledge/docs/ontap/rel723/html/ontap/nag/5sn mp7.htm
Unfortunately, I cannot assist you in actually creating a new trap, as that is something very much out of the scope of TSE's."
I have yet to create a custom trap, but please share if you get one working. I am currently monitoring my volumes by receiving SNMP alerts when the volume reaches 98%, letting me know the volume will autosize very soon.
Daniel
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Buerger, Andreas Sent: Tuesday, February 26, 2008 11:10 AM To: toasters@mathworks.com Subject: vol autoresize notification
Hi,
We're in progress to configure vol autoresizing on some of our systems. One central aspect of this configuration should be to get an information about the processed autoresizing action, to track what's going on on the affected volume. At the moment I see the only possibilty to get the threshold information of neary full and full volumes (by default 95% & 98%). By default, I just see the log on the console and so in /etc/messages, but non is send via snmp etc.
Is it possible to monitor the autoresizing action or is there a way to implement a notfication for autoresizing?
I'm thinking of user defined traps or something like that. Has anyone experiences with implementing vol autoresize?
Cheers Andreas
I could be mistaken, but I know that ONTAP 7.2.4 adds logging for volume auto-resize events. I believe that it adds SNMP events as well, but I don't know that for certain.
-- Scott Lowe ePlus Technology, Inc.
________________________________________ From: owner-toasters@mathworks.com [owner-toasters@mathworks.com] On Behalf Of Daniel Keisling [daniel.keisling@austin.ppdi.com] Sent: Tuesday, February 26, 2008 1:50 PM To: Buerger, Andreas; toasters@mathworks.com Subject: RE: vol autoresize notification
I have the same problem because I have many thin-provisioned LUNs. You are correct in that there is no SNMP notification for autosize. I opened a ticket with NetApp and the reply was:
"First, if you have DFM, you can create a custom alert for notification. Second, you can create a custom trap using SNMP, and that would alert you as well.
There is some information on creating custom SNMP traps in the Network Management Guide, Chapter 5: http://now.netapp.com/NOW/knowledge/docs/ontap/rel723/html/ontap/nag/5sn mp7.htm
Unfortunately, I cannot assist you in actually creating a new trap, as that is something very much out of the scope of TSE's."
I have yet to create a custom trap, but please share if you get one working. I am currently monitoring my volumes by receiving SNMP alerts when the volume reaches 98%, letting me know the volume will autosize very soon.
Daniel
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Buerger, Andreas Sent: Tuesday, February 26, 2008 11:10 AM To: toasters@mathworks.com Subject: vol autoresize notification
Hi,
We're in progress to configure vol autoresizing on some of our systems. One central aspect of this configuration should be to get an information about the processed autoresizing action, to track what's going on on the affected volume. At the moment I see the only possibilty to get the threshold information of neary full and full volumes (by default 95% & 98%). By default, I just see the log on the console and so in /etc/messages, but non is send via snmp etc.
Is it possible to monitor the autoresizing action or is there a way to implement a notfication for autoresizing?
I'm thinking of user defined traps or something like that. Has anyone experiences with implementing vol autoresize?
Cheers Andreas
-- Wincor Nixdorf International GmbH Sitz der Gesellschaft: Paderborn Registergericht Paderborn HRB 3507 Geschäftsführer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. Jürgen Wunram Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193
Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.
This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
______________________________________________________________________ This email transmission and any documents, files or previous email messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient or a person responsible for delivering this transmission to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of this transmission is strictly prohibited. If you have received this transmission in error, please immediately notify the sender by telephone or return email and delete the original transmission and its attachments without reading or saving in any manner.
We'll see, we're planning to upgrade one cluster this weekend. I'll let you know if this section is covered satisfyingly in 7.2.4. Just trusting a threshold and believe that the volume has been resized is not a pretty solution. It would be nice to get an alert or an information for such an event. I just had a look at the netapp.mib and at our DFM, so I'm not very confident about this topic in OnTAP < 7.2.4 At the moment, I didn't see the option to monitor the resize event with a DFM config or a user defined trap. We're able to configure different thresholds, status, growth information etc., but not a specific notfication for resizing.
So, if we don't want to parse any logs with swatch or logsurfer, the only solution right now, is to work with thresholds or (may be) update to 7.2.4.
Hope that someone can correct me.
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Scott Lowe Sent: Tuesday, February 26, 2008 8:37 PM To: toasters@mathworks.com Subject: RE: vol autoresize notification
I could be mistaken, but I know that ONTAP 7.2.4 adds logging for volume auto-resize events. I believe that it adds SNMP events as well, but I don't know that for certain.
-- Scott Lowe ePlus Technology, Inc.
________________________________________ From: owner-toasters@mathworks.com [owner-toasters@mathworks.com] On Behalf Of Daniel Keisling [daniel.keisling@austin.ppdi.com] Sent: Tuesday, February 26, 2008 1:50 PM To: Buerger, Andreas; toasters@mathworks.com Subject: RE: vol autoresize notification
I have the same problem because I have many thin-provisioned LUNs. You are correct in that there is no SNMP notification for autosize. I opened a ticket with NetApp and the reply was:
"First, if you have DFM, you can create a custom alert for notification. Second, you can create a custom trap using SNMP, and that would alert you as well.
There is some information on creating custom SNMP traps in the Network Management Guide, Chapter 5: http://now.netapp.com/NOW/knowledge/docs/ontap/rel723/html/ontap/nag/5sn mp7.htm
Unfortunately, I cannot assist you in actually creating a new trap, as that is something very much out of the scope of TSE's."
I have yet to create a custom trap, but please share if you get one working. I am currently monitoring my volumes by receiving SNMP alerts when the volume reaches 98%, letting me know the volume will autosize very soon.
Daniel
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Buerger, Andreas Sent: Tuesday, February 26, 2008 11:10 AM To: toasters@mathworks.com Subject: vol autoresize notification
Hi,
We're in progress to configure vol autoresizing on some of our systems. One central aspect of this configuration should be to get an information about the processed autoresizing action, to track what's going on on the affected volume. At the moment I see the only possibilty to get the threshold information of neary full and full volumes (by default 95% & 98%). By default, I just see the log on the console and so in /etc/messages, but non is send via snmp etc.
Is it possible to monitor the autoresizing action or is there a way to implement a notfication for autoresizing?
I'm thinking of user defined traps or something like that. Has anyone experiences with implementing vol autoresize?
Cheers Andreas
-- Wincor Nixdorf International GmbH Sitz der Gesellschaft: Paderborn Registergericht Paderborn HRB 3507 Geschäftsführer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. Jürgen Wunram Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193
Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.
This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
______________________________________________________________________ This email transmission and any documents, files or previous email messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient or a person responsible for delivering this transmission to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of this transmission is strictly prohibited. If you have received this transmission in error, please immediately notify the sender by telephone or return email and delete the original transmission and its attachments without reading or saving in any manner.
Use swatch to watch the messages file on the filer and trap on that regular expression. I'm sure you can find a single command to send the trap by executing a command when the regex is met.
--- Daniel Keisling daniel.keisling@austin.ppdi.com wrote:
I have the same problem because I have many thin-provisioned LUNs. You are correct in that there is no SNMP notification for autosize. I opened a ticket with NetApp and the reply was:
"First, if you have DFM, you can create a custom alert for notification. Second, you can create a custom trap using SNMP, and that would alert you as well.
There is some information on creating custom SNMP traps in the Network Management Guide, Chapter 5:
http://now.netapp.com/NOW/knowledge/docs/ontap/rel723/html/ontap/nag/5sn
mp7.htm
Unfortunately, I cannot assist you in actually creating a new trap, as that is something very much out of the scope of TSE's."
I have yet to create a custom trap, but please share if you get one working. I am currently monitoring my volumes by receiving SNMP alerts when the volume reaches 98%, letting me know the volume will autosize very soon.
Daniel
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Buerger, Andreas Sent: Tuesday, February 26, 2008 11:10 AM To: toasters@mathworks.com Subject: vol autoresize notification
Hi,
We're in progress to configure vol autoresizing on some of our systems. One central aspect of this configuration should be to get an information about the processed autoresizing action, to track what's going on on the affected volume. At the moment I see the only possibilty to get the threshold information of neary full and full volumes (by default 95% & 98%). By default, I just see the log on the console and so in /etc/messages, but non is send via snmp etc.
Is it possible to monitor the autoresizing action or is there a way to implement a notfication for autoresizing?
I'm thinking of user defined traps or something like that. Has anyone experiences with implementing vol autoresize?
Cheers Andreas
-- Wincor Nixdorf International GmbH Sitz der Gesellschaft: Paderborn Registergericht Paderborn HRB 3507 Geschäftsführer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. Jürgen Wunram Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193
Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.
This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
______________________________________________________________________
This email transmission and any documents, files or previous email messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient or a person responsible for delivering this transmission to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of this transmission is strictly prohibited. If you have received this transmission in error, please immediately notify the sender by telephone or return email and delete the original transmission and its attachments without reading or saving in any manner.
____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
-
Brent Ellis -
Buerger, Andreas -
Daniel Keisling -
Glenn Walker -
Hadrian Baron -
Jerry -
Matthew Zito -
Nicholas Bernstein -
Scott Lowe -
Sto Rage©