The individual owning this blog works for Oracle in Germany. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.
< Less known Solaris features - IP Multipathing (Part 5): Prerequisites | Less known Solaris features - IP Multipathing (Part 7): New IPMP and link aggregation >
Friday, January 22. 2010
When you want to try new IPMP, you need a fairly recent build of OpenSolaris. New IPMP was integrated into Build 107 for the first time.
At first: If you have already a working IPMP configuration, you can simply reuse this config. However it yields a different looking, but functionally equivalent result compared to your system with Classic IPMP. This is made possible by some automagic functions in New IPMP. One example is the implicit creation of the IPMP interface with the name of the IPMP group when there isn't already an IPMP interface in the group. However explicit creation should be prefered as you can choose a better name for your IPMP interface and the dependencies are much more obvious.
As I wrote before, the new IPMP doesn't use a logical interface switching from one interface to the other. You have a special kind of interface for it. It's a virtual interface. It's looking like a real interface but there is no hardware behind this interface.
So ... at first we have to configure this interface:
With this command you've configured the IPMP interface. You can use any name for it you want, it just has to begin with a letter and has to end on a number. I have chosen the name
Now let's look at the interface:
As you see, it's pretty much looking like a normal network interface with some specialities: At first it's in the mode
The interface is already configured with the data address.(Additional data addresses are configured as logical interfaces onto this virtual interface. You won't configure additional virtual IPMP interfaces). The data address will never move away from there. At the end you see the name of the IPMP group. The default behavior sets the name of the IPMP group and the name of the IPMP interface to the same value.
Okay, now we have to assign some physical interfaces to it. This is the moment where we have to make a decision. Do we want to use IPMP with probes or without probes? As I've explained before it's important to know at this point, what failure scenarios you want to cover with your configuration. You need to know it now, as the configuration is slightly different.
Link based failure detectionI want to explain the configuration of the link based failure detection first not only because it's easier, but to show you the problems of link based failure detection, too.
ConfigurationAs explained before, the link based failure detection just snoops on certain events of the networking card like a lost link. Thus we just have to configure the interface into the IPMP group that you want to protect against a link failure, but you don't have to configure any IP addresses on the member interfaces of the IPMP group.
Okay, at first we plumb the interfaces we want to use in our IPMP group:
Okay, now we add the three member interfaces into the IPMP group:
As you may have noticed, we really didn't specify an IP address or a hostname. With link-based failure detection you don't need it. The IP address of the group is located on the IPMP interface we've defined a few moments ago.
But let's have a look at the
Let's look at one of the interfaces:
We find the consequences of both
Playing aroundNow we need to interact with the hardware, as we will fail network connections manually. Or to say it differently: We will pull some cables.
But before we are doing this, we look at the initial status of our IPMP configuration. The new IPMP model improved the monitoring capabilities of it's state by introducing a command for this task. It's called
Just to give you a brief tour through the output of the command. The first column reports the name of the interface, the next one reports the state of the interface from the perspective of IPMP. The third column tells you which IPMP group was assigned to this interface.
The next columns gives us some more in-depth information about the interface. The fourth column is a multipurpose column to report a number of states. In the last output, the
Okay, now pull the cable from the
As you can see, the failure has been detected on the
Put the cable back to the port of the
The problem with link-based failure detectionJust in case you've played with the ethernet cables, ensure that IPMP chooses an interface connecting via Switch A as the active interface by zipping Cable 3 from the switch B for a moment. When you check with
As i wrote before there are failure modes link-based failure detection can't detect. Now let's introduce such a fault. To do so, just remove Cable 4 between switch A and B.
As there is still a link on the Cables 1 and 2 everything is fine from the perspective of IPMP. It doesn't switch to the connection via
Probe based failure detectionThe probe based detection has some additional capabilities. At first it has all the capabilities of the link-based detection. It switches over to the other network card as soon as the card loses the link. But additionally it checks the availability of the connection by pinging other IP addresses called target systems. When the system doesn't get a reply on the ICMP messages, the interface is assumed to be in failure state and it isn't used anymore.
ConfigurationOkay, at first we revert back to the original state of the system. This is easy, we just have to unplumb the interfaces. In my example I'm unplumbing all interfaces. You could reuse the
Okay, now all the interfaces are away. Now we recreate the IPMP group.
We can check the successful creation of the IPMP interface by using the
At start there isn't an interface configured into the IPMP group. So let's start to fill the group with some life.
There is an important difference. This
The idea behind the
Posted by Joerg Moellenkamp in English, Oracle, Solaris at 00:06
Related entries by tags:
Display comments as (Linear | Threaded)
The author does not allow comments to this entry
The LKSF book
The book with the consolidated Less known Solaris Tutorials is available for download here
Martin about End of c0t0d0s0.org
Mon, 01.05.2017 11:21
Thank you for many interesting blog posts. Good luck with al l new endeavours!
Hosam about End of c0t0d0s0.org
Mon, 01.05.2017 08:58
Joerg Moellenkamp about tar -x and NFS - or: The devil in the details
Fri, 28.04.2017 13:47
At least with ZFS this isn't c orrect. A rmdir for example do esn't trigger a zil_commit, as long as you don't speci [...]
Thu, 27.04.2017 22:31
You say: "The following dat a modifying procedures are syn chronous: WRITE (with stable f lag set to FILE_SYNC), C [...]