To get this cross-partition monitoring to work, make sure you enable monitoring through the HMC at the partition level. Look at Partition Properties/Hardware and check:
The term non-routable IP means a little bit more than one might think. There are of course IP ranges not used on the internet that are expected to be used by companies intranets, but this isn’t the end of the story. Oracle RAC for instance wants what it calls non-routable IP addresses. But these can’t be just any two addresses that can see each other, like 10.0.0.1 and 10.0.0.2. It could be, but Oracle seems to have a soft requirement that interfaces for interconnects have different addresses.
In our environment, we have many different VLANs which are connected to each other through a switch. Lets call them VLAN 0, VLAN 4, and VLAN 8. As a happy coincidence, the vast majority of the IPs on these VLANs follow this convention:
VLAN 0 ( 10.32.0 ) –> If machines all have 255.255.252.0 as their netmask, they could talk to each other within the VLAN if their IPs are between 10.32.0.1 and 10.32.3.254. The gateway out is always specified as 10.32.0.1 but it doesn’t have to be. It could be 10.32.2.17, but that would not be a good practice.
VLAN 4 ( 10.32.4 ) –> VLAN 4 starts at 10.32.4.1 and goes to 10.32.7.254, provided that everyone use netmask 255.255.255.252. If hosts within this VLAN decide to use different netmasks, such as 255.255.255.253, they will see a smaller subset of hosts without going through the gateway. They might be able to see other hosts by going through the gateway, but things could get pretty ugly pretty fast, especially when talking to other hosts which they can see on the local VLAN, but which can’t see them.
VLAN 8 ( 10.32.8 ) By now, you should get the point. Lets say however, that we decide that all of the hosts on VLAN 8 should use netmask 255.255.255.0. In this case the IP range would be smaller: 10.32.8.1 to 10.32.8.254. But we also now have the potential to create something which we arbitrarily call VLAN 9 and could begin populating it with IPs 10.32.9.1 – 10.32.9.254 and a netmask of 255.255.255.0.
For a long time, I thought that on the switch, where VLAN 4 was specified, some logic was also included to only allow IPs 10.32.4.1 – 10.32.7.254. This is not the case. If I put the IPs 10.32.12.23 and 10.32.12.24 on VLAN 4, they will see each other. It would make sense for me to rachet down the netmask to be as small as possible in this case, but the physical hardware of the switch will allow these two interfaces to talk to each other, They would not be seen or see other IPs on the same VLAN which did not fit into their IP/netmask restriction. They also wouldn’t see the gateway unless it also fit into their scheme, 10.32.12.24 for example.
One could imagine a really interesting configuration of a VLAN with 2 or 3 evenly divided IPs that couldn’t see each other. Each would have their own unique gateways out. Since I recently read “Godel, Escher, and Bach”, I am reminded of this image (Double Planetoid), which represents two coexisting worlds that never see each other. I suggest that you click to enlarge the image below to fully understand it.
And so, in the real world, you probably wouldn’t have a VLAN of two equal parts that couldn’t see each other, the dinosaur IPs and the civilization IPs, but that doesn’t mean that its not possible, or that some dinosaur IPs may not exist in the VLAN. This is the case with our non-routable RAC heartbeats and interconnects. They can’t exist in their own VLAN because they share interfaces and it would be a little silly to create special VLANs for only a few interfaces, yet they can’t really every see the other addresses on their own VLAN and so the model is valid.