Comments on: iSCSI, iscsicli, and WMI, Oh My! http://get-powershell.com/2009/09/18/iscsi-iscsicli-and-wmi-oh-my/ Tue, 07 Sep 2010 19:05:11 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Gregory Strike http://get-powershell.com/2009/09/18/iscsi-iscsicli-and-wmi-oh-my/comment-page-1/#comment-1175 Gregory Strike Fri, 22 Jan 2010 19:38:29 +0000 http://get-powershell.com/2009/09/18/iscsi-iscsicli-and-wmi-oh-my/#comment-1175 The line above should read: "Take each byte now and convert them back into decimal…" Always, a typo... Always. The line above should read: “Take each byte now and convert them back into decimal…”

Always, a typo… Always.

]]> By: Gregory Strike http://get-powershell.com/2009/09/18/iscsi-iscsicli-and-wmi-oh-my/comment-page-1/#comment-1174 Gregory Strike Fri, 22 Jan 2010 19:35:51 +0000 http://get-powershell.com/2009/09/18/iscsi-iscsicli-and-wmi-oh-my/#comment-1174 Great post. Thank you! You may already know this but for those readers that may not the reason the IPv4 address showed up as 1865687562 is because that's a Decimal representation of the IPv4 address which is store in binary: 1,865,687,562 to Binary is 01101111 00110100 00100010 00001010, each eight bits is a byte. Each byte represents a different octet in the IP address. Take each byte now and convert them back into binary... 01101111 = 111 00110100 = 52 00100010 = 34 00001010 = 10 10.34.52.111 Outstanding! P.S. I enjoy converting numbers between different bases. Can you tell? :) Great post. Thank you!

You may already know this but for those readers that may not the reason the IPv4 address showed up as 1865687562 is because that’s a Decimal representation of the IPv4 address which is store in binary:

1,865,687,562 to Binary is 01101111 00110100 00100010 00001010, each eight bits is a byte. Each byte represents a different octet in the IP address.
Take each byte now and convert them back into binary…

01101111 = 111
00110100 = 52
00100010 = 34
00001010 = 10

10.34.52.111 Outstanding!

P.S. I enjoy converting numbers between different bases. Can you tell? :)

]]> By: Jason Ochoa http://get-powershell.com/2009/09/18/iscsi-iscsicli-and-wmi-oh-my/comment-page-1/#comment-834 Jason Ochoa Thu, 24 Sep 2009 15:42:07 +0000 http://get-powershell.com/2009/09/18/iscsi-iscsicli-and-wmi-oh-my/#comment-834 Very nice post! At my organization we have a very similar configuration. I like the [Net.IPAddress] type. In my scrip I was converting the value to an IP manually. The script I use gets passed a couple of IPs and returns the iSCSICLI commands to establish the persistent bindings for the MPIO session mesh. This all works well and good until I add/remove/change an IP or network setting. Even if the IPs used in the iSCSI binding remain unmodified, often the ‘port number’ value changes. This causes problems for us because iSCSI traffic will then be routed out the wrong interface on the server, or the session will fail to establish at all. IPv6 changes also cause index changes as well as all IPs on a system are given a ‘port number’. Sometimes it’s as simple as a drive update that causes the issue. This is an ugly sort of problem because iSCSI traffic still tends to work, it is just routing improperly or not using all the paths it should. How are you addressing this issue in your environment? Jason Very nice post!
At my organization we have a very similar configuration. I like the [Net.IPAddress] type. In my scrip I was converting the value to an IP manually. The script I use gets passed a couple of IPs and returns the iSCSICLI commands to establish the persistent bindings for the MPIO session mesh.
This all works well and good until I add/remove/change an IP or network setting. Even if the IPs used in the iSCSI binding remain unmodified, often the ‘port number’ value changes. This causes problems for us because iSCSI traffic will then be routed out the wrong interface on the server, or the session will fail to establish at all. IPv6 changes also cause index changes as well as all IPs on a system are given a ‘port number’.
Sometimes it’s as simple as a drive update that causes the issue. This is an ugly sort of problem because iSCSI traffic still tends to work, it is just routing improperly or not using all the paths it should.
How are you addressing this issue in your environment?

Jason

]]>