Wednesday, December 2, 2009

IP Tunneling and Amazon VPC

Glenn Brunette has successfully been able to access the Amazon Virtual Private Cloud using OpenSolaris as a customer gateway.  He describes the general concept in his blog along with pointers to a tool he's developed to automate the configuration.  This OpenSolaris customer gateway uses core technologies such as IP tunneling, IPsec, and BGP to provide redundant secure links to the cloud (see the functional diagram that Glenn provides for a depiction of this).

The IP tunnel configuration using OpenSolaris allowed Glenn and his team (including Dan McDonald and others) to troubleshoot the operation of BGP over these tunnels using the observability provided by the Clearview project (integrated in OpenSolaris build 125), which would not have been possible before.

Thanks for doing this fantastic work Glenn!

Thursday, November 12, 2009

Fluendo DVD player initial reaction

I bought the Fluendo DVD player for OpenSolaris last night, and there seem to be some very rough edges.  For one, the /usr/bin/fluendo-dvd script doesn't work out of the box and spews shell syntax errors.  It assumes that "/bin/sh" is actually bash, which isn't the case on OpenSolaris.  Changing the first line of the script to "#!/bin/bash" fixes the problem and the binary launches.

I've installed the player on two systems, both running development build 126 of OpenSolaris.  One is my Sun Ultra 40 desktop, and the other is my Toshiba Portege r500 laptop.  One common gripe in general is that the player has no control buttons at all (e.g. play, stop, pause, etc.).  To control the player, one needs to go through the "DVD Player" menu, which is very odd.
There is also no evidence of the capability to navigate forward or backwards through a movie at higher or lower rates.

OpenSolaris itself is not contributing to a positive user experience, as after watching a movie for any more than ten minutes results in the audio stream being corrupted by what sounds like static clicks and hisses.  Stopping and restarting the player causes the audio issue to go away, but it comes back after a short time.  This exact same issue occurs for other gstreamer applications, so this is not fluendo-dvd player problem.  There is likely a bug in the audio framework.

Aside from these common issues, the player is unable to play movies on my Toshiba Portege laptop.  The first time I attempted to play a movie (after having applied the above fix to the launcher script), the application crashed with a segmentation fault.  I have the core dump if anyone from Fluendo wishes to debug the issue (the segfault occurs in fluendo_css_descrambler_descramble()).  From that point on, any attempt to play a movie results in the following popup.
I'm not sure what to make of that.  Perhaps there are some file permission issues on this system, but the error is cryptic enough that there's no hope of diagnosing what the problem is.

On the positive side, on the one system I'm able to get it working, the video quality is excellent.

The laptop is the main platform from which I'd like to use this, so the current situation is disappointing.  I'm hoping that these are simple bugs that can be expediently fixed, and that the mail I sent to the support channel at Fluendo last night will be answered (I'd expect so since the 20 Euros one pays for this includes 1 year of support).

OpenSolaris DVD player from Fluendo

Fluendo released their DVD player for OpenSolaris today!

http://www.fluendo.com/shop/product/fluendo-dvd-player/

Thursday, October 8, 2009

IPv6 in Shared-Stack Zones

I was recently at an OpenSolaris user-group meeting where a question was asked regarding how IPv6 could be used from a shared-stack zone.  For the benefit of anyone who has a similar question, here is an example of a working configuration:


bash-3.2# zoneadm list -iv
  ID NAME             STATUS     PATH                           BRAND    IP    
   0 global           running    /                              native   shared
   - test             installed  /export/home/test              native   excl  
   - test2            installed  /export/home/test2             native   shared

The exclusive-stack zone "test" has all of its own networking configured within it, so IPv6 inherently just works there.  The question, however, was about shared-stack, and so I setup the "test2" zone to demonstrate this.


bash-3.2# zonecfg -z test2
zonecfg:test2> add net
zonecfg:test2:net> set physical=e1000g0
zonecfg:test2:net> set address=fe80::1234/10
zonecfg:test2:net> end
zonecfg:test2> add net
zonecfg:test2:net> set physical=e1000g0
zonecfg:test2:net> set address=2002:a08:39f0:1::1234/64
zonecfg:test2:net> end
zonecfg:test2> verify
zonecfg:test2> commit
zonecfg:test2> exit
bash-3.2# zonecfg -z test2 info
zonename: test2
zonepath: /export/home/test2
brand: native
...
net:
address: 10.8.57.111/24
physical: e1000g0
defrouter not specified
net:
address: fe80::1234/10
physical: e1000g0
defrouter not specified
net:
address: 2002:a08:39f0:1::1234/64
physical: e1000g0
defrouter not specified

Here I configured a link-local address fe80::1234/10, and a global address 2002:a08:39f0:1::1234/64.  Each interface within each zone requires a link-local address for use with neighbor-discovery, and the global address is the address used for actual IPv6 communication by applications and services. The global address' prefix is one that is configured on the link to which the interface is connected.  In the zone, we end up with:

bash-3.2# zlogin test2 ifconfig -a6
lo0:1: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
        inet6 ::1/128
e1000g0:2: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
        inet6 fe80::1234/10
e1000g0:3: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
        inet6 2002:a08:39f0:1::1234/64

The global zone has IPv6 connectivity using this same prefix as well as a default IPv6 route: [2]

bash-3.2# netstat -f inet6 -rn

Routing Table: IPv6
Destination/Mask            Gateway                   Flags Ref   Use    If
--------------------------- --------------------------- ----- --- ------- -----
2002:a08:39f0:1::/64        2002:a08:39f0:1:214:4fff:fe1e:1e72 U       1       0 e1000g0:1
fe80::/10                   fe80::214:4fff:fe1e:1e72    U       1       0 e1000g0
default                     fe80::1                     UG      1       0 e1000g0

From the non-global zone, we have IPv6 connectivity:

bash-3.2# zlogin test2 ping -sn 2002:8194:aeaa:1:214:4fff:fe70:5530
PING 2002:8194:aeaa:1:214:4fff:fe70:5530 (2002:8194:aeaa:1:214:4fff:fe70:5530): 56 data bytes
64 bytes from 2002:8194:aeaa:1:214:4fff:fe70:5530: icmp_seq=0. time=4.654 ms
64 bytes from 2002:8194:aeaa:1:214:4fff:fe70:5530: icmp_seq=1. time=2.632 ms
64 bytes from 2002:8194:aeaa:1:214:4fff:fe70:5530: icmp_seq=2. time=2.501 ms
64 bytes from 2002:8194:aeaa:1:214:4fff:fe70:5530: icmp_seq=3. time=2.571 ms
^C
----2002:8194:aeaa:1:214:4fff:fe70:5530 PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms)  min/avg/max/stddev = 2.501/3.090/4.654/1.044

The zone can then be configured to use DNS or local hosts to resolve names to IPv6 addresses in order to utilize IPv6 more effectively.

Friday, September 25, 2009

Clearview IP Tunneling in OpenSolaris

I integrated Clearview IP Tunneling (the final component of the Clearview project) into the ON consolidation this week.  It will be included in OpenSolaris build 125 which will make its way to the dev repository in due time.  Thanks to all who participated including the Clearview project team (past and present), and members of various OpenSolaris communities who contributed by doing design and code reviews.  This brings a close to a project that Meem and I conceived years ago while doodling network interface requirements on his whiteboard.  We've now delivered every component that we initially identified as the solutions to meet our requirements.  That's something to be proud of.

With this integration, IP tunnel links can be created using dladm, be given meaningful names using link vanity naming, observed using traditional network observability tools such as snoop and wireshark, assigned to exclusive stack non-global zones, and created from within non-global zones.

This integration also enables the use of dladm in general from within exclusive stack non-global zones.  Aside from the IP tunnel subcommands which are supported from such zones, all of the show-* subcommands now work in such zones, allowing administrators to view datalink configuration pertinent to the zone.  This is a first step towards gradually expanding the set of datalink features available in zones.

Enjoy, and feel free to communicate with us regarding this project at clearview-discuss@opensolaris.org.