Home > IPV6, Technical > Ipv6 Logo Interoperability Test using Tahi Vel tool

Ipv6 Logo Interoperability Test using Tahi Vel tool

I found that lot of queries in the tahi forums are regarding setting up of the Ipv6 interoperabilty testbed and thought of sharing my experience which may help others.

This is a continuation of my previous post “IPv6 logo certification using Tahi Self test tool

As mentioned there to get the ipv6 logo certification, two tests are mandatory,

  1. ipv6 logo conformance test using the Selftest tool
  2. IPv6 interoperability test using the Vel tool

Goal of this test

The primary goal for this test is to make sure that, the unit under test’s (UUT) ipv6 implementation is interoperable with other vendor implementation.

Hardware Requirements for the test.

  • VEL tool.
  • 2 x PC’s(Reference Node) running free BSD OS with 3 NICS
  • 1 x PC(Vel Manager Node) running Free BSD OS with 1 NIC
  • 1 x PC (Dumper Node) running Free BSD with 4 NICs
  • 4 X PC’s (Target Nodes) running 4 different OS with 4 NICs each. Recommended Target OS are         – FreeBSD 7.0
            – NetBSD 4.0.1
            – OpenBSD 4.3
            – Fedora9
    – KAME
    – USAGI

*  I have used the bold ones as my target OS

So as we can see we need total 8 PC’s/Servers in total. We can reduce the number of PCS to 5 by running all the 4 Target OS installed in 1 single PC as well. Also please note the number of NICs which are required as well. Because of this requirements its a very difficult to have this topology. but fortunately the new virtualization technologies can help us with solving the issue and this post is about how we can optimize/achieve the same topology using a virtualization enabled server using  Vmware’s Esxi.

Optimized Setup/resources which I used

  1. Server Hardware: Cisco UCS C250M1 Rack mount server running ESXi 5.1 (Instead of this any server/hardware which is supported by ESXi can be used as well)
  2. Number of Physical Nics on the server: 1
  3. Virtualization Software/Hypervisor: ESXI 5.1

Understanding the topology for Interoperability test

First of all lets understand how to read the topology which is mentioned in the Vel tool’s read me file. Following is the topology mentioned in the README file of vel tool

                                      Network 1
              |              |           |      |
              | 1            |           | 1    +-------------+
       TG +-----------+      |        +------+                |
   +------| REF-1 (V) |      |        | LOGO |                |
   |      +-----------+      |        +------+                |
   |          | 2            |                                |
   |          |              |        Network 2               |
   |    ------+------+------------+------+-----+--            |
   |                 |       |    |            |              |
   |               1 |       |    |            +------+       |
   |       TG +----------+   |    |                   |       |
   | +--------| REF-2 (V)|   |    |                   |       |
   | |        +----------+   |    |                   |       |
   | |             2 |       |    |                   |       |
   | |               |       |    |   Network 3       |       |
   | |  ------+------+------------------------+---    |       |
   | |        |              |    |           |       |       |
   | |        | 3            |    |           |       |       |
   | |  TG +----------+ 1    |    |           |       |       |
   | | +---| TAR* (V) |------+    |           |       |       |
   | | |   +----------+           |           |       |       |
   | | |      | 2                 |           |       |       |
   | | |      +-------------------+           |       |       |
   | | |                                      |       |       |
   | | |                                      |       | 2     |
   | | |     Network for TG                   |  +---------+  |
  -+-+-+----+-------+-                        +--| dump (V)|--+
            |       |                          3 +---------+ 1
         TG |       |                                 | TG
      +---------+   +---------------------------------+
      | vel mgr |

the above one doesnt give a clear picture on how the connections are. So lets see how the topology can be interpreted.

  • Each Square/rectangular boxes are devices or PCS
  • LOGO : device under testing or your device.
  • vel mgr : vel manager, device on which velm program runs (Runs Free BSD OS)
  • TAR* : 4 interoperable devices from other vendors devices (Target nodes running target OS) including 2 hosts and 2 routers.
  • REF-1 : reference node running Free BSD OS
  • REF-2 : reference node running Free BSD OS
  • dump : packet monitor running Free BSD OS
  • (V) : device which vela and velo programs run and they are TAR*, REF-1, REF-2 and dump
  • The number around the box/device indicates the Network interfaces
  • The dashed lines (—) are the links/connections from the NIC cards
  • Network1, Network2 and Network3 are Hubs (Remember its a hub not a switch)
  • Network for TG is the management network and can be a switch.
  • “+” sign on the dashed line indicates that those two lines merge there, if there is no “+” sign that means those lines dont merge.

How to setup the same topology in the virtualized Server.

The same setup can be easily set up using Vmware’s ESXi.

  1. VM Creation: Create VMs corresponding to all the 8 devices in the topology in the same ESXi server. While creating VMs, allocate the required number of Virtual NICs as well to the VM.
  2. Vswitch Creation:  Now our job is to simulate three different network hub’s(network1, network2 and Netowrk3). For this in Vsphere Client go to ESXI Host->Configuration->Networking->Add networking–>Virtual machine(as the connection type)->Select no Physical adapters->Give a network label(network1)->Finish. Repeat the same for Network 2 and network 3. For Network TG select the physical NIC corresponding to the NIC which is conencting to the Management NIC.
  3. Mapping Network Labels to Virtual NICs: Now map the virtual NICs of each of the VM to the appropriate Network labels(Right click on the VM–>Edit Settings->Select the NIC adapter->Enter the network Label as Network1/2/3 depending on the topology.
  4. Configuring the Vswitches to behave like a hub: Another requirement is to configure the vswitches created in step 2 to behave like a hub. For this go to ESXI Server->Configuration->Networking->Select the Vswitch Name(Networ1/2/3)->Properties->Security Tab->Enable promiscuous Mode and Change it to Accept and OK.
  5. IP address Assignment:  The Virtual NICS which are mapped to Network TG will be assigned with IP address which is used for management as well as for velmgr to interact with vel clients.

Installing and Running the tool.

This is already covered in the README file of the Vel tool.

Important input file for the vel tool is a file called “config” in the “vel-5.0.1/interop_ph2” directory.

Following are the most important items which needs to be changed.

# LOGO TYPE: type of your device [host or router]
LOGO_TYPE router
# LOGO_NAME: name of your device

LOGO_IF1 Ethernet1/1
LOGO_IF1_MAC 00:00:00:00:00:01
# LOGO_IF2 : interface name and mac address on your device
# If LOGO_TYPE is router, you need to edit LOGO_IF2
LOGO_IF2 Ethernet1/2
LOGO_IF2_MAC 00:00:00:00:00:02
Similarly put the corresponding NIC mac address for the other devices in the file. Mac address can be found from the ifconfig command output.

Edit the following to change the ip address for the management or TG network
TAR1_IFTG eth0 "Put the interface name here"
TAR2_IFTG eth0 "Put the interface name here"
TAR3_IFTG eth0 "Put the interface name here"
TAR4_IFTG eth0 "Put the interface name here"
REF1_IFTG eth0
REF2_IFTG eth0
DUMPER_IFTG_V4_ADDR 192.168.20.

Some Tips

  • Make sure the firewall is disabled in all the devices which you are using. Else, vel manager may fail to connect to the vel clients.
  • Some of the tools wont be there in fedora by default. rtadvd is such a tool which I had to install.
Categories: IPV6, Technical
  1. August 25, 2013 at 8:29 PM

    Reblogged this on Nisarg Shukla's Blog.

  2. Prashant
    November 13, 2013 at 5:43 PM


    In your blog you mentioned that
    >> Network1, Network2 and Network3 are Hubs (Remember its a hub not a switch)

    Can you explain why I need to use Hubs and not switch? Hubs are no more used and not available in the market as well.


    • November 14, 2013 at 11:06 AM

      Hi Prashant,
      The reason why hub is mentioned is because the DUMPTER device needs to capture all the packets in that segment and if you use a switch, unicast packets may not be captured by dumper as the mac address learning prevents flooding of unicast packets, where as hubs/switches which doesnt support mac table learning will always flood the traffic, no matter whether its broadcast/known/unknown traffic.

  3. Prashant
    December 3, 2013 at 2:15 PM

    Hi Jerin, Instead of hubs we are using managed switches with mirroring port feature. Do you think it will work?

    We have results with us but not able to verify it. How I can confirm that the tests are successful? can you share a interoperability test report/result for comparison purpose?


    • December 3, 2013 at 2:30 PM

      Hi Prashant, I am not sure whether mirroring will help, as it depends on how you configured mirroring. But if you are using vms as the servers using ESXI yu dont need hub, please refer my blog post on how to configure promiscuous mode in esxi. Regarding the pass fail criteria, you need to refer the interoperability spec which is published by the ipv6 ready.org

      I cannot share my test results, as I am not sure whether its the right thing to do according to company’s policies.

      • Prashant
        December 4, 2013 at 11:09 AM

        Thanks Jerin. I will check the ESXI.
        Regarding results, it’s absolutely fine, I can understand that. Just have one query about results. When the test is executed, we are getting result files and dump files. So do we need to verify the result files and dump files manually?
        So I need to compare this data manually with the ‘Observable Results’ mentioned in interoperability specification document? Is my understanding correct?


      • December 4, 2013 at 11:28 AM

        Yes Prashanth. You are correct. You need to manually verify the dump file against the interop spec to confirm whether its a pass or fail.

  4. Prashant
    December 24, 2013 at 6:28 PM

    Hi Jerin,

    I am facing issues in Router Vs Router test cases. Do you have any info to share on it?
    Do I need to change topology while the test case is in execution?
    Kindly suggest the forums where I can get more information or at least can check the archives.


    • January 8, 2014 at 10:03 PM

      Hi Prashant,
      Could you please explain what’s the issue. Without that its very difficult to help

  5. rajeev
    February 7, 2015 at 2:53 PM

    hi jerin,
    I would like to test inotropes ,Is it possible to test with single host and single router and a packet analyzer for the host-router test cases with the vel tool

    • February 8, 2015 at 5:57 AM

      Hi Rajeev,
      If your intention of testing interop is to get certification then what you have mentioned is not enough, as ipv6 logo committee needs the full report with all the mentioned hosts etc in the interop.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: