Hi Mehmet,
This is a bug with the new JSON api. Could you please create an issue for it
and I will address it ASAP.
In the meantime, you can add your flowspace using the old XMLRPC API. To do
this, follow these steps:
0. Backup your config if you have things you don't want to lose.
0.1 fvctl save-config /etc/flowvisor/config.json
1. Re-enable the XMLRPC interface
1.01 Stop flowvisor
1.1 edit the /etc/flowvisor/config.json
1.2 set api_webserver_port to 8081
1.3 run fvconfig load /etc/flowvisor/config.json
1.4 start flowvisor
2. Add your flowspace using the fvctl-xml command.
2.1 fvctl-xml --url=https://localhost:8081 addFlowSpace any 10
nw_dst=10.0.0.255/32 Slice:mySlice2=7
Apologies for this, we will fix this soon. Please create an issue for this on
https://github.com/OPENNETWORKINGLAB/flowvisor/issues?state=open and follow
these steps as much as possible ->
https://github.com/OPENNETWORKINGLAB/flowvisor/wiki/Filing-New-Issues-or-bugs
Cheers.
--
Ali
On Apr 3, 2013, at 2:24 PM, mehmet fatih Aktaş <mfatihak...@gmail.com> wrote:
> Ali, I will try to follow another approach similar to what you suggested.
> Your advice helped me a lot thank you very much.
>
> I have another simple question: I am configuring FV as
> fvctl -f fvpasswd_file add-flowspace myflowspace1 all 1 any myslice1=7
> fvctl -f fvpasswd_file add-flowspace myflowspace2 all 10 nw_dst=10.0.0.255/32
> myslice2=7
>
> As far as I understand, this means the packets not matching;
> nw_dst=10.0.0.255/32, should not be forwarded to myslice2 but to myslice1.
> However, again all of the packets are issued to myslice2 because of its
> respectively high priority, I guess.
>
> Actually this behavior expected because after FV is getting configured such,
> then I "list-flowspace" and it gives:
> Configured Flow entries:
> {"force-enqueue": -1, "name": "myflowspace1", "slice-action": [{"slice-name":
> "myslice1", "permission": 6}], "queues": [], "priority": 1, "dpid":
> "all_dpids", "id": 296, "match": {"wildcards": 4194303}}
> {"force-enqueue": -1, "name": "myflowspace2", "slice-action": [{"slice-name":
> "myslice2", "permission": 6}], "queues": [], "priority": 10, "dpid":
> "all_dpids", "id": 297, "match": {"wildcards": 4194303}}
>
> As this log shows, there is no difference at the "matching" fields. So I
> think, either i am doing sth wrong with nw_dst=10.0.0.255/32 or it is not
> working right.
> (Because when add another match e.g. in_port=3, it is showing this in
> myflowspace2 match field differently from that of myflowspace1)
>
> Any help would be highly appreciated. Thanks for the time.
>
> Mehmet Fatih Aktas
>
>
>
> On Wed, Apr 3, 2013 at 4:18 PM, Ali Al-Shabibi <ali.al-shab...@stanford.edu>
> wrote:
> [Responses inline]
>
> > After I created the slices as I wrote in the previous email; first I am
> > running controller:8002, then 3 sws are not getting connected but only the
> > sw whose dpid is added with the last flowspace entry. e.g. if the FV is
> > configured such that
> > fvctl -f fvpasswd_file add-slice myslice1 tcp:192.168.56.1:8001 mfa
> > fvctl -f fvpasswd_file add-slice myslice2 tcp:192.168.56.1:8002 mfa
> >
> > fvctl -f fvpasswd_file add-flowspace myflowspace1 all 1 any myslice1=7
> > fvctl -f fvpasswd_file add-flowspace myflowspace2 00:00:00:00:00:02 3 any
> > myslice2=7
> > fvctl -f fvpasswd_file add-flowspace myflowspace2 00:00:00:00:00:03 3 any
> > myslice2=7
> > fvctl -f fvpasswd_file add-flowspace myflowspace2 00:00:00:00:00:01 3 any
> > myslice2=7
> > Then only sw_dpid:::01 is connected to myslice2. I listed FV datapaths and
> > it is showing;
> > Connected switches:
> > 1 : 00:00:00:00:00:00:00:01
> > 2 : 00:00:00:00:00:00:00:02
> > 3 : 00:00:00:00:00:00:00:03
> > 4 : 00:00:00:00:00:00:00:04
> > So there is no connectivity problem. Also as you suggested, I traced the OF
> > packet exchanges between the sws and the controllers, but for this case,
> > the connection messages (Hello, Features Request, Set Config etc.) are
> > exchanged for only connected sw_dpid:::01.
> >
>
> Are you sure flowvisor is connecting dpid 0x01 to myslice2? From your
> description I understand that initially only controller :8001 is running.
> Therefore, FlowVisor will create a connection for dpid 0x01 to myslice1 only.
> So it is normal that you only see traffic for dpid 0x01. Does this make sense
> to you?
>
> >
> > >Slicing on the dpid only will be tricky because having two entire
> > >datapaths in two different slices is nearly impossible, you need some
> > >other >variable to discriminate on. I don't know what kind of virtual
> > >subnets you want to build, but have you considered slicing on IPs or even
> > >>vlans? Another alternative which is quite simple is to slice on a
> > >combination of dpids and ports.
> > This is a good suggestion, thanks, but what I want to have is sligthly more
> > dynamic way of slicing the network by using FlowVisor. That is why I was
> > trying to go for fine-grained manner of slicing: by specifying dpids
> > individually for each slice. Also I am not trying to slice the datapath
> > entirely here.
> > Do you have any idea that might be useful to achieve this type of slicing
> > else I will try to follow what you suggested, vlan or IP slicing.
> > Thanks.
> >
>
> Dpid slicing isn't very fine grained because once you allocate a dpid to a
> slice (ie. which no other discriminant), the flowspace (and therefore the
> slice it is in) with the highest priority will always have control of that
> dpid. From what I can tell, VLAN or IP (or MAC) slicing is your best bet here.
>
> > Mehmet Fatih Aktas
> >
> >
> >
> > On Wed, Apr 3, 2013 at 2:26 PM, Ali Al-Shabibi
> > <ali.al-shab...@stanford.edu> wrote:
> > Hi Mehmet,
> >
> > For your instability issue could you check that the connection between the
> > switches and flowvisor is stable. That'll give us a better idea of where to
> > start looking. You can verify this by running fvctl list-datapaths and
> > confirming that all 4 switches remain connected. If they are always
> > connected then you should probably capture a packet trace between flowvisor
> > and the controllers to see what is actually going on. This can be done with
> > wireshark.
> >
> >
> > >
> > > Also, even though the flowspaces of myslice1&2 are successfully created
> > > and all switches are getting connected successfully, FV does not send the
> > > packet_ins to both slice switches but only to one e.g. controller:8001.
> > >
> >
> > So flowvisor does not do this. It will only forward control traffic to one
> > slice. In your case myslice1 takes precedence because it has a higher
> > priority and matches all dpids.
> >
> > > Overall, what i am trying to do is to slice the network into virtual
> > > subnets, and here i explained the problems I had during doing that. What
> > > I am doing may not be the best way, I would appreciate any help or
> > > comment.
> >
> > Slicing on the dpid only will be tricky because having two entire datapaths
> > in two different slices is nearly impossible, you need some other variable
> > to discriminate on. I don't know what kind of virtual subnets you want to
> > build, but have you considered slicing on IPs or even vlans? Another
> > alternative which is quite simple is to slice on a combination of dpids and
> > ports.
> >
> > Let me know if this helps.
> >
> > > Thanks for the time.
> > >
> > > Mehmet Fatih Aktas
> > >
> > >
> > > On Tue, Feb 26, 2013 at 3:08 PM, Ali Al-Shabibi
> > > <ali.al-shab...@stanford.edu> wrote:
> > > Hi Mehmet,
> > >
> > > FlowVisor can reside anywhere really (within a reasonable latency), so
> > > you could have it running in the mininet VM or on another machine. Just
> > > point your mininet network to the FlowVisor.
> > >
> > > This can be done by giving the --controller remote option to mininet.
> > > That said, I'd be interested to know what problems you had installing
> > > FlowVisor.
> > >
> > > >
> > > > Is there any simple tutorial or any resource that can help me to get on
> > > > board quickly ?
> > >
> > > Unfortunately not yet, but I will be putting the tutorials up online
> > > officially soon, although they may not be very different to the ones you
> > > have found yet.
> > >
> > > Hope this helps!
> > >
> > > > Thanks.
> > > >
> > > > Mehmet Fatih Aktas
> > > > _______________________________________________
> > > > openflow-discuss mailing list
> > > > openflow-discuss@lists.stanford.edu
> > > > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
> > >
> > >
> > >
> > >
> > >
> >
> >
>
>
_______________________________________________
openflow-discuss mailing list
openflow-discuss@lists.stanford.edu
https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
