IPMP rearchitecture bits now in Nevada build 107

The long awaited IPMP rearchitecture bits just got included into the crossbow integration in OpenSolaris build 107.   A new command, ipmpstat has been introduced.

If you use IPMP in production, take a look at the reachitecture here.   Peter’s documentation on the high level design is quality stuff.   The below was taken from page 3.

3 IPMP Rearchitecture: Basic Operation
3.1 IPMP Network Interface
As previously discussed, the lion’s share of the problems with IPMP stem from not treating each
IPMP group as its own IP interface. As an example, a typical two-interface IPMP group today
looks like:
ce0: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 2
inet 129.146.17.56 netmask ffffff00 broadcast 129.146.17.255
groupname a
ce0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 129.146.17.55 netmask ffffff00 broadcast 129.146.17.255
ce1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 3
inet 129.146.17.58 netmask ffffff00 broadcast 129.146.17.255
groupname a
ce1:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 129.146.17.57 netmask ffffff00 broadcast 129.146.17.255

The above output shows ce0 and ce1 with test addresses, and ce0:1 and ce1:1 with data addresses. If ce0 subsequently fails, the data address on ce0:1 will be migrated to ce1:2, but the
test address will remain on ce0 so that the interface can continue to be probed for repair. In the future, this will instead look like:
ce0: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 2
inet 129.146.17.56 netmask ffffff00 broadcast 129.146.17.255
groupname a
ce1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 3
inet 129.146.17.58 netmask ffffff00 broadcast 129.146.17.255
groupname a
ipmp0: flags=801000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,IPMP> mtu 1500 index 4
inet 129.146.17.55 netmask ffffff00 broadcast 129.146.17.255
groupname a
ipmp0:1: flags=801000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,IPMP> mtu 1500 index 4
inet 129.146.17.57 netmask ffffff00 broadcast 129.146.17.255

That is, all of the IP data addresses associated with the IPMP group will instead be hosted on an IPMP IP interface, such as ipmp013. With this new model, data addresses will no longer be
associated with any specific physical underlying interface, but instead will belong to the IPMP group as a whole. As will become clear, this addresses many outstanding problems and vastly simplifies the implementation. There will be a one-to-one correspondence between IPMP groups and IPMP interfaces. That is, each IPMP group will have exactly one IPMP interface. By default, each IPMP interface will be named ipmpN , but administrators will be encouraged to specify a name of their choosing, as described in section 4.1.5. Since an IPMP interface’s name will not be fixed, the system will set a new IPMP flag on all IPMP interfaces to indicate that the interface has special properties and semantics, as detailed throughout this document.

1 thought on “IPMP rearchitecture bits now in Nevada build 107”

  1. Your website used to have a full RSS feed. Any chance of enabling that again? I really like your blog, and I follow it via RSS.

Leave a Reply

Your email address will not be published. Required fields are marked *