stitching plus shared vlans

[Ezra Kissel]

While I'm in the middle of this, here's another issue I encountered. I
was able to create shared vlans at ig-bbn and pg-utah AMs. I was able
to bring up other slices and connect nodes using the shared_vlan
extension as expected. Now what I want to do is stitch together nodes
spanning those shared vlans at each rack.

I constructed an rspec (attached) with two interfaces per node, one in
the shared vlan, one for the stitching endpoints. I ran stitcher.py and
everything came up. However, at both ig-bbn and pg-utah, there were no
vlan-tagged interfaces as one usually sees for the stitching interfaces.
They were simply eth{1,2}. On the ig-bbn side, both interfaces got
the same IP for some reason, in this case 10.10.100.6 The IPs were at
least assigned correctly on the pg-utah side. The shared vlan part
worked, the stitching part didn't, meaning I could ping other nodes
within the shared vlan but nothing over the stitched path.

I'm in the process of recreating the entire setup, and I ran into the
POA issue at ig-bbn I just reported. Once I resolve that, I'll try
everything again but I expect the same problems as above since I tried
the stitching part twice already with identical results.

- ezra

[Ezra Kissel]

I found a typo in my rspec. I fixed it, resubmitted, and after a few
false starts, the shared vlan and stitching bits are working. This is
great!

One issue remains that I'm hoping someone could look into. My
experimental configuration is such that I would like to have all my
interfaces in the same IP subnet. So I have something like this:

BBN (shared_vlan) - (bbn bridge VM) - circuit - (utah bridge VM) - Utah
(shared_vlan)

On the bridge VMs, I bridge the two interfaces. For those interested:

brctl addbr br0
brctl addif br0 eth1
brctl addif br0 eth2
ifconfig br0 up
(then optionally assign IP to br0, flush IPs on eth1/eth2)

So now from Utah bridge VM I can ping the pre-created BBN VMs in the
shared vlan over the circuit all in the same IP subnet. Perfect.
However, I did the exact same thing on the PG Utah side but I can't ping
any of the pre-create Utah VMs, from either the utah bridge or the BBN side.

I double-checked the POA for pg_utah, it succeeded. The two Utah VMs
can talk to each other, just not the other slice(s). If there a way to
verify the Utah switch vlan config?

The Utah VMs in question are:

pcvm480-1.emulab.net (bridge)
pcvm218-1.emulab.net (shared vlan VM0)
pcvm238-1.emulab.net (shared vlan VM1)

thanks,
- ezra

[Ezra Kissel]

Here's a little more info if it helps. The link on the Utah bridge VM:

<link xmlns:s="http://www.geni.net/resources/rspec/ext/shared-vlan/1"
client_id="idms_utah_lan_link"
sliver_id="urn:publicid:IDN+emulab.net+sliver+192643">
<component_manager name="urn:publicid:IDN+emulab.net+authority+cm"/>
<interface_ref client_id="ibp3:if0"
component_id="urn:publicid:IDN+emulab.net+interface+pc480:eth2"
sliver_id="urn:publicid:IDN+emulab.net+sliver+192644"/>
<s:link_shared_vlan name="idms_lan"/>
</link>


I sniffed traffic on eth2 on pcvm480-1 and see arp broadcasts going out.
Nothing arriving on the other shared vlan interfaces.

Here's the bit from the slice I used to defined the shared vlan on the
Utah side:

<link client_id="lan0"
sliver_id="urn:publicid:IDN+emulab.net+sliver+192638" vlantag="274">
<component_manager name="urn:publicid:IDN+emulab.net+authority+cm"/>
<interface_ref client_id="ibp0:if0"
component_id="urn:publicid:IDN+emulab.net+interface+pc238:eth2"
sliver_id="urn:publicid:IDN+emulab.net+sliver+192639"/>
<interface_ref client_id="ibp1:if0"
component_id="urn:publicid:IDN+emulab.net+interface+pc218:eth2"
sliver_id="urn:publicid:IDN+emulab.net+sliver+192640"/>
<property source_id="ibp0:if0" dest_id="ibp1:if0"/>
<property source_id="ibp1:if0" dest_id="ibp0:if0"/>
<link_type name="lan"/>
</link>

[Ezra Kissel]

I did added another shared vlan + stitching link at illinois. It worked
well and connected the BBN shared vlan with the bridge VM at Utah. The
shared vlan at Utah still seems to be broken, however.

Is there any interest in looking at why it didn't come up or should I
simply tear things down and try again?

[Leigh Stoller]

> I did added another shared vlan + stitching link at illinois. It worked well and connected the BBN shared vlan with the bridge VM at Utah. The shared vlan at Utah still seems to be broken, however.
>
> Is there any interest in looking at why it didn't come up or should I simply tear things down and try again?

I looked briefly and nothing looked amiss, and I do not have time
today to look more deeply, sorry. Guess you can try it again.

Leigh

[Ezra Kissel]

On 6/10/2014 3:17 PM, Leigh Stoller wrote:
>> I did added another shared vlan + stitching link at illinois. It worked well and connected the BBN shared vlan with the bridge VM at Utah. The shared vlan at Utah still seems to be broken, however.
>>
>> Is there any interest in looking at why it didn't come up or should I simply tear things down and try again?
>

> I looked briefly and nothing looked amiss, and I do not have time
> today to look more deeply, sorry. Guess you can try it again.
>
> Leigh
>

I tried again just now at pg-utah with the same problem, a link into the
shared vlan doesn't seem to work. Slices are idms-pg-utah-2 and idms-ui
I'll leave them up for now in case you can take another look.

Here's the link in question:

<link xmlns:s="http://www.geni.net/resources/rspec/ext/shared-vlan/1"
client_id="idms_utah_lan_link"

sliver_id="urn:publicid:IDN+emulab.net+sliver+192854">

<component_manager name="urn:publicid:IDN+emulab.net+authority+cm"/>
<interface_ref client_id="ibp3:if0"

component_id="urn:publicid:IDN+emulab.net+interface+pc509:eth4"
sliver_id="urn:publicid:IDN+emulab.net+sliver+192855"/>

<s:link_shared_vlan name="idms_lan"/>
</link>

For context, I have performed the same steps at the BBN and Illinois IG
racks and have had success. I want to try at IG Utah (compare to PG)
but haven't been able to get the necessary resources to create the
shared vlan on that rack since the single Xen VM trick no longer works.
Plenty of other places to try, though!

- ezra