how can i connect uh-eg and illinois-ig using meso vlan

[akshay]

Hi,
I am trying to connect uh-eg and illinois-ig using meso scale vlan. I
went through
http://groups.geni.net/geni/wiki/GENIExperimenter/ExperimentExample
experiment.


Some thoughts regarding uh-eg and illinois-ig connectivity after reading
experiment:
----------------------------------------------------------------

1) uh-eg shares vlan 1751 for meso-scale
2) uh-eg is connected to I2 HOUS 1750 at port 19

QUESTION: As there are two different vlan tags here what should be my
interface need to be tagged while allocating resource at uh-eg (1750 or
1751) ?

3) illinois-ig shares vlan 1751 for meso-scale
4) illinois-ig is connected to I2 NEWY 1750 at port 21

QESTION: In the list of resources at illinois-ig i found
"mesoscale-openflow " vlan tag. which one i should use ?

5) I2 HOUS 1750 and I2 NEWY 1750 need to be connected using vlan 3715.


Connectivity will look like :
---------------------------
uh-eg -> uh-eg-openflow -> I2 HOUS -> vlan 3715 -> I2 NEWY ->
illinois-ig


computing resources
--------------------
uh-eg
illinois-ig

openflow resources
------------------
uh-eg-openflow
Internet2
illinois-ig-openflow


Can somebody please confirm my action plan ? I have already approved
10.42.160.0/24 subnet for experiment.

Regards,
Akshay Dorwat

[Tim Upthegrove]

Hi Akshay,

On Fri, Jul 18, 2014 at 12:15 PM, akshay <akshay...@gmail.com> wrote:

QUESTION: As there are two different vlan tags here what should be my
interface need to be tagged while allocating resource at uh-eg (1750 or
1751) ?

At UH, you should use VLAN 1751 in your compute RSpec.  In your FOAM RSpec, you will also need to specify a dl_vlan of 1751 in the match.

 

QESTION: In the list of resources at illinois-ig i found
"mesoscale-openflow " vlan tag. which one i should use ?

In your compute node RSpec, you should use the "mesoscale-openflow" VLAN.  In your FOAM RSpec, you should not need to specify any VLAN tag, just select the appropriate DPID.

 

Can somebody please confirm my action plan ? I have already approved
10.42.160.0/24 subnet for experiment.

Your approach looks right to me!  Of course, the devil is always in the details, so if you hit any snags along the way, feel free to ask questions.

Thanks,

--

 

Tim Upthegrove

[Akshay Dorwat]

Hi Tim,

    You were right Davil is always in detail. Here is a Davil.

My pox openflow  controller is running on stanford-ig,Here is the command i used to start the controller.

./pox.py --verbose  openflow.of_01 log --file=pox.log,w openflow.keepalive --interval=15 openflow.debug forwarding.l2_learning        

i have also wrote the rspec to create sliver(find them attached). As soon as sliver is created and approved i hit the 

ERROR:openflow.of_01:[2c-59-e5-65-c1-00|1751 1] OpenFlow Error:

[2c-59-e5-65-c1-00|1751 1] Error: header: 

[2c-59-e5-65-c1-00|1751 1] Error:   version: 1

[2c-59-e5-65-c1-00|1751 1] Error:   type:    1 (OFPT_ERROR)

[2c-59-e5-65-c1-00|1751 1] Error:   length:  84

[2c-59-e5-65-c1-00|1751 1] Error:   xid:     0

[2c-59-e5-65-c1-00|1751 1] Error: type: OFPET_FLOW_MOD_FAILED (3)

[2c-59-e5-65-c1-00|1751 1] Error: code: OFPFMFC_EPERM (2)

[2c-59-e5-65-c1-00|1751 1] Error: datalen: 72

[2c-59-e5-65-c1-00|1751 1] Error: 0000: 01 0e 00 48 00 03 c7 c6  00 10 00 1f 00 00 00 00   |...H............|

[2c-59-e5-65-c1-00|1751 1] Error: 0010: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   |................|

[2c-59-e5-65-c1-00|1751 1] Error: 0020: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   |................|

[2c-59-e5-65-c1-00|1751 1] Error: 0030: 00 00 00 00 00 00 00 00  00 03 00 00 00 00 80 00   |................|

[2c-59-e5-65-c1-00|1751 1] Error: 0040: ff ff ff ff ff ff 00 00                            |........        |

INFO:openflow.of_01:[2c-59-e5-65-c1-00|1751 1] connected

i used pcap to investigate. It seems controller hit permission denied error while setting the mod flow. (i have attached the pcap file and log file for reference). I am seeing this problem for both uh-eg and illinois-ig. interestingly Internet 2 seems to work fine.

slice name : idms-openflow

Can you please help me with this issue ?

Regards,

Akshay 

[Tim Upthegrove]

Hi Akshay,

On Sun, Jul 20, 2014 at 2:28 AM, Akshay Dorwat <akshay...@gmail.com> wrote:

Can you please help me with this issue ?

I took a look at the pcap file.  The first error that you see is related to a flowmod that pox tries to send out initially to clear all flows in the flow table.  It uses a full set of wildcards when doing this, which expands beyond your flowspace, and unfortunately flowvisor cannot funnel that request down to just your slice.  That is the reason for the error.  See http://www.noxrepo.org/forum/topic/switch-flow-table-clear/ for how to disable that.

The next error in the pcap that I saw was related to a barrier request.  That error message reported that the barrier request is not understood.  I am not sure where that comes from, but it could be that the HP switch in Illinois just doesn't support the barrier request message.  I'd need to investigate to know more for sure, but I'm not convinced that is causing any connectivity issues you see.

All of the other error messages I see in the pcap file are for packet-out messages where you specify a buffer ID but no packet data.  I think that relying on just the buffer ID when sending a packet out doesn't always work on the GENI substrate, although it certainly seems like the right thing to do where possible.  If this is affecting your work, you can try sending the packet data with your packet-outs instead of just the buffer ID.  That likely requires some modification to the pox module you are running for forwarding.

One issue I noticed with the pcap file is that it appears to only include messages from illinois-ig.  Are you sure that the FOAM resources at uh-eg and i2-of have been reserved and approved?  You can check if the slivers have been approved by using the sliverstatus command in omni.

Also, I noticed in your I2 RSpec that you didn't reserve any ports in the backbone VLAN on NEWY and HOUS.  You will need to reserve ports in 3715 on both of those switches *in addition* to the 1750 reservation you made on those switches.  I know that is a bit confusing, but it is what we have to work with at the moment.

Thanks, and good luck!

--

 

Tim Upthegrove

[Nicholas Bastin]

On Mon, Jul 21, 2014 at 1:48 AM, Tim Upthegrove <tim.upt...@gmail.com> wrote:

The next error in the pcap that I saw was related to a barrier request.  That error message reported that the barrier request is not understood.  I am not sure where that comes from, but it could be that the HP switch in Illinois just doesn't support the barrier request message.  I'd need to investigate to know more for sure, but I'm not convinced that is causing any connectivity issues you see.

HP switches don't support barrier requests.

 

All of the other error messages I see in the pcap file are for packet-out messages where you specify a buffer ID but no packet data.  I think that relying on just the buffer ID when sending a packet out doesn't always work on the GENI substrate, although it certainly seems like the right thing to do where possible.

In general supplying a buffer ID for packet-out isn't going to work (even outside of GENI) - certainly your controller needs to tolerate the error message and react accordingly.

--

Nick

[Akshay Dorwat]

Hi Tim and Nick,

          Thank you very much for your help. I got the connectivity between two VMs. They  can ping each other now.

 I forget to add I2 Newly and Hous 3175 switches in rspec. Thank you Tim for pointing that out. 

As per the openflow specifcation 1.0  " If the packet is not buffered, the entire packet is included in the data portion, and the buffer_id is -1."

So i got confused. But i fixed that thing in the forwarding.l2_learning pox controller module. 

If  flow-visor (I am assuming here my controller is talking with flowvisor instead of switch which is doing policy enforcement ) dont have the functionality of buffering the packets then how i am getting  buffer_id in the packet_in ?

Anyways i worked on Openflow for first time, it was good experience.

Thank you very much for your guide again

Regards,

Akshay 

[Tim Upthegrove]

Hi Akshay,

On Tue, Jul 22, 2014 at 12:21 AM, Akshay Dorwat <akshay...@gmail.com> wrote:

          Thank you very much for your help. I got the connectivity between two VMs. They  can ping each other now.

I'm glad to hear it is working!

 

If  flow-visor (I am assuming here my controller is talking with flowvisor instead of switch which is doing policy enforcement ) dont have the functionality of buffering the packets then how i am getting  buffer_id in the packet_in ?

I'm not sure that the problem is Flowvisor, actually... it could be the switches, but I forget the specifics, to be honest.  The one thing I can say definitively is that you can't rely on buffer IDs all the time across all of GENI.  I think using buffer IDs does work sometimes though.

The problem might have to do with components (like FV or switches) only giving a certain lifetime for the buffer, or perhaps having a limited buffer space that can result in older buffers getting evicted.  Also, since the GENI control-plane could be going across a WAN connection for the switch-to-FV communication in addition to a WAN connection for the FV-to-controller connection, control plane latency tends to be very high.  That might also play a role in why the buffer IDs might time out somewhere.  

 

Anyways i worked on Openflow for first time, it was good experience.

That is good to hear too!

--

 

Tim Upthegrove

[Nicholas Bastin]

On Mon, Jul 21, 2014 at 6:21 PM, Akshay Dorwat <akshay...@gmail.com> wrote:

As per the openflow specifcation 1.0  " If the packet is not buffered, the entire packet is included in the data portion, and the buffer_id is -1."

So i got confused. But i fixed that thing in the forwarding.l2_learning pox controller module. 

If  flow-visor (I am assuming here my controller is talking with flowvisor instead of switch which is doing policy enforcement ) dont have the functionality of buffering the packets then how i am getting  buffer_id in the packet_in ?

The switch is buffering the packets.  However, the openflow spec makes no guarantees about how *long* the switch will buffer the packets for, nor how many packets the buffer can support.  In typical operation the switches in GENI will have flushed the buffer for your packet before you are able to respond with an action for that buffer ID.

--

NIck