Stitched slice

[Niky Riga]

Hi Farah,

Yesterday I checked on your slice and I was able to ping and I could see
that only the initial packets of TCP connection were passing through and
nothing else, no UDP traffic was going through either.

I believe it is an MTU problem.

Today when I logged in again I am not even able to ping which means that
the stitched link is probably down, can you please send me the output of
this command:

omni.py listresources -a https://geni-am.net.internet2.edu:12346 SliceName

Thanks,
Niky

[Ezra Kissel]

Maybe not exactly the same issue here, but I know that when I did
stitching with GRE tunnels in the past, I would need to set the MTU on
the tunnel interfaces to something like 1420 before I could reliably
send TCP stream data, or potentially larger UDP datagrams. I assume the
encapsulation is causing this behavior but I am not exactly sure where
the issue is since I thought the encapsulation was happening on the host
before bits even hit the wire.

If you are stitching with layer-2 links and tagged interfaces, then I
think this shouldn't be an issue, although you might run into other MTU
issues depending on how the path is constructed.

The GRE issue I had was from last year, so let me try another PG-PG GRE
tunnel and try to repeat. I meant to ask about that earlier but wasn't
reminded until just now!

- ezra

[Ezra Kissel]

Well, I just tried GRE tunnels across PG Utah and UKY and it works fine
now with the default tunnel interface MTU and TCP/UDP streams. Verified
on both openvz containers and raw PCs. Either the issue I saw was fixed
or I was just in a bad state at the time. ;) Sorry for the noise.

- ezra

[Niky Riga]

[adding geni-users back to the distribution, please do not drop the list
since it will give you more timely responses]

I am afraid that your stitch has expired, so you probably have to do the
setup again, I am really sorry about this:-/

I don't think you can control the MTU during reservation but we can set
it after the nodes are up to test the theory and then we can go back and
fix it if needed.

--niky

Kandah, Farah wrote:
> Here is the output:
>
> geni@geni-VirtualBox:~$ omni.py listresources -a https://geni-am.net.internet2.edu:12346 testOMNI
> 15:16:49 INFO omni: Loading agg_nick_cache file '/home/geni/.gcf/agg_nick_cache'
> 15:16:49 INFO omni: Loading config file /home/geni/.gcf/omni_config
> 15:16:49 INFO omni: Using control framework portal
> 15:16:50 INFO omni: Slice urn:publicid:IDN+ch.geni.net:MultipathRouting+slice+testOMNI expires on 2014-01-30 00:00:00 UTC
> 15:16:50 INFO omni: Gathering resources reserved for slice testOMNI.
> 15:16:57 WARNING omni: Didn't get a valid RSpec!
> 15:16:57 INFO omni: Listed reserved resources on 0 out of 1 possible aggregates.
> 15:16:57 WARNING omni: No RSpec returned for slice testOMNI from geni-am-net-internet2-edu
> 15:16:57 INFO omni: ------------------------------------------------------------
> 15:16:57 INFO omni: Completed listresources:
> Args: listresources testOMNI
>
> Result Summary: Queried resources for slice testOMNI from 0 of 1 aggregate(s).
> No resources from AM https://geni-am.net.internet2.edu:12346: (Error from Aggregate: code 12. sfa AM code: 12: : ListResources: Non existing record urn:publicid:IDN+ch.geni.net:MultipathRouting+slice+testOMNI, .)
> 15:16:57 INFO omni: ============================================================
>
>
> Can we control the MTU ?
>
>
> ________________________________________
> From: Niky Riga [niky...@gmail.com]
> Sent: Thursday, December 19, 2013 2:20 PM
> To: Kandah, Farah
> Cc: geni-...@googlegroups.com
> Subject: Stitched slice